The time is right for a DOM templating API

> Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one.

How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated.

And why do you bring up absolute positioning?

I hear this take on HN again and again and sure, absolute positioning has its place, and is needed for many things.

But when it's used for page/app layout, most of the time I came across this it was an absolute nightmare, falling apart at the slightest content (even text!) or screen size changes.

Even print newspaper layout can't work like this, because typography is involved, although it's probably a lot closer to what I imagine you are describing.

Maybe I'm misunderstanding you.

But when I was doing more CSS-intensive work (I still do a fair bit), developing something on a basis when someone created a layout based on absolute positioning that looked like it was "almost ready", it was a terrible time sink to try to fix it and recreating it using flex, flow et al for layout (I'm not that fond of grid outside of some scenarios, and at the time I didn't use it due to browser support) was always faster because the problems with absolute positioning as the main layout tool were basically unfixable.

Maybe there are techniques using calc() and viewport units where it makes sense, but absolute positioning is not suitable for any layout outside of completely static content and viewport dimensions, in my experience.

I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own.

Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post.

Is it a panacea? No. Of course not. Can a constraint language help? I think so.

I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.)

But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.

But flex layout is fundamentally different from tables, I guess you meant grid with that reference?

It's not that every website uses CSS grid for layout.

Coincidentally, I took a look at the DOM+CSS of a bluesky post just a few days ago (very weird coincidence, since that was the first time I opned bluesky for months), and it did use old-school tricks like centering using CSS transforms, presumably because renders a tiny bit faster than flex centering, or avoids layout calculations when elements are added in a virtualized list.

Virtualized lists are also a good example for falling back to specifying exact pixel positions and dimensions for performance reasons, but these are usually determined with help of JS. I think the transform I saw was a translateX(-50%) one, so centering.

I totally get the canvas-like approach, but in a way the constraint-based flex layouts fall into the same line of thinking for me.

The issue with absolute positioning is the need to manually specify positions and dimensions for elements, which makes it useless unless you are working within a fixed box or only relating to the corners of one rectangle.

It is explicitly meant to remove elements from the normal layout flow so they overlap each other by default.

I did mean grid, there.

And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it.

So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to get styles such as "css-g5y9jx" and this isn't the worst examples I've seen. But I am curious on why so many nested divs seem to be needed all of the time.

I am not clear what you mean by canvas-like approach? I think folks should still use elements. Just fewer of them, all told.

Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements. They largely don't even think of sections of their template as parent/child relationships. They have a visual thing and want it filled in with whatever data.

The nested divs in modern markup are just signs of lazy bone headed devs. I’m constantly removing them from our own app because with either grid or flex box layout in the browser is stupid easy. Haven’t even been tempted to use the old tricks like floats or absolute positioning in years and years.

The badge on something is a good example for using absolute positioning exactly for what it's meant for imho.

With "canvas-like approach", I meant this part of your comment (not the web technology):

> Basically, my assertion used to be to draw out what you have in mind on grid paper.

I guess we were talking past each other because you equate templates and designs, and I didn't think of this usage of the term (the post also is not about this).

Templating is not necessarily for full pages always, that defeats the purpose of templating languages in the first place to me.

> Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements.

Agree. And using modern CSS is a great way to reduce the number of "div"s.

> But I am curious on why so many nested divs seem to be needed all of the time.

I fought many these battles in my jobs, and often it's just for flexibility, because different components are written in a modular fashion. Minimizing the DOM tree size is my goal too, but often the version with less nesting requires a bit more thinking and breaks more easily when elements are added or changed.

CSS gris vs nesting flex containers is a great example for that.

Other times it's just laziness / people don't care.

Another poster was pointing out that this is not necessarily what is meant by templates in the post. I can see the distinction, but not really sure it changes my view. Since the post is largely more javascript literals for dom objects, it is hard for me not to bring that back to the design implications? Literally comes back to "people love JSX" many times. Why? Because it lets them get things to the presentation layer that is their browser.

I took some time to dive into how extensive JavaScript has made the word template in their world. I confess it reads a bit excessive to me. More than a bit, really. Tagged templates, in particular, look like one of the biggest foot guns I've ever seen.

I took it to design because I don't know of any other real reason to template the DOM other than for design purposes. Indeed, reading on the linked proposal, this is to make reactive things on a page. And that will have to be married to a design at some point. Often the entire point of introducing names that are exported from data to a rendered document is for the presentation implications of it. Otherwise, you'd just output the data?

I'm not sure if I can contribute anything more here.

Tagged template literals, aka "template string literals" are yet another technology adjacent to JS and HTML using the word "template". But it doesn't have much to do with the submission.

It's just a fancy name for advanced string interpolation in JS, and has no inherent connection to DOM elements or fragments.

But it is used by some technologies such as styled-components and Lit (the web component library).

styled-components is probably also where the obfuscated CSS-in-JS class names in the bluesky markup originate.

There is also a `<template>` element that is used by ShadowDOM and web components.

But nothing of that is the essence of the post, these are just things that coincidentally use the word "template" (and, less coincidentally, the concept).

As far as I see, it is about the wish to standardize declarative data-binding to DOM trees.

Basically, a React-like API built into the browser, but less detached from native rendering algorithms.

I only mentioned tagged template literals, as they were called out by the article as an unsung hero. Presumably, they are an example of what a good template language looks like. If so, they don't give me hope that we know what a good template language looks like.

The idea of the post seems to be encapsulated in the web components issue and discussion. Agreed that it looks largely about data binding to DOM trees. To paraphrase you, "seems like advanced DOM interpolation in JS." Which, I just can't bring myself to agree that this looks good. Happy to be proven wrong in time.