18 ms·

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid;

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Originally, plain markup attributes where designed to accomodate rendering properties, with type checking and all. The naive dichotomy established by putting "semantics" into markup and "presentational" properties into CSS was accidental, and it didn't make sense back then, nor does it now.

tinco 10y ago
Originally, it was not known that HTML pages would be so finely designed. It is not a naieve dichotomy, it is an attainable ideal that has had a very positive effect on the state of the web. We owe huge thanks to this movement that lead both to the demise of proprietary browser extensions (like flash) and to the awesome technologies in browsers today such as these CSS features, new HTML elements and transport protocols.
- tannhaeuser 10y ago
  These things, while beneficial, don't owe their existence to CSS. Instead, introducing eg. CSS shapes or `content: ` (as two extreme examples) was the way of least resistance/guerilla tactics, as opposed to putting the functionality into SVG proper, or aligning the layout box model better with the DOM model, resp. Now what we're left with is a way overcomplicated mess for generations to clean up. There's a reason Mozilla spent the better part of the decade to come up with a new web renderer. Don't get me wrong. I praise CSS for it has given designers ways to come up with new UI idioms (something I'm personally fascinated with). But I will say this has happened in spite of, rather than because of, CSS's qualities. Designers other than outright CSS nerds are struggling with CSS, and CSS is lacking badly from a basic maintainability perspective IMHO. CSS as a language puts an unnecessarily high cognitive burden on casual web developers by lacking a construct to capture the "intent" of a couple coordinated CSS rules; as a result, unless you're doing CSS every day, you're easily lost in your (or someone else's) CSS. This isn't helped by seemingly arbitrary decisions as to what goes into CSS vs. HTML. For example, responsive images eg. the `picture` element became an HTML element, but arguably should have been subject to CSS media queries instead. Which is kindof my initial point: that the HTML/CSS dichotomy is accidental and pointless from a language theory PoV.
  - tinco 10y ago
    I don't get what your point is with mentioning CSS shapes and `content`. What I am talking about is CSS Zen Garden and the movement around it of frontend web developers professionalizing, rejecting table layouts and non-standard browser features. This was enabled by CSS being barely powerful enough, and people creative enough to make it work. Eventually the movement won, non-IE browsers won market share and the way was paved for a more healthy evolutionary path of the web which has yielded these new features. You look at CSS from a perspective that it's hard, as if there exists a solution somewhere that is easier. Before CSS there were simply the less powerful HTML features, the 'easier' but less semantic and non-adaptive tools like Flash or SVG, and the always present and expertise requiring method of simply imperatively coding the styling in WinForms or whatever. CSS was absolutely crucial.
  - diamondlovesyou 10y ago
    I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side. What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeholders declared in the "CSS". I've omitted programmable considerations cause this is a HN comment and not intended to be formal proposal. Not surprisingly, the web has kinda already shifted towards this, through the use of JSON APIs in JS.
    - debaserab2 10y ago
      The content map is the dom, no? I can't see what you described ending up any less complex than what we have today.
      - jdmichal 10y ago
        The DOM is more than the proposed content map, because it also creates structure. I think the proposed idea is to basically create a structure without any content, then apply the content into that structure. The current split is CSS is presentation while HTML is content + structure. Unless I'm misunderstanding, this proposal would separate content and structure. I'm not sure where presentation would go; you could certainly make a case for it being grouped with either. There's also plenty of questions around what's content and what's structure and what's presentation. For instance, a section heading is potentially all three. I personally would probably go for grouping presentation with the content, and call structure "layout" to disambiguate it. A section heading is maybe structure, but it's definitely not layout.
bshimmin 10y ago
I'm glad someone else said it. I particularly like that they've introduced a new unit, `fr`, and can't even decide what it stands for. I've been writing CSS since about 1996; for some reason, I feel like it all started to go downhill, fast, with the background gradient syntax.
- sangnoir 10y ago
  > I feel like it all started to go downhill, fast, with the background gradient syntax I'll take background in CSS over tiled 1px-wide gradient background images any day. The responsibilities being piled to CSS keep increasing, but I believe it is being done in good faith to at improve/formalize what people in the wild are already doing with hacks. Remember DHTML?
  - bshimmin 10y ago
    Oh I do, I do... and I agree that many of the things CSS does for you today are vastly better than the ad-hoc solutions we had in the past (if you ever have to create an HTML email - and thankfully I am able to outsource all of that sort of work to someone who actually takes a perverse pleasure in it - that's always a nice reminder of how silly HTML and CSS were in the late '90s before CSS was actually broadly usable). But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane. CSS feels like it's been groaning under the weight of all of this guff for quite some time now, and adding new obscure units and funny things in square brackets isn't really going to improve matters.
    - sangnoir 10y ago
      > But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane I had somehow missed that your gripe is with the syntax - I fully agree with you on that! CSS definitely feels kludgey, especially for larger/complex apps or sites. I now think of real CSS as a target that my build system generates as I mostly write in Sass or LESS. I find those superior to vanilla CSS in maintainability and composability.
BenoitEssiambre 10y ago
I agree plus the "there's more than one way to do it" motto is dangerous. There is a reason everyone dropped Perl. It was self obfuscating. And these constructs are so opaque that they don't even know the name of their own 'fr' unit.
lenkite 10y ago
CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.
- mbrock 10y ago
  Could you give an example of how such a Lisp-like syntax would look, to show the improvement?
  - tannhaeuser 10y ago
    Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) [1]: http://dsssl.netfolder.com/DSSSL-markup-Rules.htm http://dsssl.netfolder.com/DSSSL-markup-Rules.htm
    - usaphp 10y ago
      And how is that making it better than CSS? It looks more complicated and still has to use all the same attributes.
      - tannhaeuser 10y ago
        I don't advocate using it, I just posted it for historical reference (actually I'm hesitating to post anything LISP here because that will easily derail a thread into becoming off-topic). But what the snippet shows is how eg. the DOM is traversed explicitly, as opposed to CSS's multiple implicit measurement and layout passes over the DOM. CSS sure is more compact, but doesn't begin to reveal anything like the above snippet.
