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

#331

Post by panic » Sat, Apr 14, 2018, 12:35 AM UTC

BillinghamJ wrote: post #132

manigandham wrote: post #128

What a monumental waste of time. Why not just ignore W3C entirely? Seriously, what exactly are they going to do? Publish more? Sometimes it's better to not be nice and just let reality finish the job. So much effort taken from people who clearly have better things to do...

Yeah to be honest, at this point, it seems that the WHATWG members should just declare their withdrawal from W3C entirely, leaving it to die. It doesn't serve any purpose for the HTML standards any more.

There's more to the web than HTML, though. Most new web standards are developed through W3C working groups.

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

#332

Post by greenhouse_gas » Sat, Apr 14, 2018, 12:42 AM 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…

You can be unsafe even with typesafe builders. See

fn build(text_to_show: &str) -> HTML{ HTML(Body(H1(text_to_show))) }

What if text_to_show wasn't sanitized? You got yourself a XSS. And if you do sanitize it (and keep it in a StrSanitized type), what are the chances of accidental XSS?

Really, what should have been done is a "user supplied tag", which automatically displays everything as plain text, like Content

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

#333

Post by ajnin » Sat, Apr 14, 2018, 12:46 AM UTC

c-smile wrote: post #287

saas_co_de wrote: post #247

Earlier quoted context omitted.

Tldr is that corporations don't want a standards body with any public input so they created their own competing body, strangled w3c, and are now saying w3c is limited to being a rubber stamp for the standards they create.

Unfortunately that's over-simplification of the problem. 10-15 years we were told that use of s for layout purposes was terribly wrong. Without any reliable alternative mechanism. Here is my proposal to W3C CSS WG to add flow property and flex units: https://www.terrainformatica.com/w3/flex-layout/flex-layout.... It covers as flexbox as grid features under the same mechanism. Yet it establishes robust framework for o…

> What if browser would provide us just abstract DOM with minimal HTML/CSS implementation and some extensibility/plug-ins

That's what Houdini layout extensions are about, if that work ever comes to fruition that will indeed be a pretty major advance for web design.

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

#334

Post by lambda » Sat, Apr 14, 2018, 1:20 AM UTC

greenhouse_gas wrote: post #332

_fq4v wrote: post #233

Earlier quoted context omitted.

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…

You can be unsafe even with typesafe builders. See fn build(text_to_show: &str) -> HTML{ HTML(Body(H1(text_to_show))) } What if text_to_show wasn't sanitized? You got yourself a XSS. And if you do sanitize it (and keep it in a StrSanitized type), what are the chances of accidental XSS? Really, what should have been done is a "user supplied tag", which automatically displays everything as plain text, like Content

You would generally want the general purpose string type in your language to always be escaped when serializing, and only allow avoiding that if you opt-in explicitly.

So, for instance you'd have an H1::new(contents: TextNode) constructor, and you'd have to build a TextNode; if you build TextNode::new(text: &str), then it would escape it. If you wanted to explicitly pass in raw HTML, then you'd need something like HTMLFragment::from_str(&str), and it would parse and return the fully parsed and appropriately typed fragment object that could then be used to build larger fragments.

There might be some way to unsafely opt out, like HTMLFragment::from_str_raw(&str), that would just give a node that when traversed would just be dumped raw into the output, but that would be warned against and only used if you wanted to avoid the cost of parsing and re-serializing some large, known-safe fragment; it wouldn't be what you would normally use.

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

#335

Post by manigandham » Sat, Apr 14, 2018, 1:44 AM UTC

baybal2 wrote: post #301

manigandham wrote: post #156

Earlier quoted context omitted.

The only "standard" that matters is the one everyone uses. Everything else is a nice wish list for discussion but eventually needs to get out of the way. The WHATWG doc is a fine standard, backed up by real implementations. Beyond that, W3C is just copy/pasting whatever WHATWG has every few months so what's the point? And you really think the web is in chaos? We're at an incredible era of possibilities because browse…

> The WHATWG doc is a fine standard, backed up by real implementation. It sucks badly. To begin with, it can't be called a proper standard. It is in their terminology "a living standard" which means it being changed on a whim. It is not being written as an "ideal prototype", but rather it is just a codification of current behaviour of how Google's devs managed to write Chrome's DOM Api, with with all bugs and workaro…

Ok, so why does it suck? Because you don't like it? Why isn't it a proper standard when it's the only one implemented? Things definitely do not change on a whim and there's great care taken in the process. The group is very transparent and clearly state the objective is to keep the standard modern and evolving. You can always refer to an archived snapshot or the numerous compatibility tables for historic data if needed.

Chrome has bugs, like any other implementation, but has moved the web forward greatly in the last decade and the vast majority of developers and end-users would rather have modern working tech than some idealistic document that doesn't go anywhere.

