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

#261

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

bad_user wrote: post #179

tptacek wrote: post #94

Earlier quoted context omitted.

The lineage of the rendering engine doesn't matter. What gives Apple and Google and Microsoft command of the standard is the fact that they mediate access to web pages; they own th actual customers. That's what matters.

Nonsense. Web standards are supposed to be de jure, not de facto. Once upon a time Microsoft had 90% of the browser’s market. We created web standards in order to prevent monopolies, such as the former IExplorer, from holding the market hostage. That’s the whole reason behind web standards . And yes, they matter even with an IExplorer that has 90% market share, because governments can and do enforce adherence. That’s…

Web standards are supposed to be de jure, not de facto.

HTML5, in large part, was created to do exactly the opposite -- formally set down in writing all the de facto quirks of HTML as actually used, parsed and rendered in the real world, instead of continuing to prescribe behaviors which didn't match observed reality.

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

#262

Post by apaprocki » Fri, Apr 13, 2018, 7:07 PM UTC

Ajedi32 wrote: post #242

klez wrote: post #211

Earlier quoted context omitted.

So could I. I mean, I see what you mean, but to a casual observer that's not very clear.

GP is referring to the "Member" badge next to the commenter's name, not to any claims made in the comments themselves. You could claim to be a member of the W3C, but unless you actually are that badge won't show up next to your name in the issue tracker.

The GitHub org member list is not going to be an authoritative list of all delegates from all members that all have GH accounts. One of our W3C participants conveyed our objection and he isn't in the GH w3c org member list.

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

#263

Post by kuschku » Fri, Apr 13, 2018, 7:08 PM UTC

hsivonen wrote: post #219

olavk wrote: post #70

Earlier quoted context omitted.

As far as I know, WHATWG have deprecated some elements not widely used (like "isindex", "font"), but the documents using these elements will still be readable even if not exactly as the author intended. Moving to XHTML, on the other hand, would make billions of pages totally inaccessible. There are people who are now dead who have pages on the internet. These pages will never be updated.

font still works. isindex does not. It's extremely rare for a cross-browser HTML element to get removed but isindex is one of those.

blink also doesn’t work anymore, and neither does marquee. Several of the frame attributes are broken as well. noscript doesn’t always work reliably depending on browser.

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

#264

Post by kuschku » Fri, Apr 13, 2018, 7:09 PM UTC

Analemma_ wrote: post #90

kuschku wrote: post #22

Earlier quoted context omitted.

That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website. But if you actually try to write a new browser from scratch, or a tool to scrape websites, you’ll learn to love XHTML, and hate HTML5. The same that applies with human languages applies here as well. Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thous…

You keep repeating over and over that the big advantage to XHTML is "not having to run headless browsers", which I don't understand. I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience, and it's definitely not worth getting rid of HTML5 to abandon it, when, as others have pointed out and you keep ignoring, the practical effect would be that t…

> I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience,

Try running hundreds of tests at the same time, to actually get fast results when running a full test suite.

Right now running a small testsuite takes here over 2 hours, 99% of the time is spent in the browser processes.

And that’s not nearly close to 100% test coverage.

> not worth getting rid of HTML5 to abandon it

You don’t have to – XHTML isn’t the only strict spec out there, AMP is another, React also enforces strict syntax in JSX templates. AMP fails to render anything if there’s even a single mistake, React fails at build time.

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

#265

Post by lambda » Fri, Apr 13, 2018, 7:10 PM UTC

_fq4v wrote: post #233

lambda wrote: post #195

Earlier quoted context omitted.

Not if that You can apply mandatory quoting to untrusted input all you want, but there are going to be times when you have trusted strings that can still contain stray characters that will make the resulting markup invalid. And in many cases you don't want to have mandatory quoting for all of that, because these strings may have markup you want to include. And yeah, you can argue that instead of generating content by…

To be fair, I only use obscure type-safe functional programming frameworks. That's what I'm employed to do, and this obviously impacts my feelings on the matter. Personally, I think it's irresponsible to use anything that could be this unsafe. This doesn't mean everyone needs to use FP, just that frameworks and libraries should be chosen so as to guarantee safety. There are easy-to-use libraries for all these things…

I agree with you that we do need to do better about writing more robust software, and type safe languages are a good way to do that.

But what you're saying is as if you suggest that since the metric system is more consistent and more widely used than the English, I as a bolt distributor should start selling my bolts in metric sizes, despite the fact that the nuts that everyone has are in English sizes.

