Live data from Hacker News

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

w3.org

241–250 of 287 posts

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

#241

Earlier quoted context omitted.

Also, XHTML 2 tried to push people to tags with defined semantics like ARTICLE, SECTION, MENU, etc. Most of the tags exist now in HTML5, but their semantics were neutered in the transition.

If properly implemented tags like that would make stuff like Firefox Reader Mode a breeze to develop, but also easy to subvert. But it undoubtedly makes development harder. Web Developer 101: Section 1: This 20 page list of categories and their strict formal definitions.

It doesn't really make development harder, because the semantic tags are defined based on properties that aren't visible to a parser. So it doesn't matter whether you use them correctly -- no validator will be able to tell.

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

#242

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…

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

This times a million.

And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about:

New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be.

The various new input types and attributes. Now you can have input fields which validate email addresses and phone numbers, present the right keyboard for the type of input you want, do various other validation checks or even provide things like a nifty date picker without JavaScript.

Picture and srcset too. No more having to load giant images on mobile devices or have blurry ones on devices with retina support, you can choose which image displays on which type of device.

The preload attribute and what not. Being able to load content the user will likely need in the background is helpful.

The built in video and audio elements, obviously. Again, object was a terrible solution for this, which was unsemantic, was awkward to use and struggled in certain browsers. These elements don't.

The canvas tag and things you can do with it.

And this will be a controversial one, but... most of the old elements that were made official by 'paving the cowpaths' were nice to see added too. The whole fiasco involving embed/object in the old days and how supporting multiple browsers meant invalid HTML was a bit of a farce really, especially as neither were particularly 'semantic' to begin with. Seeing them both made official and better alternatives provided just puts a lifelong issue at rest.

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

#243
post #164

To clarify why WHATWG exists and why W3C lost power over the HTML spec: Around 2004 W3C abandoned organizational effort on HTML in favor of things like XHTML2, XEvents, semantic web, etc. The WHATWG was formed in reaction to that, rewriting HTML completely from its W3C HTML 4.0 version for example to make it better for web applications and to specify things in more detail. Since the formation of WHATWG, W3C HTML spec…

That explains the HTML spec but not the DOM spec.

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

#244

Earlier quoted context omitted.

Yes. It was your outliner I was thinking of, not a validator but weren't you involved with the original http://validator.w3.org/nu/ at least in part? I, too, served my web pages as "real" xhtml 10 years ago and loved it :)

Promise I've never worked on a validator!

Well, now I have to rewrite my book :)

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

#245
post #242

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…

This times a million. And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about: New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be. The various new input types and attributes. Now you can have input…

if only all of those things were fully flushed out in the various browsers... for instance, it disheartening to realize that it's been 15 years already and useful form elements like date(-time), phone, and email still don't have reliable and complete cross-browser behaviors, validation (i know it's hard, but still), and styling/event hooks.

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

#246

Earlier quoted context omitted.

> 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 accountabl…

> WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance I don't think that's a fair characterization at all. Ian Hickson was pretty intimately familiar with the SGML formulation of HTML. What led to that being dropped was that no browsers implemented it in practice and that trying to implement it as written in the HTML 4 standard actively broke web pages (which had been written aga…

> That is a good point, yes. Arguably it should have been left in as a void element with no behavior to avoid parsing issues of the sort you describe...

That's what we did, actually :). Parsing behavior was unchanged. Ctrl+F "keygen" in https://html.spec.whatwg.org/multipage/parsing.html.

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

#247
post #173

Earlier quoted context omitted.

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.

What reason?

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

#248

Earlier quoted context omitted.

That's a bit of an oversimplification. The Electronic Frontier Foundation resigned from the W3C for a reason.

What reason?

Probably the introduction of DRM so Hollywood would start using video tags instead of flash/silverlight/other plugins. It’s a pragmatic approach, but right now it’s incredibly limited for anyone who wants to make their own browser that can load Netflix.com, for example. The only folks DRM punishes are those trying to do the right thing, everybody else can find workarounds if they need to.

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

#249
post #173

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

The fact that the source is open doesn't say anything about difficulty of implementation; in fact, being open-source probably increases the monopolising effect, since now people will be more inclined to think "that implementation is open-source, I'll just use/contribute to it instead of starting another independent one."

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

#250
post #227

Earlier quoted context omitted.

I don't think that is a fair analysis. Firstly, much of the complexity is an emergent property of interaction between a spec and reality: the engineering choices developers make when implementing a spec. Pixel examples: (a) mitering of borders, (b) sizing four 25% width divs within a 99px div. Pick just about any old spec, then look at the corner cases where developers have discovered different browsers act different…

> Firstly, much of the complexity is an emergent property of interaction between a spec and reality: the engineering choices developers make when implementing a spec. Ah, clearly that makes it easier for third parties to maintain browsers. Or, wait, no -- that's yet another way to push players that don't have hundreds of millions per year worth of funding. > Chrome mostly works better, follows specifications faster,…

I'll bite: do you think that Chrome is some sort of conspiracy??

I also don't like how Firefox, Safari and Edge have failed to compete with it, especially because I don't like that Google slurps so much private information. I wish Opera could have continued to compete as I loved the underdog for years.

If it were just a problem of marketing, I could be upset. However technically the Chrome team is just totally obliterating competitors by just being technically so much more competent and also providing features. Features that developers and consumers want: as a web developer I see Chrome kill the other browsers on metrics I care about such as bugs fixes, adding features that are relevant to my development, development tools, etc; As a Chrome user, Chrome mostly trounces the other browsers on security, speed, etc (Safari does win on some metrics on closed iOS and macOS).

Mozilla, Apple, and Microsoft are not poorly funded - they are just being beaten for what are mostly technical reasons (relatively slower, unreliability, wasting time on low-value features).

On topic: Chrome implements many standards it didn't create far better than the other browsers. Browse through the list at https://wpt.fyi/results and see that Chrome has better scores for IndexedDB (I think created by Firefox); better scores for offscreen-canvas and orientation-sensor (I think created by Apple).

A great example: Firebug which was created outside[1] of Mozilla and fantastic at the time. Good developer tools draw in plenty of developers, and help make sure they test everything on your browser. Chrome Dev tools overtook it in every way I cared about: reliability, features, inbuilt F12, remote debugging, async stack, etc. Now developers use Chrome because this massive feature is so much better, and why blame the developers for using the tool that makes their job the easiest?

PS: I didn't downvote you - someone else must have disliked the way you answered.

[1] https://hacks.mozilla.org/2017/10/saying-goodbye-to-firebug/

Post reply on HN