5 ms·

Why is this problem so hard when CSS does so much for node positioning? Why not create a simpler standard once and for all?

BugsJustFindMe 10y ago
We had a simpler standard in 1995. It was called tables and it did this exceptionally well and more importantly was easy enough for even amateurs to understand. And then armchair demagogues decided that markup should no longer be used for markup, setting web layout back decades and creating the field of web designers whose major accomplishment was understanding stupid div hacks.
- rimantas 10y ago
  Your comment is the best example of the demagogue. Zero understanding of the issue, the problems that tables caused. But it was easy, right?
  - BugsJustFindMe 10y ago
    Every time this subject comes up, someone trots out the old canard that tables messed with screen readers and therefore were irretrievably bad. Or they say from the highest and mightiest and ivoryest pedestal "separation of semantics and display, thus spaketh the lord" pretending, of course, that modern websites look and behave just like documents when that's demonstrably false, and that tables are therefore irretrievably bad. And instead you now have, 20 years later (TWENTY! YEARS!) something that only now works as well for layout. Adding "not-data" and navigation directives to tables to aid screen readers and separate semantics would not have taken 20 years. And now you'll have to wait another 5 years before this new, "just as good as tables!" feature is sufficiently widespread to actually deploy it without a polyfill shim. But please tell me more about what I do or don't know.
  - pessimizer 10y ago
    Better than naked ad hominem and the silly assumption that people on a site largely aimed at web developers aren't as smart as you are.
- raspasov 10y ago
  It's pretty amazing, isn't it, the type of infinitely useless brain loops we can get stuck in. Especially when we fail to take a step back and ask the question "Is this really the right way?".
  - visarga 10y ago
    In 1995 I was creating a layout engine for a UI manager (personal project). It was simpler to use and I had better primitives. Had I known then that in 2017 we will still discuss about layouts, I would have face palmed so hard. In my opinion CSS's worst sin is that it does not include basic experience from other programming languages: variables and name scoping. It's a minefield of namespace collisions and superfluous repetitions.
- stan_rogers 10y ago
  It did it exceptionally poorly, and out-of-order source that was damn near impossible to modify was the norm.
Mikhail_Edoshin 10y ago
The problem is so hard because it's not decomposed in a right way. It would be much simpler if there were 1) a pure drawing language like PostScript, very well researched and developed, 2) content, described purely in its own terms, and 3) a way to transform that content so it can be rendered by (1) on screen. This was the idea behind XML+XSLT, as far as I perceive it. CSS is kind of similar to XSLT in its pattern matching capabilities, but is both more complicated and way less powerful. To compare things: Knuth's TeX has very few basic primitives: boxes, lists, and glue. And it produces very sophisticated layouts. CSS has a wagon of stuff and still cannot produce very basic things. I sometimes remember the old Ventura Publisher software (in 1990 I worked with version 3 of it). It was somewhat similar to the current HTML+CSS: you could have the same source text, but separate style files that would render it very differently for different purposes. 27 years ago.

BugsJustFindMe 10y ago

We had a simpler standard in 1995. It was called tables and it did this exceptionally well and more importantly was easy enough for even amateurs to understand. And then armchair demagogues decided that markup should no longer be used for markup, setting web layout back decades and creating the field of web designers whose major accomplishment was understanding stupid div hacks.

rimantas 10y ago
Your comment is the best example of the demagogue. Zero understanding of the issue, the problems that tables caused. But it was easy, right?
- BugsJustFindMe 10y ago
  Every time this subject comes up, someone trots out the old canard that tables messed with screen readers and therefore were irretrievably bad. Or they say from the highest and mightiest and ivoryest pedestal "separation of semantics and display, thus spaketh the lord" pretending, of course, that modern websites look and behave just like documents when that's demonstrably false, and that tables are therefore irretrievably bad. And instead you now have, 20 years later (TWENTY! YEARS!) something that only now works as well for layout. Adding "not-data" and navigation directives to tables to aid screen readers and separate semantics would not have taken 20 years. And now you'll have to wait another 5 years before this new, "just as good as tables!" feature is sufficiently widespread to actually deploy it without a polyfill shim. But please tell me more about what I do or don't know.
- pessimizer 10y ago
  Better than naked ad hominem and the silly assumption that people on a site largely aimed at web developers aren't as smart as you are.
raspasov 10y ago
It's pretty amazing, isn't it, the type of infinitely useless brain loops we can get stuck in. Especially when we fail to take a step back and ask the question "Is this really the right way?".
- visarga 10y ago
  In 1995 I was creating a layout engine for a UI manager (personal project). It was simpler to use and I had better primitives. Had I known then that in 2017 we will still discuss about layouts, I would have face palmed so hard. In my opinion CSS's worst sin is that it does not include basic experience from other programming languages: variables and name scoping. It's a minefield of namespace collisions and superfluous repetitions.
stan_rogers 10y ago
It did it exceptionally poorly, and out-of-order source that was damn near impossible to modify was the norm.

Mikhail_Edoshin 10y ago

The problem is so hard because it's not decomposed in a right way. It would be much simpler if there were 1) a pure drawing language like PostScript, very well researched and developed, 2) content, described purely in its own terms, and 3) a way to transform that content so it can be rendered by (1) on screen. This was the idea behind XML+XSLT, as far as I perceive it. CSS is kind of similar to XSLT in its pattern matching capabilities, but is both more complicated and way less powerful. To compare things: Knuth's TeX has very few basic primitives: boxes, lists, and glue. And it produces very sophisticated layouts. CSS has a wagon of stuff and still cannot produce very basic things. I sometimes remember the old Ventura Publisher software (in 1990 I worked with version 3 of it). It was somewhat similar to the current HTML+CSS: you could have the same source text, but separate style files that would render it very differently for different purposes. 27 years ago.