Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

w3.org

Post reply on HN
Print view View original

171–180 of 287 posts

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#171

Post by tannhaeuser »

bzbarsky wrote: post #126
tannhaeuser wrote: post #65

Earlier quoted context omitted.

The point is that HTML is almost 30 years old, and based on SGML which is much older (even though ISO 8879 is officially "only" from 1986), where SGML is just a formalization of typesetting practices established in the 1960's and 1970's. Given the depth of usage of HTML in everyday life (laws, contracts in ecommerce, medical records, personal communication, education, etc., etc.), I think HTML deserves better than be…

The markup parts of HTML (e.g. the parsing) are pretty frozen and have been for a while. This is the part that can sort of argue it used to be based on SGML (though now it's not, for various reasons). The "HTML spec" includes a lot of APIs and processing model details that need tweaking as new constraints come up. A good example is that a lot of APIs that involve cross-window access need changes to their specificatio…

> it used to be based on SGML (though now it's not, for various reasons)

HTML doesn't cease to be based on SGML by mere declaration, or even by brittling it to the point it can't be parsed by any known formal standard. That's more a political stance, as in American isn't English or some such.

WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance and a desire to not being accountable or formally verifiable (aka move fast and break things) against established, rich theoretical foundations of markup languages. And it shows: already in a paper I published two years ago [1], I show flaws in HTML as described by WHATWG, some of which have since been fixed ([3]). Not only is the concept of "transparent markup" flawed and underspecified, it also has since be used in the definition of the content model for the dl element, and as an unintended consequence also the div element (cf [2]), flaws that could be easily avoided by just using SGML for the grammar WHATWG is attempting to describe when SGML has been around for ages.

It's also not entirely true that WHATWG HTML can parse all legacy docs. For example, the keygen element has been removed, and while not a terrible loss as such ;), since keygen is a void element (an element with declared content EMPTY in SGML parlance), its presence in a legacy document (eg without an end-element tag) will make HTML5 parsers fail hard ([4]). It's also completely unclear which version of HTML is being validated by eg. W3C's nu or another validator. Heck, even the spec text for WHATWG HTML itself reads

> This file is NOT HTML, it's a proprietary language that is then post-processed into HTML

when a large portion of the spec text portrays HTML in the role of an authoring language.

So tell me why, as an author, I should follow WHATWG's vision for HTML? As you say yourself, WHATWG hasn't advanced HTML the markup language at all, and has rather prevented the evolution of declarative UI features, to the effect of making JavaScript essential for all but the most basic documents.

[1]: http://archive.xmlprague.cz/2017/files/xmlprague-2017-procee...

[2]: https://github.com/w3c/html/issues/1116

[3]: https://github.com/whatwg/html/commit/6e305c457e42276bf275b8...

[4]: Edit: this affects differences introduced in HTML 5.2 vs HTML 5.1, not some distant archaic HTML 4 version

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#172

Post by hiccuphippo »

lucideer wrote: post #144
Ajedi32 wrote: post #129

Earlier quoted context omitted.

> My personal opinion on this is to stop feeding the monopoly and refuse to use anything other than basic HTML for static content sites. That's not going to work for one simple reason: despite HN's obsession with plain HTML/CSS, these new standards _are_ actually useful. They're being created with the express purpose of solving practical problems that developers, site operators, and users are experiencing in the real…

> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).

The Web Authentication standard [0] seems super useful and something we really need in the web.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#173

Post by devit »

userbinator wrote: post #52
ChrisSD wrote: post #9

I still maintain that the "living standard" is an oxymoron. It's a collaborative browser dev document. Don't get me wrong, that's great. However for everyone else an unversioned document, any part of which can change at any moment, is not what's usually thought of as a standard.

This obsession with "living" and constant change seems to be mostly confined to the web --- instead of settling on a spec and then leaving it alone and "doing what you can with what you have", those working on this stuff seem more inclined with continuing to make browsers change. I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly, keeping out competitors, given who the…

All the browser engines and most browsers are open source, so making them harder to implement does not "feed the monopoly".

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#174

Post by nostrademons »

sureaboutthis wrote: post #133
ChrisSD wrote: post #66

Earlier quoted context omitted.

IIRC, the main objection was that error handling was an all or nothing affair. Whereas most HTML on the web is (or was) broken to a greater or lesser degree. There was also the objection that stricter parsing made it harder for hobbyists. In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.

I never understood that either except, as you said, for the hobbyist's sake. A lot of XHTML was generated from XML and, if one is using XML, chances are programming is involved in the transformation to XHTML. But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML.

People underestimated the extent to which markup may be mixed in from sources you didn't control, and the power that this ability gives to your users. Say you built a shiny new forum engine with from-scratch XHTML markup. You try to sell it. Most of your customers say that they've already been running forum software since 1995 but the existing posts allow inline HTML (which was less unsafe in 1995, because no Javascript), which is all badly misnested. As soon as they dump the previous data, their site stops working.

Or you import a small Javascript library from 1999 that generates its own innerHTML for a few elements, but does it with HTML. Oops.

Or you built a new CMS with shiny XHTML markup, but before you had the CMS your org just hand-wrote pages which you now need to parse and import into the CMS.

These were all very real considerations in the 2002-2004 period; I've dealt with all of them. Backwards compatibility is often the most important feature you can offer, because it directly affects the value the end user gets out of the product. Sites that were concerned with "doing it right" in that time period largely failed, while sites that "did it fast" in a hacky, XSS-prone way are now worth hundreds of billions of dollars.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#175

Post by chachachoney »

devit wrote: post #173
userbinator wrote: post #52

Earlier quoted context omitted.

This obsession with "living" and constant change seems to be mostly confined to the web --- instead of settling on a spec and then leaving it alone and "doing what you can with what you have", those working on this stuff seem more inclined with continuing to make browsers change. I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly, keeping out competitors, given who the…

All the browser engines and most browsers are open source, so making them harder to implement does not "feed the monopoly".

That's a bit of an oversimplification.

The Electronic Frontier Foundation resigned from the W3C for a reason.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#176

Post by lucideer »

lstamour wrote: post #160
lucideer wrote: post #144

Earlier quoted context omitted.

> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).