jordanlev 10y ago
You say "css fans" like we have a choice in the matter :) I am a fan of building websites, and css is the only way to achieve that. Yeah it sucks, but it's all we got. Grid spec solves a LOT of problems so even if the syntax is ugly, it's existence in the world is beautiful.
- metamet 10y ago
  I'm a fan on BEM and SASS, though. :)
- tannhaeuser 10y ago
  Sorry I didn't mean it to sound like that. I'm saying this to myself just as to everyone else (I'm using CSS all the time). The post was more an expression of dissatisfaction of CSS's ad-hoc nature, and in particular of how we've come to rationalize this HTML/CSS/JS trifecta after the fact as a sound and dogmatic edifice, when in reality it is just the result a 10 days code jam in 1996.
ender7 10y ago
It's very easy to declaim one or another layout system as verbose or inconsistent. Can you suggest a mainstream layout system that offers this feature in a better manner? I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features. Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?
- tannhaeuser 10y ago
  Good points, and I definitely don't have an answer re: best layout engine. But my critique wasn't aiming that high and was merely about placing CSS syntax outside markup. CSS design genesis seems to be "ok we have this and that HTML presentation attribute; let's put it in an entirely new item-value format and separate HTML attributes/CSS properties syntactically". From this arbitrary decision in language design the idea developed that markup attributes are part of the "semantic" content of a document, and not for styling, when, to the contrary, markup attributes were specifically designed for styling and other properties. As a consequence, CSS has numerous redundancies, asymmetries, and absurdities such as CSS shapes, SVG properties you can style with CSS, the "content:" property, dogmatic and implementation-driven limitations for using presentational attributes on elements, etc.
- T-hawk 10y ago
  Here's the fundamental problem with separating styling from content: styling is content. Layout matters. Layout carries semantics. Right here on HN is an example, where the comment reply chain is indicated with indentation. The meaning of a comment such as "I disagree" varies depending on what it is replying to and therefore where it is in the layout. Other examples where layout is content: Captions for photos. An online store where each price describes the cost of whatever item it is next to. Sports box scores and other statistical presentations. Interviews in question-and-answer format where the layout indicates who is speaking. That's why we've gotten our layout engines so mixed up with our content and markup, because layout is content. How would one devise an abstraction for layout for all of these? You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing.
romaniv 10y ago
IMO, HTML/CSS have always been missing a middle layer. It really should be: - HTML for pure information - Something else (template/view?) for layout and (possibly) forms - CSS for styling in terms of fonts, colors, etc. This would easily handle layouts, but it would also have some NLS-like capabilities where you could switch from one way of presenting information to another without changing the actual docment.
- svachalek 10y ago
  This was the role that XSL tried to fill but it never caught on. Part of the reason is that it's still very dependent on what information is in the source document; if it's not there you can't lay it out, and if you don't need it then it was a big waste of database time. This ends up reversing the dependency, so the contents of your "pure information" layer end up depending on what your "layout" layer needs, and in the end the difference between the layers is only nominal.
  - romaniv 10y ago
    XSL was not envisioned as a middle layer between HTML and CSS. Plus, it was a quintessential design by committee, trying to cater to a bunch of conflicting use cases with no overall vision or conceptual elegance.
SimeVidas 10y ago
What would make more sense?
lucker 10y ago
Yep. I think the right approach is to expose the browser's primitives and just have people write their own markup/layout/style languages if they want to. Keep HTML/CSS as a fall-back and because a lot of work has gone into optimizing their performance, but start the long-needed move to opening up mainstream browsers on a lower level. Also, of course, leave JS as a fall-back but introduce a lower-level language. Re-implement HTML/CSS/JS on top of the new exposed primitives in order to expedite moving to the new standards. So you'll be able to use either original, optimized HTML/CSS/JS, or the new HTML/CSS/JS that has been re-implemented on top of the new exposed primitives, or just new stuff built on those primitives.

tinco 10y ago

Originally, it was not known that HTML pages would be so finely designed. It is not a naieve dichotomy, it is an attainable ideal that has had a very positive effect on the state of the web. We owe huge thanks to this movement that lead both to the demise of proprietary browser extensions (like flash) and to the awesome technologies in browsers today such as these CSS features, new HTML elements and transport protocols.

tannhaeuser 10y ago
These things, while beneficial, don't owe their existence to CSS. Instead, introducing eg. CSS shapes or `content: ` (as two extreme examples) was the way of least resistance/guerilla tactics, as opposed to putting the functionality into SVG proper, or aligning the layout box model better with the DOM model, resp. Now what we're left with is a way overcomplicated mess for generations to clean up. There's a reason Mozilla spent the better part of the decade to come up with a new web renderer. Don't get me wrong. I praise CSS for it has given designers ways to come up with new UI idioms (something I'm personally fascinated with). But I will say this has happened in spite of, rather than because of, CSS's qualities. Designers other than outright CSS nerds are struggling with CSS, and CSS is lacking badly from a basic maintainability perspective IMHO. CSS as a language puts an unnecessarily high cognitive burden on casual web developers by lacking a construct to capture the "intent" of a couple coordinated CSS rules; as a result, unless you're doing CSS every day, you're easily lost in your (or someone else's) CSS. This isn't helped by seemingly arbitrary decisions as to what goes into CSS vs. HTML. For example, responsive images eg. the `picture` element became an HTML element, but arguably should have been subject to CSS media queries instead. Which is kindof my initial point: that the HTML/CSS dichotomy is accidental and pointless from a language theory PoV.
- tinco 10y ago
  I don't get what your point is with mentioning CSS shapes and `content`. What I am talking about is CSS Zen Garden and the movement around it of frontend web developers professionalizing, rejecting table layouts and non-standard browser features. This was enabled by CSS being barely powerful enough, and people creative enough to make it work. Eventually the movement won, non-IE browsers won market share and the way was paved for a more healthy evolutionary path of the web which has yielded these new features. You look at CSS from a perspective that it's hard, as if there exists a solution somewhere that is easier. Before CSS there were simply the less powerful HTML features, the 'easier' but less semantic and non-adaptive tools like Flash or SVG, and the always present and expertise requiring method of simply imperatively coding the styling in WinForms or whatever. CSS was absolutely crucial.
- diamondlovesyou 10y ago
  I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side. What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeholders declared in the "CSS". I've omitted programmable considerations cause this is a HN comment and not intended to be formal proposal. Not surprisingly, the web has kinda already shifted towards this, through the use of JSON APIs in JS.
  - debaserab2 10y ago
    The content map is the dom, no? I can't see what you described ending up any less complex than what we have today.
    - jdmichal 10y ago
      The DOM is more than the proposed content map, because it also creates structure. I think the proposed idea is to basically create a structure without any content, then apply the content into that structure. The current split is CSS is presentation while HTML is content + structure. Unless I'm misunderstanding, this proposal would separate content and structure. I'm not sure where presentation would go; you could certainly make a case for it being grouped with either. There's also plenty of questions around what's content and what's structure and what's presentation. For instance, a section heading is potentially all three. I personally would probably go for grouping presentation with the content, and call structure "layout" to disambiguate it. A section heading is maybe structure, but it's definitely not layout.

bshimmin 10y ago

I'm glad someone else said it. I particularly like that they've introduced a new unit, `fr`, and can't even decide what it stands for. I've been writing CSS since about 1996; for some reason, I feel like it all started to go downhill, fast, with the background gradient syntax.

sangnoir 10y ago
> I feel like it all started to go downhill, fast, with the background gradient syntax I'll take background in CSS over tiled 1px-wide gradient background images any day. The responsibilities being piled to CSS keep increasing, but I believe it is being done in good faith to at improve/formalize what people in the wild are already doing with hacks. Remember DHTML?
- bshimmin 10y ago
  Oh I do, I do... and I agree that many of the things CSS does for you today are vastly better than the ad-hoc solutions we had in the past (if you ever have to create an HTML email - and thankfully I am able to outsource all of that sort of work to someone who actually takes a perverse pleasure in it - that's always a nice reminder of how silly HTML and CSS were in the late '90s before CSS was actually broadly usable). But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane. CSS feels like it's been groaning under the weight of all of this guff for quite some time now, and adding new obscure units and funny things in square brackets isn't really going to improve matters.
  - sangnoir 10y ago
    > But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane I had somehow missed that your gripe is with the syntax - I fully agree with you on that! CSS definitely feels kludgey, especially for larger/complex apps or sites. I now think of real CSS as a target that my build system generates as I mostly write in Sass or LESS. I find those superior to vanilla CSS in maintainability and composability.

BenoitEssiambre 10y ago

I agree plus the "there's more than one way to do it" motto is dangerous. There is a reason everyone dropped Perl. It was self obfuscating. And these constructs are so opaque that they don't even know the name of their own 'fr' unit.

lenkite 10y ago

CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.

mbrock 10y ago
Could you give an example of how such a Lisp-like syntax would look, to show the improvement?
- tannhaeuser 10y ago
  Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) [1]: http://dsssl.netfolder.com/DSSSL-markup-Rules.htm http://dsssl.netfolder.com/DSSSL-markup-Rules.htm
  - usaphp 10y ago
    And how is that making it better than CSS? It looks more complicated and still has to use all the same attributes.
    - tannhaeuser 10y ago
      I don't advocate using it, I just posted it for historical reference (actually I'm hesitating to post anything LISP here because that will easily derail a thread into becoming off-topic). But what the snippet shows is how eg. the DOM is traversed explicitly, as opposed to CSS's multiple implicit measurement and layout passes over the DOM. CSS sure is more compact, but doesn't begin to reveal anything like the above snippet.

jordanlev 10y ago

You say "css fans" like we have a choice in the matter :) I am a fan of building websites, and css is the only way to achieve that. Yeah it sucks, but it's all we got. Grid spec solves a LOT of problems so even if the syntax is ugly, it's existence in the world is beautiful.

