Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

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.

View on HN

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?

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.

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.

> Right here on HN is an example, where the comment reply chain is indicated with indentation.

    <div class=comment>
      <span class=user>T-hawk</span>
      Right here on HN is an example, where the comment reply chain is indicated with indentation.
      <div class=replies>
        <div class=comment>
          <span class=user>random28345</span>
          HTML is a tree of element nodes, the identity of the post being replied to can be determined by 
          the position of element in the tree 
          <div class=replies />
        </div>  
      </div>  
    </div>

----------------------

    .replies {
      margin-left: 2em;
    }

Exactly what I thought. The CSS make a visual indentation, but carries no more semantic than the data structure does already.

In fact, if it did, I would consider the HTML broken.

    <div class=comment.level1>
    ...
    </div>
    <div class=comment.level2>
    ...
    </div

Ugh, no. Layout is one way to express those relationships, but those relationships already exist in the HTML. This is important because different layouts can express the same relationship. I can put a caption below, above, beside, or over a photo and have viewers understand what is meant but which option is appropriate can depend on a number of factors that have nothing to do with the actual content or relationship being expressed. Blind people read the Web too. Having multiple layouts for different kinds and sizes of device is super useful. Being able to attach a caption to photo in HTML and express the exact spatial relationship later through CSS is much more versatile than hard baking layout into the document.

" 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."

No you wouldn't and no it is not. It's dead simple:

    <figure>
        <img src='image.jpg' alt='missing' />
        <figcaption>Caption goes here</figcaption>
    </figure>

Sure, it's dead simple for one particular semantic case already with its own specific definition in HTML. But you cherry-picked that from my examples. HTML doesn't express semantics for comment-replies or sports scores or so on. It has a generic notion of a hierarchical tree, to which CSS can apply layout (like indentation for HN comments), but that's not quite the same thing. Nothing in the HTML-CSS stack expresses general-purpose semantic relationships and we tend to make an inner-system-effect mess of it when we try.

I'm going to cherry-pick your examples again and point out that sports scores actually an ideal use case for actual tables because they are generally actual tabular data. But frankly I just disagree when you say that a hierarchical tree isn't a mechanism for expressing general-purpose semantic relationships, when it's at least as good as spatial positioning on a page. In fact, I can use classes with semantic names which make my meaning perfectly clear to anyone reading the source. It might be invisible with a bad or default stylesheet, but that's a relatively easily resolved problem.

> You would need to express the semantic relationships within the data, like "comment-replied-to"

Like https://indieweb.org/in-reply-to ?

"Can you suggest a mainstream layout system that offers this feature in a better manner"

I've done better looking/performing layouts 20 years ago with plain HTML 3.2. CSS is a mess.

Can you provide an example by chance?

Not since Geocities went under. The torrent backup available from the SoHo section doesn't have my account.

Well, that's a bummer. I was hoping for a good example of nicely built websites with the older technologies. All my examples have disappeared into the ether as well.

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.

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.

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.

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.

The content map is the dom, no? I can't see what you described ending up any less complex than what we have today.

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.

I'd be curious if there are any existing example implementations that you think demonstrate this - I'm having a hard time wrapping my head around how flattening the structure would make things better.

A tree node structure for mapping content seems like it'd be the most efficient in all the ways I can imagine it.

I suppose I'm thinking of something like ASP.NET `ContentPlaceHolder`, where you create some layout and identify holes into which the content will be placed. Except that, unlike ASP.NET and HTML, only layout elements would be permitted? This would likely be an entirely new language -- thinking of it like HTML except without text doesn't really work. Think of it more like defining panes on the screen, and the content (like HTML) is injected into those defined panes.

How the panes are laid out could be accomplished through any number of methods. Absolute, flow, flex, grid, constraint solving... Or even parent panes using different methods for their sub-panes!

The point isn't to flatten the layout. The layout can be as complex as desired. The point is to remove content from the layout; a named mapping is just an easy way to associate content to layout panes for injection.