Again, since W3C just copies the WHATWG standard anyway, what is the value that you claim is being added? And if you have better ideas, why not just contribute them to WHATWG instead?

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

#336

Post by c-smile » Sat, Apr 14, 2018, 3:05 AM UTC

lambda wrote: post #288

c-smile wrote: post #189

Earlier quoted context omitted.

It definitely needs to be some curation at least. As an example, CSS: Google came up with Flexbox, Microsoft came up with Grid. Now we have two competing layout methods doing pretty much the same. Yet they are conflicting in the sense that define the same flexibility entity by two different means: flexbox uses CSS property (that by itself conflicts with CSS 2.1 box model) and grid uses fr units for defining the same…

Well, flexbox was much simpler and easier to standardize on and implement sooner. It has been available in all major browsers since 2015. Grid is great, and now works in most places, but it was good to have flexbox while grid was still in process; it only became available in Edge, in the final form, late last year, making it now available on all major browsers. You're always going to have cases like this; where there…

Problem is that flexbox is a subset of grid. Or to be precise: flexbox and grid are just two forms in a set of layout methods that we already have and will have in future.

In normal architectural process we would establish first common infrastructure for all layout methods.

I've proposed something like that 9 years ago: https://www.terrainformatica.com/w3/flex-layout/flex-layout.... but it didn't go through (Who am I and who are browser vendors?)

So we would have single property that defines layout methods:

   display:block;
   flow: horizontal; // flexbox now
   flow: vertical; // ditto
   flow: grid(
           rows: ...,  
           columns: ...
         );          // grid 
   flow: multi-column( columns: ... ); // current multi-col
   flow: stack;
   flow: row(label,input); // variant of grid

So flexbox and grid are just parts of larger entity - set of current and future layout methods. Yet flexes has to be units as they a) were from the very beginning ( see "proportional" units here: http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.4 ) and b) can be used in other layouts and properties (why not margin-left:1fr ?)

Note that each layout method has its own parameters in their own namespaces.

Currently set of CSS properties is about 400 in one flat namespace. Any junior architect will tell you that this is close to unmanageable state. But we still pushing new stuff on that x'mas tree. It will fall down by its own weight as some moment, but who cares ...

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

#337

Post by jancsika » Sat, Apr 14, 2018, 3:26 AM UTC

lambda wrote: post #85

chrisseaton wrote: post #7

Earlier quoted context omitted.

Is there an article with the background on this? Why do we have both the W3C and the WHATWG, and why do the W3C just copy and paste work from WHATWG, if that is indeed what happens?

Way back in the day, HTML was implemented as an application of SGML. SGML was a quite complex markup format, that had lots of features that were kind of complex to implement, and so web browsers didn't actually implement all of SGML, just that which was necessary for HTML and the HTML found in the wild. However, the HTML found in the wild was frequently invalid, so browsers had to implement some clever rules to do so…

> Inspired by the clever algorithm the WebKit developers had come up with for parsing invalid content,

What was the clever algorithm?

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

#338

Post by bjelli » Sat, Apr 14, 2018, 5:24 AM UTC

kuschku wrote: post #254

tptacek wrote: post #30

Earlier quoted context omitted.

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

There' s a Big difference between "every major website" and "the Web".

"every major website" means 100 companies with skilled developer who can and will react to changes in browsers quickly.

"The web" consists of millions of websites maintained by individuals and small organisations who have no resources to update the way their web pages are coded every year. It contains HTML generated 10, 20, soon 30 years ago. It contains that one app in your intranet with the table layout that you can't replace and that IOT thing you connected to your home Wi-Fi 7 years ago that has no way of upgrading its web interface.

A browser that looses access to "the web" is worst than useless.

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

#339

Post by [deleted] » Sat, Apr 14, 2018, 6:41 AM UTC

kuschku wrote: post #22

cwmma wrote: post #14

Earlier quoted context omitted.

I think you're downplaying the shit show that was XHTML. It was the epitome of standards people chasing the ideal of a perfect platonic ideal of a standard at the cost of actual usability. E.G. a single parse error in an XHTML document and it doesn't render at all. That all by itself was a deal breaker for many people.

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…

[deleted]

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

#340

Post by dmitriid » Sat, Apr 14, 2018, 6:48 AM UTC

panic wrote: post #331

BillinghamJ wrote: post #132

Earlier quoted context omitted.

Yeah to be honest, at this point, it seems that the WHATWG members should just declare their withdrawal from W3C entirely, leaving it to die. It doesn't serve any purpose for the HTML standards any more.

There's more to the web than HTML, though. Most new web standards are developed through W3C working groups.

And those are often horribly mishandled.

DRM was pushed through despite objections: https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...

SVG was all but abandoned (the full story here: https://codepen.io/AmeliaBR/post/me-and-svg)