6 ms·

Does anyone have any insight as to why it is this way? To me it seems insane, but I don't trust my own judgement in domains like this because I've never built a

Does anyone have any insight as to why it is this way? To me it seems insane, but I don't trust my own judgement in domains like this because I've never built anything comparable. Are there really good reasons for CSS to be the way it is?

2468ben 14y ago
(I don't think they're good reasons, just reasons) 1. Unlike print layout, the dimensions of a webpage can change, and so we slowly invented an evolving layout framework for something without fixed dimensions. I've done typesetting since it was exacto knives and hot wax, and if you told me then to imagine a stretchable paper for news I would have cried in the corner. 2. The layout framework was independently built by a bunch of separate companies, who by nature of competition weren't going to agree on everything (see every browser). 3. The agreements that WERE made were done by committee, including the reluctant inputs of competing companies. This method of design will guarantee that they end up with something weird. 4. Make it backwards compatible with all the previous ghosts of architects past. Imagine if Ford, GM and Chrysler had to build a joint car every few years. Also, try designing a page in Flash and using (or just reading about) their graphics/layout/text frameworks. Some things are much harder than HTML/CSS, some are much easier, but it offers a great comparison on a completely different way of solving layout. I've implemented a spec like CSS for customizing Flash app appearances, and compared to what existed before, it made everything better.
- CapitalistCartr 14y ago
  Imagine if Ford, GM and Chrysler had to build cars that shared the same roads, used the same fuel, fit in the same overall dimensions for parking and driving, accepted the same basic controls: Steering, foot pedals, etc. It would be madness.
  - 2468ben 14y ago
    Those features are the madness of standards enforced under penalty of law. CSS is a recommendation, and the only penalty is a competitive disadvantage. Back when the Internet was a graphically simpler place with a browser monopoly, there was little disadvantage to implement CSS however they damn felt. If Ford sold 90% of cars and a consortium recommended they add 12 new safety features, imagine how they'd respond.
    - yuhong 14y ago
      In case of CSS, the important browser was IE. This reminds me of DOCTYPE switching. From http://hsivonen.iki.fi/almost-precedent/ http://hsivonen.iki.fi/almost-precedent/: "Back when the Quirks Mode and the Almost Standards Mode were introduced ... committees created specs and that were enshrined as W3C Recommendations before there was solid implementation experience. Then the Web Standards Project lobbied browser-makers to implement the W3C specs as they were. The mindset was that the specs given from above couldn’t and shouldn’t change. People thought that vigorous upgrade evangelism would work and make Web authors change their existing sites." Note that the Web Standards Project was also the one petitioning Netscape to cancel Mariner, which ended up contributing to the problem. Why did non-IE browsers have to implement document.all?
Camillo 14y ago
I don't have a reference for this, but I always got the impression that CSS was intentionally limited to help browsers implementers write efficient layout engines with as few pathological cases as possible. For instance, if you could specify the value of object attributes using arbitrary expressions with other objects' attributes as input, it would be very easy to have circular dependencies, unexpectedly high computational costs, contradictions, and so on. Just defining how to solve a contradiction would have made the standard much more complex, and error reporting would have been a nightmare.
- Arelius 14y ago
  I think that while that may have originally been the case, I feel that we've long since passed the point of particularly efficient layout engines with as few pathological cases as possible. Particularly computational costs, since I think you'll find many sites doing some part of layout in javascript.
  - ajanuary 14y ago
    Hence new layout techniques in CSS3.
- Arelius 14y ago
  I think that while that may have originally been the case, I feel that we've long since passed the point of particularly efficient layout engines with as few pathological cases as possible. Particularly computational costs, since I think you'll find many sites doing some part of layout in javascript.
