3 ms·

crazygringo is absolutely right. When the committee responsible for CSS started working in the late 1990s, it seems to have lacked any members who knew anythin

by gcv 13y ago

crazygringo is absolutely right. When the committee responsible for CSS started working in the late 1990s, it seems to have lacked any members who knew anything about layout. Certainly, the browser was a new challenge, but automatic layout engines had existed for decades by that point. TeX, for example. While it is a beast, I have usually found it far easier to get its glue-and-boxes model to do what I want than wrestle with CSS. To make matters worse, the CSS people considered it a badge of pride that CSS lacks programming features. Allow variables to represent colors so we don't have type #f0c450 all over the place? Nesting constructs? Perish the thought!! That would make it look like a programming language, with scopes! As a result, we now have LESS and Sass which plug up the worst holes, but do nothing about the fundamentally brain-damaged layout model.

steveax 13y ago
You're comparing a layout engine for print where the creator has control over all aspects of the presentation (font size, page size, etc.) with CSS where the content is displayed in an environment where the user is in control of many of those? Apples to Oranges. Pretty much all the things that are difficult to do in CSS have to do with this uncertainty and lack of control. For example, centering in CSS is trivial if you're only doing it for one viewport size, font, font size.
- gcv 13y ago
  As I said, the browser is a new challenge, and I was referring exactly to the problem of presentation flexibility. However, I'm pretty sure that the boxes-and-glue model can handle flexible viewport and font sizes as inputs from the browser, rather than specified by the user in terms of page size. CSS has boxes, more or less. It does not have glue in any meaningful way, i.e., it does not give a direct way to specify what happens in between the boxes. Pretty much all the things that are difficult to do in CSS have to do with the difficulty of describing what happens in the negative space.
- lobster_johnson 13y ago
  It's true that it is harder to design a model based on different viewports and so on. However, this does not excuse the ridiculous shortcomings of CSS, especially in this case. CSS doesn't really have vertical positioning within arbitrary boxes, which is insane if you think about it. This shortcoming has nothing to do with viewports or fonts or whether it's screen or paper. After all, the rule "box B is to be vertically centered within box A" is not dependent on a particular medium such as print or screen. The rule "box A is to be 100 pixels tall" adds medium-specificity, but that's different. Rather than providing rich high-level rules to create simple, responsive layouts, CSS makes one jump through hoops to accomplish trivial things like vertical positioning, and gets mired in finicky micro-details and a cumbersome, inflexible layout model. It breaks down quickly; for example, only recently, with the introduction of "box-sizing: border-box", has it been possible apply percentages to box sizes that have padding. (Before, if you had two boxes with "width: 50%", they would wrap if you applied padding.) As an aside, I am personally not convinced that the CSS promise of separating presentation from content has paid off. In any serious web app, the DOM is visual, and separating CSS from the DOM makes no sense. It's useful as a way to organize code and to share style rules, to be sure, but those benefits don't come from content/presentation separation. I wish we had an inverted model — a visually oriented language concerned only with presentation (think SVG, only not limited to vector graphics), with a separate data language concerned exclusively with data.

by gcv 13y ago

steveax 13y ago

You're comparing a layout engine for print where the creator has control over all aspects of the presentation (font size, page size, etc.) with CSS where the content is displayed in an environment where the user is in control of many of those? Apples to Oranges. Pretty much all the things that are difficult to do in CSS have to do with this uncertainty and lack of control. For example, centering in CSS is trivial if you're only doing it for one viewport size, font, font size.

gcv 13y ago
As I said, the browser is a new challenge, and I was referring exactly to the problem of presentation flexibility. However, I'm pretty sure that the boxes-and-glue model can handle flexible viewport and font sizes as inputs from the browser, rather than specified by the user in terms of page size. CSS has boxes, more or less. It does not have glue in any meaningful way, i.e., it does not give a direct way to specify what happens in between the boxes. Pretty much all the things that are difficult to do in CSS have to do with the difficulty of describing what happens in the negative space.
lobster_johnson 13y ago
It's true that it is harder to design a model based on different viewports and so on. However, this does not excuse the ridiculous shortcomings of CSS, especially in this case. CSS doesn't really have vertical positioning within arbitrary boxes, which is insane if you think about it. This shortcoming has nothing to do with viewports or fonts or whether it's screen or paper. After all, the rule "box B is to be vertically centered within box A" is not dependent on a particular medium such as print or screen. The rule "box A is to be 100 pixels tall" adds medium-specificity, but that's different. Rather than providing rich high-level rules to create simple, responsive layouts, CSS makes one jump through hoops to accomplish trivial things like vertical positioning, and gets mired in finicky micro-details and a cumbersome, inflexible layout model. It breaks down quickly; for example, only recently, with the introduction of "box-sizing: border-box", has it been possible apply percentages to box sizes that have padding. (Before, if you had two boxes with "width: 50%", they would wrap if you applied padding.) As an aside, I am personally not convinced that the CSS promise of separating presentation from content has paid off. In any serious web app, the DOM is visual, and separating CSS from the DOM makes no sense. It's useful as a way to organize code and to share style rules, to be sure, but those benefits don't come from content/presentation separation. I wish we had an inverted model — a visually oriented language concerned only with presentation (think SVG, only not limited to vector graphics), with a separate data language concerned exclusively with data.