Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec • Hacker News Board

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#251

Post by BinaryIdiot » Fri, Apr 13, 2018, 6:49 PM UTC

dragonwriter wrote: post #186

chrismorgan wrote: post #114

Serious question: why are the W3C still publishing or trying to publish standards for DOM and HTML and probably a few others, when no one that matters cares about them? Why not rather throw in the towel on those particular standards and acknowledge that the WHATWG has won on them?

> Serious question: why are the W3C still publishing or trying to publish standards for DOM and HTML and probably a few others, when no one that matters cares about them? There is a potential legitimate role for the two-track approach, if WHATWG represents a moving target of what browser vendors have agreed to implement and essentially is the vehicle for documenting hmthe agreed future common web platform, and W3C pr…

I don't really understand how this would make the two-track approach legit. Couldn't they just version the specification under WHATWG if that's what they're after?

I just can't see a reason for the W3C to be handling any of this anymore except for money reasons.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#252

Post by kuschku » Fri, Apr 13, 2018, 6:55 PM UTC

hsivonen wrote: post #222

kuschku wrote: post #187

Earlier quoted context omitted.

And wouldn’t it have been easier to write it without any of the leniency it has to expose? Wouldn’t it have been easier if all tags were either ending in /> or followed by a closing tag? Wouldn’t it have been easier if the syntax was formally defined as ABNF, and could be translated into code in a matter of days? I believe it would have been. And I believe that making the web easier machine readable, and making it ea…

> Wouldn’t it have been easier if all tags were either ending in /> or followed by a closing tag? Not really. > Wouldn’t it have been easier if the syntax was formally defined as ABNF, and could be translated into code in a matter of days? No, working from an spec written as an algorithm is easier than working from ABNF plus some inconvenient prose constraints. (With the exception of template element support, I wrote…

> No, working from an spec written as an algorithm is easier than working from ABNF plus some inconvenient prose constraints.

That sounds very unlikely.

I’ve implemented my own parsers for countless specs – plaintext or binary, and the parsers that are written as imperative algorithms are insanely complicated to implement as functional implementations.

I end up with horrifying code, while the specs written as ABNF are much easier to translate into pattern matching code.

The specs written as algorithm only work fine for a single type of implementation IME, while the ABNF specs work equally well for all types.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#253

Post by s2g » Fri, Apr 13, 2018, 6:57 PM UTC

dragonwriter wrote: post #180

scarface74 wrote: post #62

We know that Apple, Google, Microsoft, and Mozilla, consider the WHATWG to be the canonical version. We don't yet know whether the other 450+ W3C member organisations that represent the wider web platform agree with this position or not though. Honestly, do the other 450+ W3C member organizations matter? ( https://www.w3.org/Consortium/Member/List )

> Honestly, do the other 450+ W3C member organizations matter? Well, the four objectors are responsible for browser engines that cover somewhere between 95 and 99+% of browser usage, depending on which set of stats you use and whether you count other browsers that have Chromium or Firefox upstream, including the system browsers of every major mobile and desktop OS. So, no, in practice if those four agree on something…

Hurray for the oligarchy.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#254

Post by kuschku » Fri, Apr 13, 2018, 6:57 PM UTC

tptacek wrote: post #30

kuschku wrote: post #23

Earlier quoted context omitted.

> I'd say the W3C wasted a huge amount of time pursuing quests of purity (XHTML) over actually making the web better for users. I see the value in what they were trying to do, but it wasn't letting people do the things they wanted to do on the web. Okay, let’s make a deal: We both write a crawler that can fully reliably parse websites. I implement XHTML1.1, you implement HTML5. We both get 1 month time. What do you t…

The HTML5 person's crawler will parse some significant fraction of real websites, and the XHTML one won't, because people write HTML5 and not XHTML, even if you as a tool vendor would greatly prefer otherwise.

And yet, forcing people to implement opengraph tags, forcing people to drop flash, forcing people to use HTTPS, forcing people to drop Symantec certs, forcing people to drop SHA1 certs – so often the actors behind the WHATWG have managed to get website authors to change what they use.

Hell, Google has AMP, which is far more intrusive than XHTML ever was, and yet, they’ve managed to get every major website to implement it. https://www.ampproject.org/docs/troubleshooting/validation_e...

And yet, somehow, implementing some stricter spec is supposedly impossible?

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#255

Post by dragonwriter » Fri, Apr 13, 2018, 6:58 PM UTC

jsgo wrote: post #236

da_chicken wrote: post #194

Earlier quoted context omitted.

If you fork an existing rendering engine, you're rather implicitly using a WHATWG DOM. In order to use W3C DOM 4.1, you'd either have to modify a WHATWG DOM renderer into a W3C DOM 4.1 renderer -- which is a bit like starting with the emacs source to build a vim clone -- or to build your own. The inertia of forking an existing project pushes you towards the WHATWG implementation, not W3C. That's the point of forking.…

If that's the case: 1a) Why would it matter that Microsoft, Google, Mozilla, and/or Apple object to W3C DOM 4.1 if they don't implement it? 1b) Why would Microsoft, Google, Mozilla, and/or Apple care enough to object to W3C DOM 4.1 if they aren't implementing it? Why would they even give any effort to a competing specification and just allow it to die from inactivity? 2) Why does what is in W3C DOM 4.1 matter if the…