mcgwiz 14y ago
Let's clarify the question. "Does anyone have any insight as to why vertical centering of dynamic-height content is the way it is?" Yes. The original standards committee created a layout model (block, inline, and inline-block elements) that (they felt) adequately balanced language complexity with features. It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/ http://jsfiddle.net/aMMxj/10/ "Does anyone have any insight as to why people that code CSS complain about it so much?" This is a much deeper question, but one that I think is far more informative. Having done front-end engineering for 10 years, across industries, and in very pricey and exclusive consultancies, I have never found another engineer who had read the bulk of the CSS spec, or even a book about it, for that matter. Developers, the ones with the mind and experience to bring technical discipline to CSS and create a set of idiomatic patterns (both low-level and high-level), treat CSS as a second-rate citizen. The bulk of the rest of the CSS userbase consists of visual design types (coming from print or graphic design), where the tools of the trade are physical pen and paper, or something from Adobe Creative Suite. The remaining portion of the userbase are equally non-technical hobbyists. This is the real problem of CSS. Those that have the mindset to devise idiomatic conventions to the community don't think the language is worth it. At best, you have semi-experienced developers duct-taping various non-idiomatic ideas together and giving it a fancy name.
- sandGorgon 14y ago
  genuine question as a non front end engineer- do you recommend reading the CSS spec as a reference guide? im basically asking whether someone learning to be good in CSS should read the spec or pick up one of the recommended books (that appear from time to time on HN). For example, i never had to read the spec for ruby to get jruby to work.
  - Arelius 14y ago
    Does ruby even have a proper spec?
    - sandGorgon 14y ago
      yes - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59579 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_... there are other community-driven sources - like RubySpec [1], etc. but this is the (expensive!!) ISO standard. FYI - I had intended it as an example. I'm really interested to know if the most effective way to work with CSS is to understand its spec... which is not the way it works with most programming languages. But perhaps CSS is more similar to a rulebook (declarative) than a language. [1] http://en.wikipedia.org/wiki/RubySpec http://en.wikipedia.org/wiki/RubySpec
spyder 14y ago
Because we used to do these things with tables but tables aren't cool enough since the "War on tables" (because tables aren't the right way to do layouts) and nothing better has been available. Hopefully CSS3 will fix these things.
- sopooneo 14y ago
  The crazy thing about that is that all these css grid system seem to me to just be reimplementations of tables, with just as much markup.