The browser vendors, at least, are working on implement their browsers in more type-safe languages (https://github.com/servo/servo), but even still they have to work with the content that is produced by thousands of different languages, frameworks, and tools, and millions of hand written HTML files, templates, and the like. Just turning on strict XML parsing doesn't make that go away, it just makes your browser fail on most websites.

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

#266

Post by domenicd » Fri, Apr 13, 2018, 7:10 PM UTC

BinaryIdiot wrote: post #251

dragonwriter wrote: post #186

Earlier quoted context omitted.

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

In fact, we already do publish commit snapshots for every change we make: https://dom.spec.whatwg.org/commit-snapshots/

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

#267

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

lucideer wrote: post #228

jerf wrote: post #212

Earlier quoted context omitted.

OK, so by lucideer's quirky definition of "XHTML", the vast majority of the web moved to XHTML. Based on the expansiveness of lucideer's definition, this appear to have encompassed web developers who probably weren't even aware they were writing "XHTML". By the definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes, to a first approxi…

> by lucideer's quirky definition Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. > definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes Which, again, is the definition used in the later w3c xhtml 1.1 & 2 specs, the former which wasn't widely use…

Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me.

Except that the number of people who actually implemented valid, well-formed, properly-served XHTML Strict -- of any version -- in compliance with all the relevant specifications is at best vanishingly tiny. XHTML Transitional was tag soup.

Your retort further up about many sites serving invalid HTML5 actually works against you, since HTML5 explicitly has a forgiving parsing model, while XHTML is explicitly "every error is a fatal error". If browsers had enforced the XHTML approach on every document using an XHTML DOCTYPE, we would have seen the death of XHTML much earlier.

This is why people say XHTML was never really adopted -- many people certainly put a "/>" to close their empty elements, and stuck an XML prolog and an XHTML DOCTYPE up at the top, but surveys like the infamous "XHTML 100" showed that next to nobody actually adopted XHTML in a manner compliant with the relevant standards.

And I say this as someone who, way back in the early 00's, was serving valid, well-formed XHTML as application/xhtml+xml. XHTML was a terrible approach, and the W3C process was dragging farther and farther from practicality at every revision (remember XHTML 2.0?).

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

#268

Post by domenicd » Fri, Apr 13, 2018, 7:12 PM UTC

c-smile wrote: post #237

colanderman wrote: post #178

Earlier quoted context omitted.

Thanks. The TL;DR seems to be that, instead of sticking to documenting what is , the W3C is (either deliberately or through incompetence) trying to push their own "vision" for DOM 4.1 without browser buy-in.

That does not mean that it is a good thing to put all bells and whistles from different browser vendors under the same umbrella. Let's say you are a) owning and b) managing a project that three competing teams are working on in parallel. If you will not curate the project you will have one team adding and another team adding ... In real world you would invite dedicated architect or team of architects to define the sp…

This information about how the WHATWG works is somewhat outdated; please see https://whatwg.org/faq for more.

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

#269

Post by lonnyk » Fri, Apr 13, 2018, 7:12 PM UTC

solarkraft wrote: post #230

dragonwriter wrote: post #180

Earlier quoted context omitted.

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

Remember that Apple just implemented the Canvas tag. If you implement something good perhaps almost none of the W3C member organisations matter in pushing something.

Can you explain what you mean? According to caniuse[1] it has been supported for a while.

[1]https://caniuse.com/#feat=canvas

*EDIT I misread the parent. I didn't put the context for that paragraph together and read 'just' as in 'right now' instead of 'just decided to'.

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

#270

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

lucideer wrote: post #164

ChrisSD wrote: post #61

Earlier quoted context omitted.

I'm not certain that it's true to say most of the web quickly moved to XHTML. Sure a number of sites advertised themselves as XHTML but they were not strictly XHTML compliant. This could be due to third party widgets or other included code or it could be due to a mistake in template construction. Whatever the issue fully compliant XHTML wasn't used much in practice outside of hand-crafted pages. Also Internet Explore…

> they were not strictly XHTML compliant The vast majority were not strictly XHTML compliant, but whatever the figure was, I'd imagine it wasn't too different to all the many "strictly HTML compliant" sites now (compliant according to which commit?). The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. E…

The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to.

I'm honestly trying to figure out whether this is satire or not.