You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. And that even "static HTML" requires accessibility improvements and adaptations to new device types. For example, split screen phones, where you've a mobile device that starts at one size, but then can open up to a larger size. Tiny watch apps,…

> You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead.

"giant bundles of JavaScript" weren't how we shipped the web before the HTML5 process began. The solution to "we're loading too much overengineered bloated redundant logic over HTTP" isn't "lets bundle all of that logic", it's "stop overengineering simple webpages".

> even "static HTML" requires accessibility improvements and adaptations to new device types

Accessibility standards predate and are still external to HTML5, and have actual fixed specs. They're relatively simple to implement from a parser perspective, and individual tools implementing functionality on top of that are ancillary to mainstream browsers. The only exception here is support for things like MSAA, etc. and that's also completely separate to HTML5 et al.

You go on to list a bunch of CSS stuff (again, some pre-dating HTML5, none coming from WHATWG), proprietary browser settings (not a part of any spec, living or static).

> better support for print media

Now this would be great to see. However this is something we definitely have not gotten since the advent of HTML5. What are you referring to here?

CORS pre-dates HTML5 (was later subsumed into HTML5), but the newer auth APIs you mention are nice; I'll give you that.

Things like IntersectionObserver however are one perfect example of extra feature-creep in HTML5, building hacks on top of an ecosystem overrun with overengineering. You should not need IntersectionObserver to get basic, usable performant scrolling. If you feel you do, you've overengineered your webapp: try actually addressing your performance bottlenecks.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#177

Post by lucideer »

hiccuphippo wrote: post #172
lucideer wrote: post #144

Earlier quoted context omitted.

> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).

The Web Authentication standard [0] seems super useful and something we really need in the web. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...

Yeah, this is pretty great. It's also comes from the W3C, not the WHATWG.

(it might be a bit lost in the hierarchy of the thread by now, but the original comment was about the WHATWG taking over and monopolising the normal considered and democratic standardisation process of the W3C with their HTML5 "living" spec.)

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#178

Post by pbhjpbhj »

cygx wrote: post #76
pbhjpbhj wrote: post #64

Earlier quoted context omitted.

Tabular markup for non-tabulated data is not rational & semantic markup is certainly not irrational. You don't come from print design by any chance? With flexbox, for example, you can change order of appearance contrary to the code order in the markup. It's not a mirage. Anyone who's used a browser's reader mode, or distilled view (as Brave calls it), knows the usefulness of applying different styles to a fixed marku…

You don't come from print design by any chance? You've not been doing that whole web design thing for very long, by any chance? Those of us who have been around for a while do remember the inadequate layouting capabilities of CSS of bygone eras. While I was on the semantic markup side of the debate at the time, it's not as if the pragmatists that just went with the table for convenience's sake did so for no reason at…

I started web design for lynx browser, back when using pine for email was hot, then moved on to Mosaic and NN.

There's a clear body of web design/dev people that think it's just a visual display medium, and a lot of those seem to come from print design.

The web for me has always been primarily a medium for information transfer, visual design is nice but not at the expense of semantic markup; table markup for visual layout is entirely unnecessary (and was terrible for accessibility).

People went with table layout because marketing people demanded pixel matched presentation and/or they didn't care to make sure their content was machine readable. The same views lead to IE only and give us websites that don't bother with semantic blocks now, or that don't work without JavaScript when that js is just being used for presentational flair.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#179

Post by duskwuff »

kijin wrote: post #152
ChrisSD wrote: post #9

I still maintain that the "living standard" is an oxymoron. It's a collaborative browser dev document. Don't get me wrong, that's great. However for everyone else an unversioned document, any part of which can change at any moment, is not what's usually thought of as a standard.

I don't mind a changing standard as long as two people can agree on exactly which version of the standard they're talking about and actually use that version. I should be able to build my web app against an LTS version of the standard and expect it to behave identically in all future versions of all major browsers, until the EOL date of said version, no matter what changes they make in future versions. I want this fo…

> Unfortunately, the whole HTML 5.1/5.2/5.3 business never quite caught on...

Because that was an artifact created by W3C by taking snapshots of the WHATWG HTML5 standard and making arbitrary changes to portions they didn't agree with. Since the WHATWG standard was already considered normative by most browser makers, the influence of the W3C's "standards" work here was essentially nil.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#180

Post by mrguyorama »

mynegation wrote: post #114
austincheney wrote: post #79

Earlier quoted context omitted.

> I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly That is far too grand a motive. The reality is that the average web developer has a shelf life of about 5 years or is primarily focused elsewhere, such as Java or C#. That said consider the people who do this work with 100% focus. These people are typically not the same developers who are performing graduate level st…

You are already downvoted into oblivion and rightfully so, but I just wanted to add my perspective as a backend developer (and the one who did post-graduate level mathematical stuff at that) who now manages a team of back and front end developers and plays with front end development for toy projects. The sheer amount of complexity and required knowledge for front end development is simply baffling to me. These folks…

>The sheer amount of complexity and required knowledge for front end development is simply baffling to me

99% of it is self-inflicted though. You didn't need react/redux/sagas/uber popular framework 7.5 to do your job, but you and your coworkers thought "This is the cool new toy that facebook made!!!! Let's use it!!!" When 90% of web sites are reinventing a wheel made in 1994, there's no reason to actually do most of this junk

Post reply on HN