Hacker News Reader

Comment by diamondlovesyou | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com