pornel 14y ago
1. CSS1 started modestly by specifying very little over what browsers already did at the time, and from the start locked itself into HTML's inline/block/float/table model. Back then the old Netscape engine was dominant and it couldn't get even those basics right (http://acid1.acidtests.org http://acid1.acidtests.org), so there was no hope of adoption of a more advanced layout mechanism. 2. CSS had deliberate limitations that did help early implementors: e.g. elements later in the document are not supposed to cause reflow of elements earlier (with tables being "legacy" exception). That's how Opera worked until v6. That what helped all browsers implement progressive rendering. The downside is abysmal vertical centering and limited selectors (flexbox and CSS4 selectors finally drop that limitation). 3. It was hard to get any progress on this for many, many years. First we had Netscape 4, then we had IE6 holding back use of CSS on the web, so specs from that time were mostly untested ivory tower science-fiction. Things got better since, but of course now we have massive legacy and backward-compatibility constrains... and IE8/9 holding back flexbox.

2468ben 14y ago

(I don't think they're good reasons, just reasons) 1. Unlike print layout, the dimensions of a webpage can change, and so we slowly invented an evolving layout framework for something without fixed dimensions. I've done typesetting since it was exacto knives and hot wax, and if you told me then to imagine a stretchable paper for news I would have cried in the corner. 2. The layout framework was independently built by a bunch of separate companies, who by nature of competition weren't going to agree on everything (see every browser). 3. The agreements that WERE made were done by committee, including the reluctant inputs of competing companies. This method of design will guarantee that they end up with something weird. 4. Make it backwards compatible with all the previous ghosts of architects past. Imagine if Ford, GM and Chrysler had to build a joint car every few years. Also, try designing a page in Flash and using (or just reading about) their graphics/layout/text frameworks. Some things are much harder than HTML/CSS, some are much easier, but it offers a great comparison on a completely different way of solving layout. I've implemented a spec like CSS for customizing Flash app appearances, and compared to what existed before, it made everything better.

CapitalistCartr 14y ago
Imagine if Ford, GM and Chrysler had to build cars that shared the same roads, used the same fuel, fit in the same overall dimensions for parking and driving, accepted the same basic controls: Steering, foot pedals, etc. It would be madness.
- 2468ben 14y ago
  Those features are the madness of standards enforced under penalty of law. CSS is a recommendation, and the only penalty is a competitive disadvantage. Back when the Internet was a graphically simpler place with a browser monopoly, there was little disadvantage to implement CSS however they damn felt. If Ford sold 90% of cars and a consortium recommended they add 12 new safety features, imagine how they'd respond.
  - yuhong 14y ago
    In case of CSS, the important browser was IE. This reminds me of DOCTYPE switching. From http://hsivonen.iki.fi/almost-precedent/ http://hsivonen.iki.fi/almost-precedent/: "Back when the Quirks Mode and the Almost Standards Mode were introduced ... committees created specs and that were enshrined as W3C Recommendations before there was solid implementation experience. Then the Web Standards Project lobbied browser-makers to implement the W3C specs as they were. The mindset was that the specs given from above couldn’t and shouldn’t change. People thought that vigorous upgrade evangelism would work and make Web authors change their existing sites." Note that the Web Standards Project was also the one petitioning Netscape to cancel Mariner, which ended up contributing to the problem. Why did non-IE browsers have to implement document.all?

Camillo 14y ago

I don't have a reference for this, but I always got the impression that CSS was intentionally limited to help browsers implementers write efficient layout engines with as few pathological cases as possible. For instance, if you could specify the value of object attributes using arbitrary expressions with other objects' attributes as input, it would be very easy to have circular dependencies, unexpectedly high computational costs, contradictions, and so on. Just defining how to solve a contradiction would have made the standard much more complex, and error reporting would have been a nightmare.

Arelius 14y ago
I think that while that may have originally been the case, I feel that we've long since passed the point of particularly efficient layout engines with as few pathological cases as possible. Particularly computational costs, since I think you'll find many sites doing some part of layout in javascript.
- ajanuary 14y ago
  Hence new layout techniques in CSS3.
Arelius 14y ago
I think that while that may have originally been the case, I feel that we've long since passed the point of particularly efficient layout engines with as few pathological cases as possible. Particularly computational costs, since I think you'll find many sites doing some part of layout in javascript.

mcgwiz 14y ago

Let's clarify the question. "Does anyone have any insight as to why vertical centering of dynamic-height content is the way it is?" Yes. The original standards committee created a layout model (block, inline, and inline-block elements) that (they felt) adequately balanced language complexity with features. It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/ http://jsfiddle.net/aMMxj/10/ "Does anyone have any insight as to why people that code CSS complain about it so much?" This is a much deeper question, but one that I think is far more informative. Having done front-end engineering for 10 years, across industries, and in very pricey and exclusive consultancies, I have never found another engineer who had read the bulk of the CSS spec, or even a book about it, for that matter. Developers, the ones with the mind and experience to bring technical discipline to CSS and create a set of idiomatic patterns (both low-level and high-level), treat CSS as a second-rate citizen. The bulk of the rest of the CSS userbase consists of visual design types (coming from print or graphic design), where the tools of the trade are physical pen and paper, or something from Adobe Creative Suite. The remaining portion of the userbase are equally non-technical hobbyists. This is the real problem of CSS. Those that have the mindset to devise idiomatic conventions to the community don't think the language is worth it. At best, you have semi-experienced developers duct-taping various non-idiomatic ideas together and giving it a fancy name.

sandGorgon 14y ago
genuine question as a non front end engineer- do you recommend reading the CSS spec as a reference guide? im basically asking whether someone learning to be good in CSS should read the spec or pick up one of the recommended books (that appear from time to time on HN). For example, i never had to read the spec for ruby to get jruby to work.
- Arelius 14y ago
  Does ruby even have a proper spec?
  - sandGorgon 14y ago
    yes - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59579 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_... there are other community-driven sources - like RubySpec [1], etc. but this is the (expensive!!) ISO standard. FYI - I had intended it as an example. I'm really interested to know if the most effective way to work with CSS is to understand its spec... which is not the way it works with most programming languages. But perhaps CSS is more similar to a rulebook (declarative) than a language. [1] http://en.wikipedia.org/wiki/RubySpec http://en.wikipedia.org/wiki/RubySpec

spyder 14y ago

Because we used to do these things with tables but tables aren't cool enough since the "War on tables" (because tables aren't the right way to do layouts) and nothing better has been available. Hopefully CSS3 will fix these things.

sopooneo 14y ago
The crazy thing about that is that all these css grid system seem to me to just be reimplementations of tables, with just as much markup.

pornel 14y ago

1. CSS1 started modestly by specifying very little over what browsers already did at the time, and from the start locked itself into HTML's inline/block/float/table model. Back then the old Netscape engine was dominant and it couldn't get even those basics right (http://acid1.acidtests.org http://acid1.acidtests.org), so there was no hope of adoption of a more advanced layout mechanism. 2. CSS had deliberate limitations that did help early implementors: e.g. elements later in the document are not supposed to cause reflow of elements earlier (with tables being "legacy" exception). That's how Opera worked until v6. That what helped all browsers implement progressive rendering. The downside is abysmal vertical centering and limited selectors (flexbox and CSS4 selectors finally drop that limitation). 3. It was hard to get any progress on this for many, many years. First we had Netscape 4, then we had IE6 holding back use of CSS on the web, so specs from that time were mostly untested ivory tower science-fiction. Things got better since, but of course now we have massive legacy and backward-compatibility constrains... and IE8/9 holding back flexbox.