metamet 10y ago
I'm a fan on BEM and SASS, though. :)
tannhaeuser 10y ago
Sorry I didn't mean it to sound like that. I'm saying this to myself just as to everyone else (I'm using CSS all the time). The post was more an expression of dissatisfaction of CSS's ad-hoc nature, and in particular of how we've come to rationalize this HTML/CSS/JS trifecta after the fact as a sound and dogmatic edifice, when in reality it is just the result a 10 days code jam in 1996.

ender7 10y ago

It's very easy to declaim one or another layout system as verbose or inconsistent. Can you suggest a mainstream layout system that offers this feature in a better manner? I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features. Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?

tannhaeuser 10y ago
Good points, and I definitely don't have an answer re: best layout engine. But my critique wasn't aiming that high and was merely about placing CSS syntax outside markup. CSS design genesis seems to be "ok we have this and that HTML presentation attribute; let's put it in an entirely new item-value format and separate HTML attributes/CSS properties syntactically". From this arbitrary decision in language design the idea developed that markup attributes are part of the "semantic" content of a document, and not for styling, when, to the contrary, markup attributes were specifically designed for styling and other properties. As a consequence, CSS has numerous redundancies, asymmetries, and absurdities such as CSS shapes, SVG properties you can style with CSS, the "content:" property, dogmatic and implementation-driven limitations for using presentational attributes on elements, etc.
T-hawk 10y ago
Here's the fundamental problem with separating styling from content: styling is content. Layout matters. Layout carries semantics. Right here on HN is an example, where the comment reply chain is indicated with indentation. The meaning of a comment such as "I disagree" varies depending on what it is replying to and therefore where it is in the layout. Other examples where layout is content: Captions for photos. An online store where each price describes the cost of whatever item it is next to. Sports box scores and other statistical presentations. Interviews in question-and-answer format where the layout indicates who is speaking. That's why we've gotten our layout engines so mixed up with our content and markup, because layout is content. How would one devise an abstraction for layout for all of these? You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing.

romaniv 10y ago

IMO, HTML/CSS have always been missing a middle layer. It really should be: - HTML for pure information - Something else (template/view?) for layout and (possibly) forms - CSS for styling in terms of fonts, colors, etc. This would easily handle layouts, but it would also have some NLS-like capabilities where you could switch from one way of presenting information to another without changing the actual docment.

svachalek 10y ago
This was the role that XSL tried to fill but it never caught on. Part of the reason is that it's still very dependent on what information is in the source document; if it's not there you can't lay it out, and if you don't need it then it was a big waste of database time. This ends up reversing the dependency, so the contents of your "pure information" layer end up depending on what your "layout" layer needs, and in the end the difference between the layers is only nominal.
- romaniv 10y ago
  XSL was not envisioned as a middle layer between HTML and CSS. Plus, it was a quintessential design by committee, trying to cater to a bunch of conflicting use cases with no overall vision or conceptual elegance.

SimeVidas 10y ago

What would make more sense?

lucker 10y ago

Yep. I think the right approach is to expose the browser's primitives and just have people write their own markup/layout/style languages if they want to. Keep HTML/CSS as a fall-back and because a lot of work has gone into optimizing their performance, but start the long-needed move to opening up mainstream browsers on a lower level. Also, of course, leave JS as a fall-back but introduce a lower-level language. Re-implement HTML/CSS/JS on top of the new exposed primitives in order to expedite moving to the new standards. So you'll be able to use either original, optimized HTML/CSS/JS, or the new HTML/CSS/JS that has been re-implemented on top of the new exposed primitives, or just new stuff built on those primitives.