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

201–210 of 287 posts

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

#201

Post by [deleted] »

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…

[deleted]

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

#202

Post by stephenr »

Sargos wrote: post #197
stephenr wrote: post #191

Earlier quoted context omitted.

They're not doing anything to "harm" them, they created both of them, and both specs basically include a caveat that says "this could be mis-used, but YOLO".

So you're against the standards entirely? What is the alternative that you favor? If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? WebUSB gives us an option of doing it in a seamless and maintainable way.

> If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain?

So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again, like they did last year?

Sounds like a winning strategy my man.

Edit: to answer your original question > So you're against the standards entirely?

Yes. Literally the only reason either exists, is because without them Google's theory of "everything can be in a browser" falls flat on it's face, and when things are in a browser Google has a good chance of controlling the conversation (the same way Microsoft controlled the conversation in the 90s and early 2000's with Windows).

Both specs have glaring security issues that they themselves point out, but then provide no actual solution or work around for. They may as well start each one with "this could lead to compromise of your device.. life's a lottery, be lucky!"

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

#203

Post by bzbarsky »

tannhaeuser wrote: post #171
bzbarsky wrote: post #126

Earlier quoted context omitted.

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 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 against browsers, not against the spec). Firefox tried going down that route for a while; I should know, because I implemented some parts of that and reviewed the code for the implementations of other parts. We eventually had to remove them, because of compat problems with websites. Comment parsing was a perennial favorite there.

> For example, the keygen element has been removed

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

> So tell me why, as an author, I should follow WHATWG's vision for HTML?

Honestly, because that's the thing browsers will implement. That's the only reason.

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

#204

Post by mcchampion »

jrochkind1 wrote: post #187
mcchampion wrote: post #184

Earlier quoted context omitted.

W3C did try to balance multiple constituencies for HTML, but it couldn't find consensus among them, and broad consensus is the basis for its authority. WHATWG didn't so much take control of the standards process as recognize that what actually works on the web defines the "stadard" It's not a capitulation, it's a way to exert influence in a world that respects rough consensus and running code more than formal process…

If they choose "not to ratify" something... will it have any effect on browser behavior at all? I don't think so. It'd just be a standard none of the relevant software cares about. Pretty useless to anyone. (Much like current W3C html standards...) Seems to me W3C will straight up be acting as administrative staff for WHATWG, providing free labor to do the "hard parts" of providing a useful standard, without much dec…

> If they choose "not to ratify" something... will it have any effect on browser behavior at all?

W3C has no authority to change browser behavior, no. But they CAN influence browser behavior by providing expert assistance to promote W3C's traditional values (accessibility, internationalization, privacy, etc.) in WHATWG.

We'll have to see if W3C's ratification or not has an impact on the larger web ecosystem, but it would probably get key customers' (and regulators) attention if W3C refused to ratify changes to HTML, DOM, etc. on accesibility or privacy grounds. Browser developers may respect W3C's supposed authority to set standards, but they definitely do respect the opinions of customers and authority of regulators.

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

#205

Post by austincheney »

icebraining wrote: post #196
austincheney wrote: post #162

Earlier quoted context omitted.

Stop being offended and have some objectivity. I am a front end developer and I am describing myself as much as anyone else.

Having a low opinion of yourself doesn't make you right.

Why are people so hyper sensitive about this? What mortal wound does this subject expose?

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

#206

Post by Sargos »

stephenr wrote: post #202
Sargos wrote: post #197

Earlier quoted context omitted.

So you're against the standards entirely? What is the alternative that you favor? If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? WebUSB gives us an option of doing it in a seamless and maintainable way.

> If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again , like they did last year? Sound…

We already have a native app but we are transitioning the majority of our core app to the web. Printing labels is one of the tricky parts that will be hard to transition. We are currently using an electron shell which makes maintenance easier but it still requires that end users install something which they might not have administrative rights to do. With WebUSB we expect that our entire app will be on the web and fully usable both on and offline without much maintenance fuss for the thousands of clients we have.

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