> Why would it matter that Microsoft, Google, Mozilla, and/or Apple object to W3C DOM 4.1 if they don't implement it?

It matters to the utility of the W3C DOM spec that it doesn't represent either what browsers have implemented or what they will implement.

> Why would Microsoft, Google, Mozilla, and/or Apple care enough to object to W3C DOM 4.1 if they aren't implementing it?

They care enough because they want the W3C, if it is going to write purported web standards, to do something that won't confuse developers and lead to browser vendors fielding complaints from developers who mistake useless W3C documents for something meaningful.

> Why would they even give any effort to a competing specification and just allow it to die from inactivity?

They don't want to have a competing specification, though they do not seem opposed to having a specification with a different focus but consistent with WHATWG to the degree dictate by the purpose.)

> Why does what is in W3C DOM 4.1 matter if the high 90s percentage of users are served by a browser in the WHATWG DOM camp?

The idea is not to have opposing camps, though if W3C insists on making it an opposing camps situation, thst becomes a real issue.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#256

Post by kuschku » Fri, Apr 13, 2018, 6:59 PM UTC

TheOtherHobbes wrote: post #112

smaddox wrote: post #29

Earlier quoted context omitted.

That seems reasonable to me. Would you want your programming language to compile code that has a syntax error?

Web pages are information held inside containers, not code. The analogy is a classic example of the "Everything must act like a compiler" fallacy. There are many situations in which compilation is hopelessly inappropriate as a user model. Not only is the web one of them, but the hypothetical semantic web is also one of them. You can't force semantics into compilable tokens. The suggestion that you can - and should -…

I’ll remind you that the AMP spec has an extremely strict validation requirement: https://www.ampproject.org/docs/troubleshooting/validation_e...

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#257

Post by colanderman » Fri, Apr 13, 2018, 7:01 PM UTC

dragonwriter wrote: post #205

colanderman wrote: post #78

Earlier quoted context omitted.

> The WHATWG has always opposed the W3C's spec. They see it as confusing to have two "official" specifications. As the old joke goes... if it hurts, they should stop doing that! The WHATWG spec is worse than useless to me as a developer. It's impossible to tell what is usable and what is just Google's wishlist (which is about half of it). The MDN has entirely replaced it for me, since they at least do a good job of d…

> The WHATWG spec is worse than useless to me as a developer. It's impossible to tell what is usable and what is just Google's wishlist (which is about half of it). The MDN has entirely replaced it for me, since they at least do a good job of documenting reality. The WHATWG living standard is largely where browser vendors (and other interested parties) work out what the web will be. W3C (with their implementation req…

I agree with everything you said. What rubs me the wrong way about the WHATWG is that they give the perception (and it may be just that) that they are trying not just to serve as that forum for browser makers, but also as the standard reference for web developers (which is the role the W3C HTML specs, save XHTML 2, have historically served), and doing a poor job of the latter.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#258

Post by wink » Fri, Apr 13, 2018, 7:02 PM UTC

hsivonen wrote: post #204

lucideer wrote: post #153

Earlier quoted context omitted.

> This simply is not true. The web moved to an XHTML-like dialect of HTML You're thinking of XHTML 1.1 or XHTML 2. That "XHTML-dialect" that everyone switched to was called "XHTML 1.0", which allowed serving as either content type. If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being serv…

> If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being served as valid HTML5. Completely different thing. XML processing and all reasoning based on the premise of XML processing are fiction when XHTML is served as text/html. The HTML parsing algorithm and tve rest of the processing requir…

Because someone asked and it explains some of the history quite nicely.

FWIW, maybe I'm the 1% but I wrote valid XHTML 1.0 for a while, but also soon gave up :P

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#259

Post by ubernostrum » Fri, Apr 13, 2018, 7:02 PM UTC

gfo wrote: post #117

ma2rten wrote: post #105

Earlier quoted context omitted.

It's interesting that a formal objection is done by creating an issue on github.

A sign of the times perhaps? It makes sense given the repository, but of course, it does make it challenging to verify the authenticity of the request when, for all we know by looking at the messages, they could be random users.

Any group discussion could be "random users" to an outsider. To people at W3C, or even to people who just follow web standards development, the names are pretty instantly recognizable, and presumably since these accounts have been added to the W3C's GitHub org, W3C feels confident that they are who they claim to be.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#260

Post by duskwuff » Fri, Apr 13, 2018, 7:02 PM UTC

xtian wrote: post #122

Sharlin wrote: post #107

Earlier quoted context omitted.

> Most of the web quickly moved to XHTML. This simply is not true. The web moved to an XHTML-like dialect of HTML which was still served as text/html and browsers interpreted it as "HTML soup" because actually serving pages as application/xhtml+xml would have broken the majority of the web because browsers would actually validate them and refuse to display a page at all if there was even a single missing close tag.

And the versions of IE in use didn’t support application/xhtml+xml anyway so you would have to switch to text/html based on the user agent string. It was never clear what the technical benefit of this was supposed to be. I only ever saw one site whose pages served double duty as an API and UI by serving styled XML. It seemed like a challenging approach to pull off well.

The shoe web site skechers.com used to do this. With the removal of XSL support from browsers, though, it looks like it's now using some form of JS templating.