So that's where the W3C ivory tower clique ended up this year, as rubberstamping secretary for the WHATWG: https://w3.org/blog/2019/...

Well at least, the W3C got the grounding they clearly were lacking over many years!

Recap: the W3C went totally out of touch with reality and wanted an HTML incompatible successor that neither browser vendors nor web authors were interested in. They wasted years on XHTML and drafted specs into the void.

15 years ago, Mozilla and Opera said "fuck this shit" and founded the WHATWG which would work on HTML5. Apple and Google joined in later.

And now the W3C does ground-breaking work like providing the recommendation texts in different formatting, LOL!

I’m optimistic in the long term.

I hope they will finally start pushing web components specification.

Unified layout builder across multiple platforms is what I want for about 7-8 years.

Also web assembly and recent formation of bytecodealliance. I hope mozilla will be able to grab more attention with it.

@vane I think we need to increasingly differentiate between websites and web applications.

For websites, no layout builder is needed, it would even be harmful. Just look at the garbage that WordPress, Wix, Squarespace and Bootstrap produce - it's because the whole approach has never made sense and cannot make sense for document-like things.

What has happened here is that people continued to do what we were doing in the 90s with table based layouts and just abused divs plus presentational classes instead. It sucked back then, and it's downright wrong today.

It's even worse today because most websites have some PHP engine behind so that it isn't "just" crappy bloated markup, it's also creating useless server load because it's created on the fly.

@Fast-Nop Yeah what I meant is unification of layout attributes across platforms. Ex. you make a list that is top left corner I want the top left placement attributes in code and maybe component names to be unified.

Something like invision on steroids that would be able to produce skeleton for future application in different languages but can reuse same layout files.

@vane And that's exactly what we were doing in the 90s, and it doesn't make sense. After we had CSS, the proper way has been just putting a list in the markup. Positioning has no business in the markup at all.

If and only if the list isn't the only thing of that component/unit, then a wrapper div might be justified; but otherwise, a UL is already a perfect block level element.

Then you give it one (!) class or ID that describes what this list is, in terms of meaning. The CSS and only the CSS then takes care of positioning, styling, differentiating between media targets and such.

This is a huge improvement from the formatting-infested markup we had to do in the 90s. That's what HTML4 was actually about, to get us out of the dark age of HTML3.

Starting to do this AGAIN would undo two decades of progress and drop us right back into the bad practices of HTML3.

@Fast-Nop yeah and html with web components will be next step of separation of concerns and unify modern shadow dom frameworks fragmentation (hopefully).

With css and each component described it in standard way we can start standardizing it across platforms that’s what react native or flutter are trying to do right now.

WPF. And state. I hate web applications and refuse to work on them. They are a shit show to develop, and provide the worst user experience since DOS. When we can create a web application with something like WPF and state, I'll recant everything.

@vane Yeah web applications is difficult because HTML was intended for describing documents and then used for applications because nothing else was there after Java applets had failed.

But still, with the shadow DOM, the point of that is that DOM manipulations are expensive so that only changes from the shadow DOM are transferred.

Heretic thought: maybe if people didn't use ten times the markup they would need, and didn't have many thousands of DOM nodes where a few hundred would suffice, and didn't have half a meg of presentational crap CSS where 50k would already be bloated - well maybe then DOM operations wouldn't be slow? ^^

Oh and managing state: maybe if the UIs were not a complete design chaos where everything impacts everything else, maybe directly managing DOM state wouldn't be such a spaghetti?

@Fast-Nop The real cause is to get rid of designer -> developer workflow and separate ux / designer / management from the core.

That’s the biggest money burning point. Move button 10 pixels to the right in 10 years old application can cause a headache.

State management can be achieved by something like grpc for layouts.

It’s still abstraction when you think about it but at the end I see some light.

Cloud is trying to unify backend deployment so why not unify designer -> developer workflow and make it smooth.

I think web components is step in the right direction but we need time for people to figure something out.

Not far away from IETF and the ipv6 Frankenstein.

@vane Yeah that workflow is also total nonsense because you have to start from the content, not from the visuals. The Photoshop monkeys shouldn't even be in the loop until AFTER the content is already there. That pixel shit that leaked over from print design has never been a good fit for web, especially because many "designers" have never understood the difference.

Instead of leveraging the screen media (has always been plural!), they tried to shoehorn printed pages into the screen.

Everytime you see class names that contain shit like "600px" for anything that isn't natively pixel based like images / photographs, you have one of these clowns at work, pissing on two decades of progress and still longing for the bad days of HTML3. It's really sad.