#207

Post by andybak »

geezerjay wrote: post #47
stupidcar wrote: post #42

Earlier quoted context omitted.

"Standard" = consensus definition of desired behaviour. "Living" = open to change. I don't see what is so oxymoronic about this? Just because a consensus has been reached doesn't mean that consensus must be immutable. Just because the process of standardisation in some technical domains has tended to use versioned documents doesn't mean that such an approach is fundamental to standardisation.

> "Standard" = consensus definition of desired behaviour. "Living" = open to change. > I don't see what is so oxymoronic about this? A standard is set in stone as a fixed target for implementers. No fixed target? No standard. And no, an unversioned document that changes arbitrarily is not a standard. To put it differently, a standard is a goal. If the goalpost is arbitrarily kept on the move then there is no goal.

> A standard is set in stone as a fixed target for implementers.

Is that a descriptive or normative statement?

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

#208

Post by lucideer »

lstamour wrote: post #194
lucideer wrote: post #176

Earlier quoted context omitted.

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

I was speaking more generally about live standards, but if you want to focus specifically on the HTML spec and notable changes for newer devices and accessibility: https://github.com/whatwg/html/commits Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboa…

I really really don't mean to be dismissive here, but... you know the WHATWG largely emerged as an backlash against the W3C's efforts to create an extensible standard for allowing authors to create custom elements (what's more, they would be namespaced with actual schema, a la react prop-types, or—later—Typescript interfaces), with extensible forms (xforms). This is a process started in the late 90s! Two decades later, and there's people on the internet claiming the WHATWG are doing something novel reinventing this concept now.

WeakMap is ECMA. CSP was W3C and implemented by Firefox 4 years before HTML5 was released as a spec.

There's good stuff in the HTML5 (there would want to be in a spec. that size!), but it's remarkable how many of the cited examples are nothing to do with it.

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

#209

Post by lstamour »

lucideer wrote: post #208
lstamour wrote: post #194

Earlier quoted context omitted.

I was speaking more generally about live standards, but if you want to focus specifically on the HTML spec and notable changes for newer devices and accessibility: https://github.com/whatwg/html/commits Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboa…

I really really don't mean to be dismissive here, but... you know the WHATWG largely emerged as an backlash against the W3C's efforts to create an extensible standard for allowing authors to create custom elements (what's more, they would be namespaced with actual schema, a la react prop-types, or—later—Typescript interfaces), with extensible forms (xforms). This is a process started in the late 90s! Two decades late…

It's important to note, nobody's being forced to use custom components or new syntax by specification, though as deprecations occur it's possible based on usage statistics that services like Google or new browser security or performance improvements could affect your site. And speaking to XML for a sec, while XHTML's backwards compatibility problems could have been avoided by specifying some kind of graceful fallback instead of Firefox's red text on yellow (yikes!), the real point is that when specs are created now, there's more of an attempt to "see what sticks" than there used to be. It's funny because E4X was also a failure, but JSX is so popular today, go figure.

Re. specific examples mentioned:

CSP is still evolving today and HTML has to keep up -- https://github.com/whatwg/html/search?o=desc&q=CSP&s=author-...

With WeakRef, things still need to stay up-to-date: https://github.com/whatwg/html/pull/4571

I would say it's remarkable how many standards on the web apparently don't have anything to do with HTML.

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

#210

Post by stephenr »

Sargos wrote: post #206
stephenr wrote: post #202

Earlier quoted context omitted.

> If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again , like they did last year? Sound…

We already have a native app but we are transitioning the majority of our core app to the web. Printing labels is one of the tricky parts that will be hard to transition. We are currently using an electron shell which makes maintenance easier but it still requires that end users install something which they might not have administrative rights to do. With WebUSB we expect that our entire app will be on the web and fu…

You have a working solution, and have decided to change to a platform that effectively doesn’t provide what you require to do business.

Whoever makes the engineering decisions at your company is an idiot.

Post reply on HN