W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM • Hacker News Board

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

#111

Post by domenicd » Tue, May 28, 2019, 1:39 PM UTC

klez wrote: post #30

danarmak wrote: post #23

Earlier quoted context omitted.

But no browser maker recognizes the W3C standard or claims to implement it, so what good is it?

That no browser maker recognizes W3C's standard is a bit misleading. MDN (i.e. Mozilla) quotes the w3c recommendations all over the place. Google, from what I found around, cites nothing, not even WHATWG. Webkit cites MDN (which cites w3c) as a source.

The W3C citations on MDN are a historical artifact by the documentation folks, not influenced by the browser folks. There's a slow movement to consolidate around what's implemented and stop referencing W3C forks, and I think today's news will help hurry that along. See e.g. the discussion in https://github.com/mdn/kumascript/issues/1019 or my previous work in https://github.com/mdn/kumascript/pull/220.

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

#112

Post by kevingadd » Tue, May 28, 2019, 1:43 PM UTC

_bxg1 wrote: post #100

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…

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in. - HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (…

"not breaking" is an aspirational goal, not remotely a fact. When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) they have to run live experiments to gather data on how many commonly-visited sites use a feature they're going to change or a quirk they're going to remove. Typically if the value is like 1% or above the change is killed unless it can be made compatible, but they will go ahead even if it's over 0%. 1% may sound small to you, but web browsers are used by like... a billion people? More? And 1% of a billion is a pretty sizable number of people.

Pretend if you want, your stuff will probably break eventually. If it's simple enough it won't break and then you can go on with your life - that's certainly the goal of browser developers.

At the moment you start using the DOM or other JS APIs exposed by browsers the odds of your stuff breaking in the next decade go up, especially if you're using things that aren't like 5-year-old parts of the spec. The shelf life of most JS-heavy webapps is like 2 years in my experience.

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

#113

Post by [deleted] » Tue, May 28, 2019, 1:44 PM UTC

_bxg1 wrote: post #100

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…

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in. - HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (…

[deleted]

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

#114

Post by mynegation » Tue, May 28, 2019, 1:44 PM UTC

austincheney wrote: post #79

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…

> 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 have to know such disparate technologies as CSS, HTML, Javascript as a bare minimum and it never stops there. Typescript, templating engines, CSS preprocessors, huge and continuously evolving javascript ecosystem, evented concurrency (please take me back to my threads and semaphores), asynchronous state management in complex UIs with non-trivial interdependencies... Compared to this stochastic calculus is a breeze.

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

#115

Post by kevingadd » Tue, May 28, 2019, 1:45 PM UTC

nicoburns wrote: post #37

baybal2 wrote: post #18

Earlier quoted context omitted.

It isn't great at all, because even that living standard is never being implemented up to spec, often by the same people who wrote it, and the current browser support status usually ends up being "what's written in bugzilla"

There are very comprehensive browser support matrices at https://kangax.github.io/compat-table/es6/ (JavaScript features) and https://caniuse.com/ (DOM features). It's only for very recently implemented features that you should need to look in bugzilla.

"should", sure, but vendors (I mostly run into this w/Chrome but other vendors do it too) happily just ignore the spec because it's inconvenient and sometimes explicitly have no plans to ever align with it. I recently ran into a case where Chrome was intentionally moving away from the spec without making any effort to update the spec, because being correct was... annoying. Not impossible or bad for users, just annoying.

At the time the behavior worked right in Firefox and Edge but now that Chrome is going to ignore the spec I suspect the other vendors might too. (For reference, it was an issue related to the lifetime of javascript objects for frames that have been unloaded or navigated)

This sort of thing will never appear in a compatibility matrix. You find out when it breaks your code.

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

#116

Post by ChrisSD » Tue, May 28, 2019, 1:48 PM UTC

vorpalhex wrote: post #103

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.

Hopefully those aren't in contrast to each other. You can have a living document that gets consistent updates AND still has meaningful versions, much like a lot of well developed software. The goal is for the time between HTML versions to not be a decade, but instead for consistent, incremental improvements without browsers trailing behind for years. At the same time, these should (hopefully) not be breaking changes.

Sure. IMHO one solution might be to have a HTML standard specification that is stable, which can then be built on. Extensions can be proposed so long as they don't break the standard. This would allow new elements and attributes to be introduced before they are themselves fully stable, as they are now. Breaking changes would require bumping the spec to a new major version and should happen only rarely.

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

#117

Post by kevingadd » Tue, May 28, 2019, 1:49 PM UTC

inglor wrote: post #58

In practice I've found that web standards are mostly driven by people who are willing to spend the time and effort to iron our all the edge cases. I've had a very pleasant experience contributing to things like `fetch` and negative experiences contributing to some other things - essentially it's a "people problem" more than a technology problem.

I find the pleasantness of the standards process depends on how many people have strong opinions about the thing you're working on. Being involved in 'new' standards like fetch or gamepad or webgl is generally pretty relaxed because while it's interesting to many people, there aren't a bunch of people with Past Experience with the new api/standard and they aren't about to dedicate a bunch of time to doing it themselves.

Coming in to try and fix problems or propose improvements for existing stuff like canvas or XHR or whatever is another matter entirely, as you've probably noticed. Thanks for helping make fetch good!

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

#118

Post by _bxg1 » Tue, May 28, 2019, 1:50 PM UTC

kevingadd wrote: post #112

_bxg1 wrote: post #100

Earlier quoted context omitted.

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in. - HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (…

"not breaking" is an aspirational goal, not remotely a fact. When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) they have to run live experiments to gather data on how many commonly-visited sites use a feature they're going to change or a quirk they're going to remove. Typically if the value is like 1% or above the change is ki…

I'm really not sure what kind of changes you're talking about. They certainly don't do what you describe at the API level. Maybe you're just talking about bugs? I have encountered a few browser regressions over the years but they're always for really exotic use-cases of relatively new APIs, and they always get fixed in the next release. I've been working on a suite of highly complex JS-heavy tools for the past 2.5 years, and the problems that have stemmed specifically from browser bugs in that time are a vanishingly small number. Probably less than five.

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

#119

Post by bzbarsky » Tue, May 28, 2019, 1:50 PM UTC

kevingadd wrote: post #112

_bxg1 wrote: post #100

Earlier quoted context omitted.

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in. - HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (…

"not breaking" is an aspirational goal, not remotely a fact. When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) they have to run live experiments to gather data on how many commonly-visited sites use a feature they're going to change or a quirk they're going to remove. Typically if the value is like 1% or above the change is ki…

1% is _way_ higher than the acceptable breakage thresholds I've seen browsers use. Usually it's more like 0.003% or less.

This can still be a significant number, of course...

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

#120

Post by egeozcan » Tue, May 28, 2019, 1:51 PM UTC

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…

Totally agree. Also: I'm strongly against calling people "Front-End Developer" or anything like that at all. Where does front-end start? Where does it end? What is full-stack, does it imply you can do embedded? I've seen many listings that count PHP as one of the front-end requirements. This is just a term that should make the HR's job easier, and it does that badly.