At one point XSLT was created to convert XML documents into presentation markup. Browsers supported it and everything. It never caught on though.

I feel like that's because XSLT introduced so much complexity that mere humans found it impossible to work with. I've searched in vain for a decent XSLT editor to help me; the ones I've tried have themselves been incredibly complex. The idea was good, but the implementation is the stuff of nightmares.

> There's a reason Mozilla spent the better part of the decade to come up with a new web renderer.

That had nothing to do with the fact that HTML and CSS are independent.

Tables are way way more complicated than anything in CSS. In fact, tables are unspecified.

This [1] is a work in progress draft and incomplete. You'll be forgiven if your eyes glaze over while reading it.

[1]: https://dbaron.org/css/intrinsic/

This is not a tables-vs-CSS thing. Hey, I'm looking forward to servo and applaud Mozilla devs for it; but the reason they found it worthwile to invent an entire new programming language for implementing it certainly is telling about CSS's insane complexity.

GPU vendors invented an entirely new programming language for drawing triangles. Creating a new programming language to a solve a task doesn't mean that task is overly complex.

CSS has its problems (I'm the first to admit that), but on balance I think it's the best layout language that has been devised for documents.

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.

> 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?

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.

> 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.

I couldn't go back to vanilla CSS. Even with just its basic nesting features, SCSS enables a much more modular, compartmentalized, and parsable format, with a clear view of the overall hierarchy via imports

Dude! I had so forgot about making those 1px by however long/high images, over and over as size of things changed.

CSS/HTML is a complicated mess. But anyone who thinks it used to be better needs to take off the rose tint glasses.

Remember back in the days you had to use rounded corners images and JS hacks to get a result that border-radius does today. Nightmares.

The ironic thing is now instead of having to load 40 images, you're loading 40 different JS libraries to get the job done.

I'm still not sure if we're better off yet. . . .

I know what you mean, but just to be clear, 0 libraries are needed for me to write CSS.

I've always seen it referred to as "fractional". Have you seen it described as something else?

Well, @fantasai, who should probably know, says "I think we never really decided on that": https://twitter.com/DasSurma/status/815910270023430144

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.

Could you give an example of how such a Lisp-like syntax would look, to show the improvement?

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

And how is that making it better than CSS? It looks more complicated and still has to use all the same attributes.

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.

For one thing, if the rest of the representation of the document (the HTML and script part) was in the same language, maybe the CSS could be condensed with macros, or otherwise procedurally generated on the client side, all in the same syntax.

Figures Schemers would put the colon on the wrong end just so that the property indicators wouldn't translate to Lisp keyword symbols.

The syntax is pretty simple. The problem is all the available attributes and values. I don't see how lisp syntax would help.

I guess you could then just plop in a small lisp (scheme!) function instead of units and values in order to place things as you like them.

You could then have standard functions that did what a lot of the keywords did.

On the other hand, It could get incredibly complicated too...

Yes, if there a model of how to make something so easy and intutitive that anyone can pick it up and be productive, it is definitely Lisp.

Ha ha, but is it more confusing than javascript actually - removing the factor that what you already know is less complex than a new thing.

(Especially scheme is rather rigid in my humble opinion.)

Some sort of uniform, same syntax for representing all of HTML, CSS and the browser-side scripting language would have been a good start instead of this hodge podge of different notations clumsily embedded in each other.

Lisp for just CSS with all else same: lukewarm idea.

CSS would be nothing more than built-in functions to traverse nodes and change attributes. The latter of which would have already existed by virtue of having a programmatic interface with the DOM structure, and the former would have been invented in some form to build on whatever primitives existed, a la jQuery.

Kinda makes me wish I lived in that alternate universe.

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.

I'm a fan on BEM and SASS, though. :)

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.

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.

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.

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.

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.

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.

What would make more sense?

Reply on news.ycombinator.com