For those interested in this from a nonprofit perspective, I did an interview with W3C’s recently departed CEO, Jeff Jaffe, last year to discuss the organization’s thinking around this move: https://associationsnow.com/2022/08/world-wide-web-consortiu...
I prefer to not let assholes influence my choices. Besides, a different name would not stop the bullies from being bullies. Perhaps they would pick on someone else, but I don't see that as much better. Better to deal with the bullies directly rather than trying to work around them, even if that seems harder at first.
A very courageous stance when somebody else bears the consequences.
Let's give some of the kids joke names, and if they have a bad time, blame society. Let's give them access to guns, too, 'murica. Gotta commit to what you wish is right and ignore the evidence.
I was referring to the fact that most of its funding comes from the industry. And there's a revolving door for the FDA guys to work in the industry as well, which is the hallmark of utter corruption.
The other option was forcing browsers to have to make this part of the tech stack convoluted and painful for those using DRM, perhaps diminishing the appeal of using it -- not irrelevance. We had plugins in the early days of the web, and the W3C was entirely relevant at that time despite the dominance of flash.
You'd rather have plugins than streaming services that just work?
Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
> You'd rather have plugins than streaming services that just work?
Yes.
> Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
No, I'm still a happy Netflix subscriber. And they would have done just fine in a plugin model.
> And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
Your logic is just so bizarre here I won't bother with a response.
> No, I'm still a happy Netflix subscriber. And they would have done just fine in a plugin model.
Wouldn't that include disadvantages for the users? Plugins are usually a black box, working independent and lacking any way for customizing. The solution now is narrow enough that customization is possible for users on the harmless parts, without touching the DRM-part. By which I mean things like play-settings, the interface, behavior. There are many different types of extensions for changing the user experience on Netflix and such, stuff which did not exist for Flash&Co.
EME only works with proprietary plugins anyway. A <video> tag with EME is functionally indistinguishable from a fully proprietary <embed>. But the W3C decided to endorse EME as the "open" solution for completely spurious reasons.
8.1 CDM constraints in the EME is a pretty big deal relative to the plugin standard that hooks the <embed> tag. Plugins generally ran unsandboxed in the browsers' memory and therefore were a massive security hole.
EME unblocked killing Flash and made the web more secure.
> EME unblocked killing Flash and made the web more secure.
Neither of these are correct. Flash was dead on mobile long before EME, and the code running behind EMEs is an unaudited, black box (and having worked on decompiling the Mediatek secure enclave code, it's absolutely horrendous).
The only thing I'd consider to be marginally secure is Firefox's sandboxed DRM provider, and that could easily be a vendored extension on the window/media object.
> the code running behind EMEs is an unaudited, black box
It's an unaudited black box that isn't running in the same process as the browser itself. It can certainly do risky things in that context, but one of those things isn't "scrape the user's bank password directly out of the RAM it's sharing with the tab showing the bank's web site."
I'm not going to defend plugins as they were (a plugin-based DRM solution would not necessarily rely on the <embed> tags), but they were migrating to run in sandboxes before flash died. Chrome shipped flash-as-locked-down-process from early in its history.
EME code, however, can have deep hooks into the OS, especially on mobile.
> You'd rather have plugins than streaming services that just work?
Yes.
> Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
I don't.
> And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
Not since I got out of school. But it's also irrelevant as file sharing is not overly affected by DRM since it only needs to be stripped once.
I'd much rather have plugins. I don't want to watch any of the services you mentioned on my computer. I have a dedicated hardware device for watching these things, attached to my TV.
Why? The browser is a far more convenient deployment solution for the end-user: high-security via sandboxes and partitioning by default, temporary, no installation step required.
Are we pro-web here? Because if the answer to hard problems is "make it native then," we might as well declare the HTML stack a dead-end technology.
If I want to watch Netflix, etc I watch them on a TV with a dedicated remote. I’m not watching those things on a desktop computer attached to a big screen.
It's fine it's not for you. It's weird to tell other people "Don't do that." People have all sorts of reasons to rig up their setups that way. Let people do what works for them.
(Besides, I never said anything about laptops. I've got a desktop wired to my wall screen. Bluetooth trackball and keyboard on my coffee table. Works well, and I don't have to put up with the bad implementations of the Netflix app I've seen my relatives with cable boxes try to limp along).
Those other people could still install Netflix on their computer, which would probably even perform better and could even support things like IR remotes without the browser adding even more attack surface just because some people have a use for it.
I'm pro-web as in a hyperlinked web of hypertext. I am not pro-web as application delivery platform with unbounded complexity which is also available to sites that should be hypertext but use that complexity to restrict user freedoms. Calling a document-centric HTML dead-end because it doesn't suite your application (hah, get it?) is ridiculous.
Dead-end in the sense that the use case you describe can be implemented by something that also allows for apps, therefore we can anticipate it will be subsumed by that something (much like previous services online were rendered obsolete / irrelevant by HTTP, a protocol that could vend documents that also hyperlinked to other documents).
> Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
I can oppose DRM and still (regretfully) use DRM'd streaming services. DRM was not necessary for any of those services. Piracy still exists despite DRM. DRM is about controlling the end-user experience, not preventing piracy.
It was a masterstroke how Macromedia managed to normalize cross-platform video with Flash.
Circa 2000 you had a number of vendors pushing incompatible video and audio plugins such as Apple, RealMedia, Microsoft, etc.
If you wanted to publish media and have it work for everyone you had to support at least three formats.
Everybody thought Flash was about games and vector animation and there was no pushback when Macromedia had gotten a working video player into almost all web browsers, which made YouTube possible. Oddly Adobe bought Macromedia at that time and it was downhill for Flash after that... I think primarily because web browser vendors quit fighting over video formats and ganged up against Flash. Had Microsoft, Apple, and others really known Flash was going to win the video war they might not have bundled it with their browsers.
Ultimately HTML 5 killed off Actionscript and today Adobe Animate is alive and well not because people output Flash or even Flash-emulated-in-HTML 5 but because people output cross-platform video with it.
Besides the notorious security issues, flash had abysmal accessibility, cross platform support was nominal at best if you weren't on windows, and despite this it was being used in all sorts of places where it was completely unnecessary, like what seemed to be nearly every restaurant website. There were websites with navigation menus written in flash for no good reason at all, just because whoever made the website thought it would be cool to use more animations or something.
The whole thing was a disaster. Nominally cross-platform video playback was hardly a consolation.
I remember getting involved in an argument with somebody over this back when it was called 'FutureSplash' and before it was bought by Macromedia. This guy was a political activist and we were working with him to put Noam Chomsky lectures online long before there were podcasts but he thought people would connect better w/ animation-heavy interfaces.
I thought it was a good case study in how somebody who is worried about corporate power when it affects the workplace or foreign policy can be indifferent to corporate power over technology. My friend Harel and I felt pretty firmly that a web based on open standards was going to be good for 'ordinary people' having venues for self-expression. I think Mike Albert's viewpoint is closer to the mainstream though, where most people perceive ease-of-use as more 'liberating' than personal control, like that 1984 ad by Apple.
Today I think it is funny because I like animation-heavy interfaces in video games and think, hypothetically, it would be nice to see some more of that on the web, but I develop a lot of 'intranet' applications that consistently avoid the SPA boondoggle where the one thing I really can't do is animate transitions. I guess I could use HTMX and push the animations out to a 'frame' around the 'pages' that get loaded but that is unappealing to me because I'd like to have completely integrated animations and not a library of dissolves, fades, wipes and loading indicators that are much less necessary if you are loading a 25k 'screen' as opposed to 2.5 MB of Javascript.
To me it shows that they are living in the real world. Had they denied DRM in browsers we'd have everything behind native app barriers. I don't see that as a positive.
It was a “hosted” organization that was managed by a number of universities and research/educational bodies, which meant that it had to go through these organizations to make material decisions, such as hiring and investment. They did it this way because when the W3C was founded the goal was getting up and running quickly. But over time, this setup became complex.
Now, with this restructuring, it can make its own decisions about who to hire, for example, and can also do its own fundraising.
It was an organisation with no legal existence, existing as an agreement between different host organisations (originally MIT & CERN, soon turning into MIT & INRIA, then later joined by Keio University and Beihang University, INRIA also getting replaced by ERCIM).
"The WHATWG was founded by individuals from Apple Inc., the Mozilla Foundation and Opera Software"
Steering group is people from the 4 major companies.
At least originally WHATWG was undeniably and undisputedly a good thing. Their work literally removed incompatibilities from the web by producing standards that specify how HTML should actually be rendered, for example.
Now everything is subverted and co-opted by Google, of course.
> Their work literally removed incompatibilities from the web by producing standards that specify how HTML should actually be rendered, for example.
No they didn't. There's no standard today that exists that describes the implementation level details of CSS 2.1. It's descriptive and you have to figure it out yourself.
// 2.3 The CSS 2.1 processing model
// This section up to but not including its subsections is non-normative.
// This section presents one possible model of how user agents that
// support CSS work. This is only a conceptual model; real implementations
// may vary.
HTML rendering is a part of the visual user agent standard in CSS 2.1. It is no longer outside of their purview when they discuss visual output. The HTML issue tracker also discusses changes to JavaScript APIs, among other things. So, emphatically no they did not "remove incompatibilities from the web by producing standards that specify how HTML should actually be rendered." That's the CSS specification's job.
Here are all of the standards WHATWG works on: https://spec.whatwg.org/ They also discuss changes to standards they don't work on directly, but effect change through the HTML Living Standard.
XHTML 2.0 had some good ideas, it wasn't all "fantasy land", and WHATWG still picked over the corpse of XHTML 2.0 and added some of them to HTML 5. XHTML 2.0 was never truly finished so we have no idea what the final product would have looked like if the browser implementors had actually contributed back into the process instead of going off in their own direction.
What I'm learning from this thread today is that there's a lot of animosity to what WHATWG did when Hixie et al rebooted the standard (which at the time was effectively dying and unmaintained).
Can anyone explain this politicking and bad blood? Are there some people upset this long after it all happened?
The very short tl;dr is there were a couple main contentions:
* Continuing work on HTML at all, instead of furthering work on XHTML + XForms + etc.
* Certain decisions, especially around accessibility & internationalisation, at a point where the editor (then Hixie) practically controlled the decision making.
They could have done it as a WG in W3C, but they decided not to. They instead created a separate organization and cabal which today is controlled de facto by Google.
They couldn't: to form a W3C WG requires support of the staff and the W3C membership, and it was clear that there wasn't that support prior to the WHATWG's formation. I believe the original preference of those involved was to do it at the W3C.
They killed momentum on XHTML, which included reusable modularization and components. Inclusion of semantic web / structured RDF graph data was an objective, and this all got pushed by the wayside.
Strict, structured data could have posed a threat to Google by enabling other search engines to more easily build fact-based competitors and crawl the web of rich data. The decentralized nature of OWL/RDF would have pushed the web closer to P2P aggregation (think RSS, FOAF, pingback...)
The web could have been less Facebook-y, less Google-y, more Napster, more GPT-3 if XHTML had won.
That last assertion is heavy speculation. Why are we assuming that, had XHTML been the dominant infrastructure, Facebook and Google wouldn't still be the best at leveraging it?
And if anything, Google desperately did and does want people to semantically annotate data. They're extremely confident in their ability to be the best at organizing it, and well-annotated clean data is a huge benefit to them.
The RDF vision (where every website authors their own rdf graph in an open world sort of way, which web spiders search in a unified fashion) has tons of problems that its advocates refuse to acknowledge. Most notably lack of incentives to participate, complex authoring burden and poor scalability of graph querying.
The only time rdf has had success is when there is only an extremely limited vocabulary allowed (xmp, certain other metadata standards) or when the ecosystem is closed so its just one site or group making the rdf (e.g. wikidata)
It was never a threat to google because it was never going to win.
Did the people driving the semantic web ever really get traction on the taxonomy problem? I vaguely remember a lot of hand-waving about semantic ontologies, but the mechanics to actual reconcile the widely divergent labels humans inevitably produce always seemed to be someone else's problem.
What killed XHTML was the lack of backwards compatibility and especially the first-mover problem with embedding and the ads ecosystem. Namely, making a large production website fully validate was very hard, yielded zero ROI, and if anything went even slightly wrong such that invalid XML was emitted that would create a site outage that you couldn't easily detect server side.
That's a bitter pill to swallow even as is, but now throw in the common practice of mixing in markup from third parties for ads, social buttons, login forms and other things and now you can have a major site outage caused at random by third parties, which, again, cannot be detected server side.
As for RDF, GPT-3 is sort of the ultimate repudiation to that whole line of AI research. GPT-3 doesn't care about structured data at all, it can't even use it any better than a human would.
Disagree. HTML, until HTML 4.01 published 1999, was formulated as an SGML vocabulary. Then, starting in 1997, W3C (technically, the SGML Extended Review Board in cooperation with ISO) "went meta" and created XML as an SGML subset in anticipation of a wealth of new vocabularies on browsers to be supported, of which SVG and MathML made it. Today, these vocabularies are integrated into HTML, with HTML rather than XML parsing rules (for example, element names are treated case-insensitive). HTML itself still uses tag inference and attribute shortforms that are only part of SGML but not the XML subset of SGML. Basically, the multi-year detour of creating XML was not worth it for the web since everything XML could do was by definition possible using SGML as well, it being a strict superset of XML, despite XML being hugely successful in enterprise computing and the publishing industry, and most HNers only knowing XML.
What XML (XHTML2) was onto, however, was a completely unrealistic attempt to redefine browser behavior and vocabulary, with no buy-in from browser vendors (except Opera?), and with things such as XForms and wildly unproven RDF/SPARQL stuff. Ian Hickson was right in 2004 to fork HTML; browser vendors had no alternative.
A) WHATWG is totally controlled by the browser vendors, which have become even more of a small oligopoly than it seemed they would be 10 years ago. It's basically Apple, Mozilla, Google and Microsoft -- so those four organizations, three of which are enormous corporations, are controlling web standards. (And in practice it seems to mostly just be Google-controlled for whatever reason, but either way). Whereas W3C at least hypothetically was accountable to multiple stakeholders.
B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it.
The counter to (a) that, is if your standard is beholden to a bunch a stakeholders who aren't actually making the software, you're going to end up with something useless that nobody implements.
The biggest difference between whatwg html and earlier w3c html is that people actually implemented whatwg html where w3c standards were more wishful thinking that never got used or implemented (rip xhtml).
XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers.
XHTML 1.x also did a lot to help shake out things like "quirks mode" versus "standards mode".
HTML 5 imported a lot of things that worked from XHTML 1.x.
It's true that XHTML 2.0 was murdered before the spec finished but that was part and parcel of the WHATWG coup. We have no idea what the final product from XHTML 2.0 would have looked like (it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them) or if it had implemented if it would have been used because the browser implementors had already decided they were going to take charge instead.
> it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them
That one sentence pretty much sums up why w3c is a bad standards body.
A standards body is not a research group. If you are aiming for the stars you are doing it wrong. A standards body is supposed to be doing the boring work of formalizing what is known to work well, not try and invent new untested things.
I think there is a large spectrum of standards bodies and working to productize outside research and aspirations is a part of some good standards bodies.
Not a lot of people are calling WHATWG a bad standards body, but it is even worse at taking stuff directly out of Blink research and labeling it a draft standard with only a single implementation with sometimes seemingly very little study into its safety or long-term viability.
I suppose there is a small distinction between Ivory Tower academic aspirations and research versus Walled Garden corporate aspirations and research, but at the end of the day it certainly feels the same, and I have more reasons, myself, to admire the academic aspirations that aren't tied to corporate interests and profit motives, but I can understand why some feel what Google and WHATWG is doing is better for the web because they start with that first "implementation" of their research instead of a chalkboard and a hope for a better web.
In order for a standards body to be successful, it must be possible to attempt standards and fail them before they leave the standards body. Otherwise they would lose credibility by publishing recommendations that won't get wide acceptance. XHTML2 is an example of a W3C WG exercising restraint. That is a good thing.
You seem to think standards should only be built in reverse, which is essentially the WHATWG philosophy: Browser vendors implement something they think is useful, then try to negotiate to get it standardized. That's not bad per se, but it's limited and it's a different system of accountability.
As I recall even in draft standards you could mix XHTML 1.0 namespaces and XHTML 2.0 namespaces to use "backwards compatible markup" where you needed to. It wasn't pretty as most things involving XML and lots of mixed namespaces isn't, but it was possible.
We still don't know if it would have gotten more backwards compatible had browsers tried to actually implement it.
> XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers.
Well, the XML part wasn’t. Serve your XHTML as text/html and it was “supported” by virtue of being treated like HTML with some minor syntax errors. Serve your XHTML as application/xhtml+xml, as required to get any XML features, and it wouldn’t display in Internet Explorer at all.
XHTML 1.0 was allowed to be served with text/html for compatibility reasons, if you were careful to not make it too different from HTML (don’t self‐close an empty <textarea>, for example, and add a space before every “/>”). XHTML 1.1 didn’t allow the text/html MIME type at all, and so basically nobody used it.
That’s not even getting into XML’s unpopularly draconic error handling for pages that did get served as XML…
I recall I had XHTML 1.x Strict served as XML working in Internet Explorer (that would have been my primary testing/dev browser at the time, even). It was certainly no cakewalk, but it was briefly possible. As I recall it the XML mime types stopped working again shortly after HTML 5 became the headwind.
Great argument for zero accountability to users and everyone else impacted by decisions of browser vendors. You don't seem to be aware that the W3C has been chugging along, publishing real web standards that do get implemented, for years - or the actual roles of W3C and WHATWG in the standards process - so just stop. (Also FYI https://caniuse.com/?search=xhtml)
> You don't seem to be aware that the W3C has been chugging along, publishing real web standards
Including most recently standards that are basically a way to give a thin veneer of respectability to crypto shit (e.g. DID)
To be clear, i am not saying everything w3c does is totally devoid of value. They have done useful work. But its still an org that generally makes bad standards that are rarely followed. The recent bitcoin stuff is shit and basically not a standard. The historical standards are also often terrible, especially when you step away from html (you can't possibly read XMLSignature and think any of it is a remotely good idea).
As an org, its riding almost entirely on the coat tails of HTML, and now that that is gone, what is the point?
> zero accountability to users
Has w3c ever done anything at all that actually helped users over browser vendors? Things like P3P that aren't implemented don't count.
Two use Blink, which is a fork of Webkit (Google owned. Microsoft uses its own forked version for Microsoft Edge since Edge Version 79). Apple uses Webkit proper, and Mozilla is Gecko driven.
The power of open source. Next you will discover how widespread software is that was primarily written by individuals like Jean-loup Gailly, Mark Adler, Daniel Stenberg or Dwayne Richard Hipp.
> B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it.
I've found it incredibly useful. For the first time, someone actually wrote down all the details of how to do real-world HTML parsing, rather than having that knowledge all embedded in web browsers.
WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.
The key issue is the "Living Standard" part, not the technical details of the specification.
Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality.
It means that:
1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec;
2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed;
3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated.
Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions.
Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.
I personally think the web should have used a more solid standard from day 1. If something like strictly validated XHTML had been the very first thing shipped on the web, and anything that didn't validate wouldn't display, we'd have had a very different web.
But given the web we have, I think we need to document it.
> It would quickly become unmanageable as libraries would be using different features from different revisions.
As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".
The issue is, suppose you implement an HTML viewer component in Java/C#/whatever, which could be used, for example, to display help pages in a desktop application. You’d like to tell the users of that component that it supports HTML version x.y, but with the “living standard” there is no x.y to point to. Content providers instead have to use trial and error to see what renders in that viewer and what doesn’t, instead of having a specific standard they can refer to.
Similarly, you can’t have an HTML content generator that would guarantee that its output conforms to HTML x.y, and thus could be used to produce content for the viewer component.
The only thing that the respective providers of the viewer component and of the content generator could do is to provide a copy of a snapshot of the “living standard” to express which revision they support. But since there are no named/numbered versions, that’s not very practical, and it makes it hard to determine compatibility between such software modules.
This is what the “living standard” fails at, as a standard.
As pointed out elsethread, it also fails by leaving a lot unspecified.
If you've done any web work at all though it's pretty obvious that the edges of the spec are never especially well specified and browsers have different implementations all the time. Sometimes deliberately.
So you don't really lose anything at all by having a continuously updated spec instead of a versioned spec. Hell if you want you can think of the date as the version. Then there's no difference at all. Many versioning systems work like that.
> Imagine writing a Java, C# etc. application to a Living Standard.
Those are bad examples because they have implementations that are overwhelmingly popular and therefore the de facto standard is "what does the official compiler do?".
A better example is C++. Guess what? C++ implementations are incomplete and patchy and often have subtle differences just like with web browsers.
> WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.
No they didn't. In fact there are whole sections of the web standards that have no normative details on how to implement them other than descriptive notes about how the end results should function. It's a core reason why the Internet Explorer team had issues with CSS composition. It's UNDEFINED.
Not sure what "standard" you're reading. No implementor wants to write against a "living standard" that you have to fork for a pinned date of what your rasterizer conforms to.
WHATWG just links to a bunch of W3C actual versioned standards for the majority of specifications, most of which they didn't actually want to do work on.
Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications.
Oh by the way, for people who actually read the specifications required to build a full web browser know that you still actually have to read WebKit, Chromium, and Gecko/Quantum codebases to understand what they have all silently agreed to do that isn't documented in the specifications.
Why? Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.
> It's a core reason why the Internet Explorer team had issues with CSS composition
I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should?
> Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications.
They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that.
> Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.
Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)
The most important ones..., like, how is a website drawn? Well, there's intentionally no such definition. And people wonder why Internet Explorer was so "bad," it wasn't that IE was bad, the standards themselves are garbage.
Foundational visual user agent compositing is based today on CSS 2.1, and all CSS modules that build on top of it.
Newer algorithms like flexbox have a formal algorithm with minor undefined details documented.
The entire box model has no normative processing standard. It basically tells implementors, "Well, it should look like this, but you know if you want to do something different, that's fine. We don't tell you how to process glyphs or lines, so figure it out."
Let me put it this way: there is no such thing as a collection of web standards that you can read today and implement a visually similar output to mainstream evergreen browsers. They don't exist. It's a farce, a lie, an illusion. However, you want to articulate it, there it is.
Some subsets are formally defined and provide an actual algorithm you can implement, others describe an output with no processing model, further some standards exist which implicitly require that an undefined formal processing model exists.
You MUST read existing web browser codebases and their explicit comments which specifically say things like, "This is what WebKit/Blink/Gecko/Quantum does, so we do it here, too," in order to create a web browser that does something similar.
It can be as basic as line processing to as nuanced as box shadow processing, or as complex as how subtrees affect framebuffers. Yes, there are CSS properties dedicated to altering the implementation level details of a CSS processing model that doesn't formally exist.
I know this specifically because I wrote a compositor that conforms to a subset of CSS 2.1 and additional CSS Modules.
I STILL don't know how one writes a performant compositor today because what you're supposed to do is write one with a tile-based rasterizer and virtualized graphics commands.
You can't just rasterize subtrees to framebuffers because the calculated CSS may result in dimensions larger than what your hardware can support for backing layers.
Try finding that in the CSS standards.
HTML parsing may have a formal standard now, I've never read it, but the fundamental truth is that it didn't matter if one existed anyway. There was no such thing as a conforming HTML parser prior to then, so what implementors did was read how other web browsers parsed HTML, because that was what users and developers expected, so that was the "true" standard.
This problem still exists today, just in other places.
There are also NO REAL TESTS. There are some manual, human-based, use-your-eyeballs web browser tests that exist, but you can't use them, because they rely on circular logic.
You can't test a web browser by referencing some ground truth that is produced by the web browser when you're testing the exact features that generate said "ground truth."
It's also impossible by definition to test browser rendered output because the output is implementation specific. There's no comparing output to a reference rasterization, because now you're dependent on properties that in the specification are left to the implementor to decide what they want to do.
WHATWG did the right thing because W3C had basically abandoned HTML at the time. A fork of the spec was the only was forward for the web. But WHATWG is fully controlled by the browser vendors where W3C was more neutral.
Quirks mode is a backwards-compatible rendering mode which retains certain historical bugs in the CSS implementation. It is completely independent of the HTML/XHTML divide which is about the syntax of HTML.
Hammering out how strict XHTML was to be was a big part of the browser conception of "modes" to begin with. XHTML itself as a standard suggested "three modes" Transitional, Strict, and Frameset. Transitional XHTML was still more strict than classic "quirks mode" (though obviously much less strict than Strict XHTML which was too strict for most people) which got its name somewhat in contrast. Quirks mode survived for a while longer after XHTML declined because of things like historical bugs in CSS (and ES3-), but trying to clean up many of those historical bugs was considered a part of the reason for XHTML and part of why XHTML suggested multiple "modes" that documents could opt into to get better behavior.
As far as I recall the HTML 4.0 and XHTML 1.0 specs were drafted side by side and which one you want to give credit for introducing the different DTD "modes" is a matter of perspective. My perspective from that time was that because the "modes" affected XHTML parsing (and mime types) so much more than they affected HTML 4 they always seemed to me designed for XHTML and back-ported/side-ported to HTML 4.
The DTDs were a signal designed to opt into different parsing and rendering modes, including CSS rendering differences (and as I recall even differences in ES3 mode "option strict"/proto-ES5; though memory is hazy and I don't remember which browser I think did that in my testing at the time) and DTDs were a simpler signal than most of the other alternatives at the time and since (META tags/Headers). They were never independent concerns in practice, though sure they could have been in theory. Rendering changes were one of the reasons few developers opted into XHTML 1.x Strict.
According to Wikipedia, HTML 4 was published in 1997, XML in 1998 and XHTML 1.0 in 2000, so it is unlikely there was any backporting from XHTML 1.0 to HTML 4.
The issue around DTD's is confusing because browsers use the <!DOCTYPE>-tag as a signal to switch between quirks and standards rendering modes. This might suggest a connection between the DTD's and the rendering modes, but in reality browsers have always ignored the DTDs. They just match the <!DOCTYPE> against some predefined strings to determine the mode. And the DTD's was never designed for this purpose, it was just a hack introduced by browser vendors.
> Rendering changes were one of the reasons few developers opted into XHTML 1.x Strict.
XHTML 1.x strict was rendered the same way as the corresponding HTML in standards mode. But given the confusion around the issues, it is possible some developers thought it would render differently.
I can’t speak for everyone else, but I am resentful that it promoted the Web as an platform for running applications containing arbitrarily-complex (Turing-complete) code instead of a platform for exchanging structured (declarative) documents, I despise the philosophy of ‘backwards compatibility at all costs’ it follows, and the massive volume of standards documents it produces, all of which basically guaranteed the browser engine (quasi-)market would remain an oligopoly, by making it prohibitively expensive for new, leaner yet practical implementations to emerge (both because of the initial cost of catching up with the current state of the art and also of keeping up with the Red Queen’s Race of the ever-evolving ‘living standards’; just look at the sorry state of NetSurf). Not to mention the security holes their attitude engendered. If we moved to XHTML, maybe we wouldn’t have the meta-utopia Web 2.0 promised, but at least we wouldn’t have CVE-2020-26870.
The WHATWG was formed as a cartel of browser vendors that pretended to be a standards body. And these days even ‘cartel’ may be too generous, now it’s just a Chrome rubber-stamping committee.
As far as I remember the (W3C) standard wasn’t really unmaintained, it was going in a direction nobody cared about with its focus on xhtml.
In the meantime IE6 had all but won the browser wars and completely strangled innovation in a striking demonstration of the problems with a monopoly. The web needed to be shook up.
The W3C went down a rabbit hole of XML based stuff with an emphasis on everything being well formed and valid. There was a time 15 or so years ago when XHTML a version of HTML which was also valid XML was being touted as the way forward. This meant that if there were any errors in the page it would just though an error, as opposed to HTML which would try it's best.
WHATWG was created in frustration with that approach and saw the XHTML and other XML stuff being a case of Architectural Astronomy (which is not to say they weren't doing anything, just they weren't doing anything seen as useful) and they created HTML5 which was a standard based on how HTML worked in the wild and explicitly codified how tag soup and other invalid pages should be shown.
HTML5 really revitalized the web at a time when it was pretty stagnant. WHATWG has always had a pretty practical approach to standards that boils down to the fact that whoever builds a browser ends up having the final say in what goes into the spec because it doesn't matter if there is some cool feature that nobody wants to ship, if nobody ships it it's fundamentally not part of the spec because it can't be used. This does end up meaning that WHATWG ends up being just made up of Microsoft, Google, Apple, and Mozilla. There is some irony as the descriptive HTML5 which tried to codify how HTML worked in the wild made it so complicated to create an HTML parser that now only a megacorp could actually afford to do so.
So, going off some of the descriptions of how this impacts budgeting and hiring from [0], I feel like this is a bit of a double edged sword:
- Under the new model, corporations will be able to more aggressively influence funding, and thus be better able to ensure their interests are represented by new staff members responsible for shaping debate on features.
- But under W3C's old model, where budgets and hiring were subject to approval by university liasons, staff couldn't be hired with enough agility and bandwidth to prevent those corporations from being overly aggressive anyways. Perhaps with more non-corporate-aligned humans being able to wholly focus on standardization now, there will be more attention paid to community engagement.
I suppose time will tell. When it comes to things like FLoC (now Topics) [1] the privacy implications of having an agile standards board are more important than ever, and may actually have significant impacts on people's physical safety.
Whether or not this has been true historically, all three companies are under massively increased pressure in the current environment, and may not be sufficient checks on each other the way they have been in the past.
Genuinely: what do you believe the W3C has published as a standard (and not as a draft, not as a community group report) without support from multiple vendors?
Agreed, though I'm not sure the W3C has much choice. When WHATWG wrested control of HTML from W3C it drove home that browser implementers determine the standard. Given chromium's ~75% market share[1] and Apple's ~18% market share it increasingly seems like the purpose of the W3C is performative, to lend more credibility to what has become a proprietary standard driven by Google and Apple.
What Google does, is publish a "draft" which is as far from a standard as their authors are from the Moon. This gives Chrome the leeway to call it an "emerging standard" and just ship it. It doesn't care if there are objections, or that other browser vendors will not implement it. It's now a "standard" in Google's dictionary.
For something to become a W3C standard even in the present world, you need a consensus and at least two independent implementations. None of that exists for stuff Google pushes out (hardware APIs, web transport, constructible stylesheets [1], the list goes on...).
The correct name for those is Chrome-only non-standards.
[1] These one isn't even a draft. It is.... "a collection of interesting ideas" in a working group https://wicg.github.io/construct-stylesheets/ Shipped by default in Chrome, of course
TIL, I though chromium always was ahead of chrome, so all changes end up in chromium first, therefore also other chromium based browsers get the patch/nonstandard behavior.
Chromium might get those features purely due to Chrome's release cadence. So the code may be enabled the code base without flags before it ships in Chrome (Chrome releases are monthly).
Most of Chromium-based browsers will probably lag on those features because they either don't want them, or have their own release cadence, or are running an older version etc.
And it's only Chrome that pretends that their non-standard features are standard, and employs a large network of propaganda from web.dev[1] to dev rels[2] to advertise them as standards.
[2] I sadly lost the link to tweet from either Justing Fagnani or Alex Russel where they called the decision to ship Constructible Stylesheets "bravery to move the platform forward". Context: trivial deadlock issues in the spec, both Mozilla and Safari were dead set against it until issues could be fixed, Google-led lit-html wanted the functionality, so Chrome just shipped it.
Remember the good old days, when Google didn't have a browser and Googlers donated generously to public benefit nonprofits like Mozilla?
The real issue is allowing folks with a fat salary to advocate in bad faith against a healthy internet. (Along with shit like moving the Chrome team into the same building as Mozilla HQ and poaching employees for years.)
It was frequently the case the hosts didn't want to be sinking money into the W3C previously: this is the reason for many of the recent (controversial) moves (especially around WoT, advertising, etc.) to try and attract further members to try and increase revenue.
If anything, this is likely going to result in the W3C having fewer staff and lower costs, and thus only needing membership fees to cover a lower sum than it has previously.
> When it comes to things like FLoC (now Topics) [1] the privacy implications of having an agile standards board are more important than ever, and may actually have significant impacts on people's physical safety.
This sounds like needless fear-mongering. Is there anything to backup any concerns about people's physical safety?
When it comes to Topics, it's essential that there be hands on the wheel at W3C that approach the solidification of e.g. the Topics taxonomy https://github.com/patcg-individual-drafts/topics/blob/main/... from a neutral perspective that takes into account the various ways in which proposed topics could be dangerous, and how strongly to word the specification to prevent it from creeping in increasingly privacy-eroding ways in the future.
Is the W3C legitimate? At this point most of their standards are behind the curve. It feels as though the big three are setting the standards, and others (including W3C) are just following along.
That's how standards organizations usually work. They can't dictate standards. They have more power when there are many participants, but when there are only a few players all they can do is formalize things big players (mainly Chrome) decided to add.
> Our vision for the future is a web that is truly a force for good ... truly international ... more inclusive ... more respectful of its users ... supports truth better than falsehood, people more than profits, humanity rather than hate ... that works for everyone, because of everyone.
Ok the question is how to achieve these goals and are those having failed to deliver on these goals for 28 years now according to their own words really the ones to expect solutions from, as W3C, Inc of all things.
I'm sorry but all I can see is W3C, Inc. acting in their own interest, for job security. Because core web standards such as HTML are specified elsewhere (basically by random people on github, but mostly Google employees and other financially dependent people who're calling themselves the WHAT working group), leaving only CSS at W3C, and it's a fsking mess. Maybe we can get W3C to work on a formal CSS spec or, better even, a reference browser rather than la-la specs. Though I fail to see how that could be financed under either their old or new funding model.
Amaya specifically disagreed we should use "Browsers"; preferring that everyone could contribute by accessing the web via an "Editor". Calling it a browser shows how far it failed to achieve that.
Netscape was bundling a full WYSIWG + markup editor with their browser in '97, a few years before IE6 came out. It was kinda separate by my recollection, but still basically felt like part of the browser, though it may have been possible to install the browser stand-alone (it's been too long, I don't remember)
Nowadays, all the large browsers come with development tools that are much more powerful than Amaya (Firefox even has a developers edition that centers the UX around those tools). People still use them for debugging, not development, because the web is inherently a client-server environment that does not allow development done by the client.
This is more of a "what were they thinking?" situation than we actually losing anything.
I think Amaya's vision is much closer to the original vision of the web though. CSS was made with the idea of each user having their own stylesheet in mind so they could browse the web however they wanted.
Obviously CSS has evolved way beyond that nowadays and you need an extension on most browsers to even use something like that. But I think there's a value in a project like Amaya making these tools front and center instead of stashing them away in ways only "developers" are meant to use. I'd hope it'd cultivate a sense making the web work the way you want it to work amongst the general userbase
I would actually like to see the project reborn some day
> I'm sorry but all I can see is W3C, Inc. acting in their own interest, for job security.
It is painfully obvious that just about everybody who speaks in that certain way is primarily/exclusively concerned with their own job security. Welcome to Zombocom.
Funny that most of those "ideals" of theirs are directly contradicted by their support for DRM. Being a "force for good", "inclusive", "respectful to its users", "people rather than profits", "that works for everyone"? Utter bullshit. Profits for media conglomerates are clearly more important to them than all of those values.
While it's a shame that support for DRM went through, this is an org that's already suffering criticism for being "irrelevant", through no fault of their own other than a bunch of large rich corporations decided to throw their efforts behind a more expedient force (WHATWG). It's understandable to see why they would fear the same happening with DRM (implementers decided to go with non-W3 specs in order to add DRM support).
The above comment is a perfect example: criticising the W3C for being a "fsking mess" due to forces outside of their control (the ownership of web tech by a very small number of very wealthy web client corporations).
I could forgive it if their stance was simply, "this is unfortunate but there is nothing we can do about it". But that wasn't their stance. Tim Berners-Lee (you know, the director of the W3C) was publicly endorsing DRM.
You're right that the W3C has no actual power to dictate what gets standardised anymore; they squandered that, so now only WHATWG's word matters in the end. The only power the W3C has is their ability to influence public opinion, their voice is still rather meaningful in the public debate. They could've used that voice for good, taking the side of the EFF and other pro-freedom organisations to denounce DRM. In the end, they would have had to begrudgingly accept WHATWG's DRM standard if it came to that, but they could've made it clear along the way that it's a terrible idea. This would've put them squarely in the pro-open-web camp, and would've made it clear to the public that the WHATWG is in the anti-open-web camp.
Or they could've stayed out of the discussion, accepted their irrelevance, and just adopted the W3C spec.
But they chose to actively enter the public debate around DRM in favour of this user-hostile, anti-open-web standard. They chose to use their influence to convince people that DRM is a good thing. They're on the record as being in favour of a web where it is impossible to make a proper open-source web browser which can render any standard web page.
In my book, the W3C's stance is clear as day: they're actively hostile to an open web, and they're prepared to spend any influence they might have to fight against it.
I'm going to be Devil's advocate here and say that DRM ostensibly protects the IP of content originators who I think we'd agree should be rewarded for investing in or creating that content.
Perhaps you have some other scheme or perspective on how content originators/creators can/could/should monetize their IP without DRM? Genuinely curious what alternative schemes are viable for protecting and rewarding content creators.
(Yes; let's all acknowledge that even with DRM, pirating still exists)
As far as I can tell, piracy exists for exactly two reasons:
1. Content is priced way the fuck higher than market value.
2. Content is so encumbered that it is difficult to even get it or use it.
The way I see it is that #1 is not a problem for content creators. It is relatively rare compared to people buying content and the person who would rather download an episode of The Office rather than paying Apple $1.99 for it was unlikely to pay if that was the only option in the first place. Their alternative to piracy isn’t to spend the money. It’s to watch something else.
As for #2, it is a self-inflicted wound. There was a time when the 6th Harry Potter movie was about to come out in theaters. I wanted to do a marathon watch of the first 5 movies with my family. I had the first 4 on DVD and wanted to buy the 5th. I checked all streaming services and none had it. In fact it appeared that some removed it a month prior. I then called several nearby stores and all were sold out. A store 20 miles away had a copy for $40. After spending nearly an hour to find this out, I spent 5 minutes downloading it off a torrent site. Maybe indestructible your content will net you more money even if you have some of your content pirated.
For $17/mo, I can access an endless stream of content on Netflix. This is way cheaper than I remember my cable subscriptions used to be (if we consider the cost of Internet access as fixed in either case). Verizon is even offering to throw in Hulu, Disney+, and a bunch of other streaming services "free" if I switch to FIOS + mobile.
I can watch Netflix on my phone, tablet, PC, TV, Chromecast, Roku, Apple TV. I can watch any show, any time I want, as many seasons and episodes as I want. 24x7x365. Is it really encumbered? Aside from IP owners walling off their services, content -- as long as you pay for it -- flows more freely now than ever, IMO. If I go to an Airbnb, I can log into my Netflix account and watch all of my shows. I can log into my Amazon account and watch all of my purchased movies. (Just don't forget to log out!)
Yes; I can't watch it offline or if I'm in a location with poor Internet speeds. But that is such a small fraction of my time that it hardly registers. Yes; my right to view content I've paid for can be revoked in some circumstance I'm sure, but it's never once happened to me.
Yes, and NetFlix is a great example. Prior to the existence of NetFlix video piracy was extensive and widespread, once NetFlix appeared that piracy was greatly reduced as the "value" was there (it was more convenient to pay NetFlix than to figure out how to pirate stuff). It won't be "zero" of course but it was effective enough that content companies have emphasized that model over encrypted optical media.
Then pay $9.99 for Netflix Basic or $6.99 and deal with ads. If you can't afford that then there's basically no price point that makes sense because you're simply not willing or able to pay for entertainment.
Exactly, or I can have it for free on my university T3 connection, and still keep up with popular culture.
Part of the problem is that it’s not ‘content’ that you want to subscribe to, but ‘specific content’, which might be spread around 3-4 different services that all want that sweet sweet monthly fee.
Dollars to donuts, I bet content available on Netflix is pirated a lot less than content that is not. Gel restrictions, content contractors expiring, not being able to watch it on a plane, etc. all do contribute, but Netflix is fairly priced for what it has (which is far from everything) and fairly easily available.
Yes, it's encumbered. You are beholden, across all of your examples, to binary compatibility of a .so file Google refuses to distribute for any platform except x86_64 and 32-bit ARM. The fact that you have a lot of such devices does nothing for the people who want to either consume the content on other devices or develop new devices for the purpose.
Much like DVD region locking, the majority of the population doesn't care, and those who do are capable of overcoming the DRM anyway, but the latter is illegal, and leaves no room at all for people who want to comply with the law but not with Google's device mandates.
If there's a TV series I want to watch on Netflix, and I watch it in the span of 4 months, I pay $68 for that one TV series. Is that great value?
Maybe Netflix is a good value if your primary goal is to have an endless stream of content to watch and you don't really care what it is. But if you watch TV less frequently, it's absolutely terrible value. And if you want to choose what series to watch rather than which streaming service to watch, the constant switching between streaming services is terribly tedious, and another source of increased cost if your interests don't change perfectly aligned with billing periods.
Sure, but I believe it is a very small percentage of people who pirate content (which is a small fraction of people who consume content). Most people are happy to pay and not think about it. Majority of those who aren’t, pirate for the above reasons. A small percentage pirate because of other reasons.
I know someone who just wants to have copies of all movies and TV shows. He spends way more effort on keeping up his storage array and downloading things then he does enjoying the movies. But for every one of him there are 10,000 regular paying consumers. Is he worth worrying about?
DRM, especially the kind used in browsers, is cracked all the time. So the claim that it 'protects IP' is false. It mainly just adds a barrier to creating compatible competing browsers/players.
I already acknowledged this; there's no such thing as perfect DRM and there can never be. There are a million and one ways to copy content, DRM be damned. But for the majority of users, there is a balance between inconvenience, quality, and cost that DRM tips the balance just enough for a part of the market.
The problem is that DRM only has to fail/be cracked once for every piece of media. If users who wanted to pirate something had to crack the DRM every single time, I'd be with you. But that doesn't happen. Instead, scene groups crack them and upload the media on torrent sites and the like, then it's just like any other pirated piece of content.
In terms of convenience DRM doesn't change a thing, because from the consumer's perspective it's all there on a torrent site, there's no way to even know if something had DRM unless you look it up specifically.
Online games include anti-cheat software. I'd argue that this is also "anti-consumer" because it forces me -- a non-cheater -- to install monitoring software. Not only that, despite this anti-cheat software, there are still cheaters in every online game!
Do you take the same view that game developers should just abandon anti-cheat because it can be cracked? Should online games just abandon anti-cheat schemes? Would that be a better experience for the gamers and the developers/publishers if we just abandoned anti-cheat because it's not perfect and there are always cheaters?
I'd say yes. Anti-cheat and anti-crack has created far too many issues for me as a legitimate customer. I prefer paying for DRM-less content and opensource software, and i'd choose to pay them over commercially protected alternatives anytime.
> Anti-cheat and anti-crack has created far too many issues for me as a legitimate customer.
Let me get this straight, though: you would rather that CoD, Fortnite, LoL, Lichess, etc. just make it open season; no anti-cheat. You believe that as a gamer, your gaming experience would be enhanced if there was no anti-cheat.
If that's your logical conclusion -- that no anti-cheat is the answer because there are always going to be some cheaters -- then I have nothing. We'll just have to agree to disagree. As a gamer, I'm happy to install anti-cheat if it can defeat the majority of casual cheaters -- even if it costs some frames or adds overhead to the startup time.
Anti-cheat is a) only neccesary for for competitive games, which is only a fraction of possible games and b) only needed there because publishers want to remain in control of the servers instead of letting the community run their own. With community-run servers the admins can kick disruptive players wether they are cheaters or not, no spyware needed. You could even require your own spyware for your server and let others play on servers that are more reasonable. And for tournaments the organizer should control the hardware and software anyway to make sure there is a level playing field.
I'd argue that anti-cheat is analogus to security-by-obscurity. It is basically a bad compromise to mitigate issues of a broken architecture.
Imagine that online banks would do login checks on client side, and you'd have to install anti-steal software before you can login. Would that be acceptable to reduce fraudalent transactions? Of course, there'll still be a signifcant amount of stolen funds, but it'd prevent most of your neighbors to login to your account.
Well, this is horrible design (and has basically happened with credit cards btw...) and you should address it at it's core, by bulding the architecture in a way that such fraudalent transactions are next-to impossible.
My point is: if cheating is so much of an issue, games should be architected in a way to avoid the ability of cheating from client-side at all, without additional monitoring required. Anti-cheat is a bad workaround to a core development problem, at the expense of the customer instead of developers.
In the case of DRM it's different. The inconvenience threshold is only about non-pirated to pirated, not "pirated (no DRM originally) to pirated (with DRM originally)"
Faulty analogy. The lack of DRM would not hamper my enjoyment of the media, as the lack of anti-cheating ware would hamper my enjoyment of a shared game. Put simply, DRM is about protecting the creator, anti-cheat is about protecting the consumer.
FWIW, I pay for nearly all the streaming apps and still get the file itself through ${other means} because I want it for offline viewing/future viewing etc just like we used to be able to with DVDs. If the streaming provider provided this file, I wouldn’t need to resort to these other means and they wouldn’t lose a customer who now already has to have an alternate pathway to get a soft copy of the file.
You don't need any "scheme". DRM-free already works for the music industry. Most people don't mind paying for content if they have reasonable options for doing so.
The flaw with your theory is that it's not browser or video player sellers who are pushing for DRM. What interest does Netflix have in preventing competing browsers / players?
A major DRM scheme is Widewine, controlled by no other than Google. So you have Google which is a browser vendor, an OS vendor and DRM gatekeeper. Even if as you say Netflix is fine with competing browsers/players, as long as they use Widewine they put everyone else at the mercy of Google's decisions. This is absolutely anti-user, anti-competitive madness. Mozilla pushed back as long as possible but had to give up.
I do not care. Even if DRM was magic and perfectly prevented piracy, it's not appropriate in the web. We're in a situation where it's intentionally impossible to write an open-source browser which can render any standard web page. That's not an acceptable state of affairs.
EDIT: Wow, I didn't expect "it should be legal to make an open source web browser which can render any standard web page" to be so controversial. I'm disappointed.
DRM is only unable on audio and video tags. You can still render the rest of the page. Often sites will gracefully fallback onto a lower quality version of the content if you don't support DRM. You could also just use widevine from your open source browser to play it.
Widevine isn't a browser. Similarly running GNU bash on Windows doesn't suddenly make GNU bash no longer open source even though it is calling out to closed source code.
An open source browser can not render standard web pages. A browser can either be open source and unable to render DRM content, or it can contain closed-source components and be able to render DRM content. Firefox + Widevine is the second kind, Firefox without Widevine is the first kind. It is illegal to make a fully open source browser which can render any standard web page.
That's missing the point, I think. The HTML spec includes elements that cannot be rendered using open source software. Yes, of course other parts of the page can be rendered (at least today) but it's absurd for them to claim that they are supporting open standards.
FWIW, you can make a reasonable argument that DRM as it currently exists is not about protecting IP of content creators, but instead "giving content providers leverage against the creators of playback devices"[1]. To be sure, both reasons contribute, but the latter isn't a good one, and you can argue that W3C indirectly supported it (although, I don't understand why it's preferable for DRM to be implemented through entirely non-standard protocol as opposed to having the W3C make something of a standard for it).
Ostensibly is doing a lot of work here because it literally does not. I can torrent any show or movie that is otherwise being streamed with DRM. DRM is a complete farce that serves no actual purpose but to make idiotic media executives happy.
It's a little strong to say it "literally does not" when I cannot break L1 Widevine, which uses the W3C's APIs
You might be able to torrent any show or movie in high quality with a private tracker, but it's hard to come by 4K HDR content just hanging out for free these days.
> You might be able to torrent any show or movie in high quality with a private tracker, but it's hard to come by 4K HDR content just hanging out for free these days.
Even if that's the case, that's not an issue of DRM, that's an issue of distribution.
It's also just flat out not true. Sure, some of the 4k HDR content might originate from PTP/BTN/scene/w.e., but it's readily available on e.g. RARBG.
DRM protects content creators from copyright infringement. Protecting against copyright infringement, something which is illegal and can hurt creators, is a force for good.
DRM would exist on the web with or without standardization from the W3C.
DRM is the epitome of prioritizing profits rather than people and disrespecting users. In search of profits for their stakeholders, the WHATWG and the W3C has made it impossible to make an open source web browser which can render standard web pages.
Disrespecting users? As if users stealing your content is not disrespectful to the owners of it. You can not just selectively ignore groups of stakeholders whom you are not a member of. The web should be made good for everyone.
>the WHATWG and the W3C has made it impossible to make an open source web browser which can render standard web pages.
Chromium is an open source browser which can do that.
Chromium can render DRM content using a closed source component. An open source browser can not render standard web pages, because DRM is part of the standard and DRM requires a closed-source component.
Every DRM scheme out there has been broken (or will be soon, if it just came out). It is trivially easy for any interested party to find copies of content with DRM removed. In fact I'd say this content is more accessible than if there were no DRM and the only obstacle were having to splice together chunks of unencrypted stream data transmitted by the authorized source. I was at someone's house the other day, a Netflix subscriber mind you, and the Netflix app wouldn't work on his laptop for whatever reason. He went to a pirate site and had the show playing within 30 seconds.
What DRM does protect, is the market position of equipment and software vendors that have the resources to sign on as DRM licensees.
DRM is not good, but if they didn't specify DRM, it would still end up in browsers as proprietary methods, or it's possible proprietary browser plugins like Flash would have continued to exist. Unfortunately, you can't just make the people pushing for DRM go away by not specifying it.
As important as the Web still is (and with the re-decentralization of the fediverse [0] it may yet get granted a second chance), it has been clear for some time now that the shape of digital life is rapidly being defined by mobile devices where the web is a second class citizen. The original "web-phone" dream has failed [1] and there is a distinct lack of ambition about "open mobile".
Here's hoping W3C has a better chance today, with people increasingly aware that the web's commercial interests are largely counter to the interests of a free and open society, and with WHATWG dominated by those very commercial interests.
Maybe W3C bungled things with XHMTL 10 years ago, trying to pull the web toward TBL's original vision of something like a giant Wikipedia. But things are very different now, having spent the interim in service to browser vendors and their monetization of control over user data.
> with people increasingly aware that the web's commercial interests are largely counter to the interests of a free and open society
Are people increasingly aware of that? Because society at large still seems to want to chanse after the latest shiny gadget without considering the full cost of the T&C.
Well, it is supposed to be fine since the web core is still around which nearly all services provided over the net can be performed with, namely with noscript/basic (x)html. You can add <audio> and <video> and pass that to an external mediaplayer until the URL seeking interface is standard and keep web browsers as they are supposed to be: lean/light client.
222 comments
[ 3.0 ms ] story [ 262 ms ] threadThe press release has more info: https://www.w3.org/2023/01/pressrelease-w3c-le-launched.html...
(Jaffe left the organization in December: https://www.w3.org/blog/news/archives/9776)
Let's give some of the kids joke names, and if they have a bad time, blame society. Let's give them access to guns, too, 'murica. Gotta commit to what you wish is right and ignore the evidence.
They gave up freedom by voting for secret DRMs in "standards".
A complete disgrace.
How, exactly?
Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
Yes.
> Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
No, I'm still a happy Netflix subscriber. And they would have done just fine in a plugin model.
> And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
Your logic is just so bizarre here I won't bother with a response.
Wouldn't that include disadvantages for the users? Plugins are usually a black box, working independent and lacking any way for customizing. The solution now is narrow enough that customization is possible for users on the harmless parts, without touching the DRM-part. By which I mean things like play-settings, the interface, behavior. There are many different types of extensions for changing the user experience on Netflix and such, stuff which did not exist for Flash&Co.
Anybody who cares about end-use security should want plugins out as quickly and completely as possible.
They literally ran in the same process as the browser. Full access to the memory itself. No security at all, and many of them were closed source.
The DRM standard was a strict improvement over the status quo.
EME unblocked killing Flash and made the web more secure.
Neither of these are correct. Flash was dead on mobile long before EME, and the code running behind EMEs is an unaudited, black box (and having worked on decompiling the Mediatek secure enclave code, it's absolutely horrendous).
The only thing I'd consider to be marginally secure is Firefox's sandboxed DRM provider, and that could easily be a vendored extension on the window/media object.
It's an unaudited black box that isn't running in the same process as the browser itself. It can certainly do risky things in that context, but one of those things isn't "scrape the user's bank password directly out of the RAM it's sharing with the tab showing the bank's web site."
EME code, however, can have deep hooks into the OS, especially on mobile.
Yes.
> Please tell me that since you're against DRM you don't use Netflix, HBO Max, Disney+, Hulu, Amazon Prime, Apple TV, or any of the other services that have exploded since EME.
I don't.
> And since they're presumably wrong to want DRM, tell me you also don't pirate their content.
Not since I got out of school. But it's also irrelevant as file sharing is not overly affected by DRM since it only needs to be stripped once.
I watch them from a Roku Device on an Actual TV, where TV and Movies should be consumed, not in a web browser
Are we pro-web here? Because if the answer to hard problems is "make it native then," we might as well declare the HTML stack a dead-end technology.
I do have a pretty large monitor on a wall patched into a desktop PC via HDMI though.
Not to your preference, perhaps. And the DRM doesn't seem to be bothering you since you don't watch in a browser, do why begrudge its existence?
I’m opposed to DRM in the browser on principle but opposed to watching movies and TV on laptops also.
It's fine it's not for you. It's weird to tell other people "Don't do that." People have all sorts of reasons to rig up their setups that way. Let people do what works for them.
(Besides, I never said anything about laptops. I've got a desktop wired to my wall screen. Bluetooth trackball and keyboard on my coffee table. Works well, and I don't have to put up with the bad implementations of the Netflix app I've seen my relatives with cable boxes try to limp along).
I can oppose DRM and still (regretfully) use DRM'd streaming services. DRM was not necessary for any of those services. Piracy still exists despite DRM. DRM is about controlling the end-user experience, not preventing piracy.
W3c had and has zero leverage to force browsers to do anything
Circa 2000 you had a number of vendors pushing incompatible video and audio plugins such as Apple, RealMedia, Microsoft, etc.
If you wanted to publish media and have it work for everyone you had to support at least three formats.
Everybody thought Flash was about games and vector animation and there was no pushback when Macromedia had gotten a working video player into almost all web browsers, which made YouTube possible. Oddly Adobe bought Macromedia at that time and it was downhill for Flash after that... I think primarily because web browser vendors quit fighting over video formats and ganged up against Flash. Had Microsoft, Apple, and others really known Flash was going to win the video war they might not have bundled it with their browsers.
Ultimately HTML 5 killed off Actionscript and today Adobe Animate is alive and well not because people output Flash or even Flash-emulated-in-HTML 5 but because people output cross-platform video with it.
The whole thing was a disaster. Nominally cross-platform video playback was hardly a consolation.
I thought it was a good case study in how somebody who is worried about corporate power when it affects the workplace or foreign policy can be indifferent to corporate power over technology. My friend Harel and I felt pretty firmly that a web based on open standards was going to be good for 'ordinary people' having venues for self-expression. I think Mike Albert's viewpoint is closer to the mainstream though, where most people perceive ease-of-use as more 'liberating' than personal control, like that 1984 ad by Apple.
Today I think it is funny because I like animation-heavy interfaces in video games and think, hypothetically, it would be nice to see some more of that on the web, but I develop a lot of 'intranet' applications that consistently avoid the SPA boondoggle where the one thing I really can't do is animate transitions. I guess I could use HTMX and push the animations out to a 'frame' around the 'pages' that get loaded but that is unappealing to me because I'd like to have completely integrated animations and not a library of dissolves, fades, wipes and loading indicators that are much less necessary if you are loading a 25k 'screen' as opposed to 2.5 MB of Javascript.
Now, with this restructuring, it can make its own decisions about who to hire, for example, and can also do its own fundraising.
This announcement is a magnificent nothing.
Too bad Chrome has now hijacked all of web-related standards.
Steering group is people from the 4 major companies.
At least originally WHATWG was undeniably and undisputedly a good thing. Their work literally removed incompatibilities from the web by producing standards that specify how HTML should actually be rendered, for example.
Now everything is subverted and co-opted by Google, of course.
No they didn't. There's no standard today that exists that describes the implementation level details of CSS 2.1. It's descriptive and you have to figure it out yourself.
Here are all of the standards WHATWG works on: https://spec.whatwg.org/ They also discuss changes to standards they don't work on directly, but effect change through the HTML Living Standard.
In any case, the de-facto standard is whatever Blink does, and there is really no way around that for the foreseeable future.
Can anyone explain this politicking and bad blood? Are there some people upset this long after it all happened?
* Continuing work on HTML at all, instead of furthering work on XHTML + XForms + etc.
* Certain decisions, especially around accessibility & internationalisation, at a point where the editor (then Hixie) practically controlled the decision making.
And indeed, Web Forms 2.0 was presented as a position paper by Opera and Mozilla at a W3C workshop in 2004, prior to the formation of the WHATWG, and voted down: https://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
Strict, structured data could have posed a threat to Google by enabling other search engines to more easily build fact-based competitors and crawl the web of rich data. The decentralized nature of OWL/RDF would have pushed the web closer to P2P aggregation (think RSS, FOAF, pingback...)
The web could have been less Facebook-y, less Google-y, more Napster, more GPT-3 if XHTML had won.
And if anything, Google desperately did and does want people to semantically annotate data. They're extremely confident in their ability to be the best at organizing it, and well-annotated clean data is a huge benefit to them.
It is true that RDF have failed to live up to its promise, but this have nothing to do with WHATWG.
The only time rdf has had success is when there is only an extremely limited vocabulary allowed (xmp, certain other metadata standards) or when the ecosystem is closed so its just one site or group making the rdf (e.g. wikidata)
It was never a threat to google because it was never going to win.
That's a bitter pill to swallow even as is, but now throw in the common practice of mixing in markup from third parties for ads, social buttons, login forms and other things and now you can have a major site outage caused at random by third parties, which, again, cannot be detected server side.
As for RDF, GPT-3 is sort of the ultimate repudiation to that whole line of AI research. GPT-3 doesn't care about structured data at all, it can't even use it any better than a human would.
What XML (XHTML2) was onto, however, was a completely unrealistic attempt to redefine browser behavior and vocabulary, with no buy-in from browser vendors (except Opera?), and with things such as XForms and wildly unproven RDF/SPARQL stuff. Ian Hickson was right in 2004 to fork HTML; browser vendors had no alternative.
A) WHATWG is totally controlled by the browser vendors, which have become even more of a small oligopoly than it seemed they would be 10 years ago. It's basically Apple, Mozilla, Google and Microsoft -- so those four organizations, three of which are enormous corporations, are controlling web standards. (And in practice it seems to mostly just be Google-controlled for whatever reason, but either way). Whereas W3C at least hypothetically was accountable to multiple stakeholders.
B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it.
The biggest difference between whatwg html and earlier w3c html is that people actually implemented whatwg html where w3c standards were more wishful thinking that never got used or implemented (rip xhtml).
XHTML 1.x also did a lot to help shake out things like "quirks mode" versus "standards mode".
HTML 5 imported a lot of things that worked from XHTML 1.x.
It's true that XHTML 2.0 was murdered before the spec finished but that was part and parcel of the WHATWG coup. We have no idea what the final product from XHTML 2.0 would have looked like (it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them) or if it had implemented if it would have been used because the browser implementors had already decided they were going to take charge instead.
That one sentence pretty much sums up why w3c is a bad standards body.
A standards body is not a research group. If you are aiming for the stars you are doing it wrong. A standards body is supposed to be doing the boring work of formalizing what is known to work well, not try and invent new untested things.
Not a lot of people are calling WHATWG a bad standards body, but it is even worse at taking stuff directly out of Blink research and labeling it a draft standard with only a single implementation with sometimes seemingly very little study into its safety or long-term viability.
I suppose there is a small distinction between Ivory Tower academic aspirations and research versus Walled Garden corporate aspirations and research, but at the end of the day it certainly feels the same, and I have more reasons, myself, to admire the academic aspirations that aren't tied to corporate interests and profit motives, but I can understand why some feel what Google and WHATWG is doing is better for the web because they start with that first "implementation" of their research instead of a chalkboard and a hope for a better web.
You seem to think standards should only be built in reverse, which is essentially the WHATWG philosophy: Browser vendors implement something they think is useful, then try to negotiate to get it standardized. That's not bad per se, but it's limited and it's a different system of accountability.
We still don't know if it would have gotten more backwards compatible had browsers tried to actually implement it.
Well, the XML part wasn’t. Serve your XHTML as text/html and it was “supported” by virtue of being treated like HTML with some minor syntax errors. Serve your XHTML as application/xhtml+xml, as required to get any XML features, and it wouldn’t display in Internet Explorer at all.
XHTML 1.0 was allowed to be served with text/html for compatibility reasons, if you were careful to not make it too different from HTML (don’t self‐close an empty <textarea>, for example, and add a space before every “/>”). XHTML 1.1 didn’t allow the text/html MIME type at all, and so basically nobody used it.
That’s not even getting into XML’s unpopularly draconic error handling for pages that did get served as XML…
Including most recently standards that are basically a way to give a thin veneer of respectability to crypto shit (e.g. DID)
To be clear, i am not saying everything w3c does is totally devoid of value. They have done useful work. But its still an org that generally makes bad standards that are rarely followed. The recent bitcoin stuff is shit and basically not a standard. The historical standards are also often terrible, especially when you step away from html (you can't possibly read XMLSignature and think any of it is a remotely good idea).
As an org, its riding almost entirely on the coat tails of HTML, and now that that is gone, what is the point?
> zero accountability to users
Has w3c ever done anything at all that actually helped users over browser vendors? Things like P3P that aren't implemented don't count.
I've found it incredibly useful. For the first time, someone actually wrote down all the details of how to do real-world HTML parsing, rather than having that knowledge all embedded in web browsers.
WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.
Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality.
It means that: 1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec; 2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed; 3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated.
Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions.
Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.
But given the web we have, I think we need to document it.
> It would quickly become unmanageable as libraries would be using different features from different revisions.
As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".
Similarly, you can’t have an HTML content generator that would guarantee that its output conforms to HTML x.y, and thus could be used to produce content for the viewer component.
The only thing that the respective providers of the viewer component and of the content generator could do is to provide a copy of a snapshot of the “living standard” to express which revision they support. But since there are no named/numbered versions, that’s not very practical, and it makes it hard to determine compatibility between such software modules.
This is what the “living standard” fails at, as a standard.
As pointed out elsethread, it also fails by leaving a lot unspecified.
So you don't really lose anything at all by having a continuously updated spec instead of a versioned spec. Hell if you want you can think of the date as the version. Then there's no difference at all. Many versioning systems work like that.
> Imagine writing a Java, C# etc. application to a Living Standard.
Those are bad examples because they have implementations that are overwhelmingly popular and therefore the de facto standard is "what does the official compiler do?".
A better example is C++. Guess what? C++ implementations are incomplete and patchy and often have subtle differences just like with web browsers.
No they didn't. In fact there are whole sections of the web standards that have no normative details on how to implement them other than descriptive notes about how the end results should function. It's a core reason why the Internet Explorer team had issues with CSS composition. It's UNDEFINED.
Not sure what "standard" you're reading. No implementor wants to write against a "living standard" that you have to fork for a pinned date of what your rasterizer conforms to.
WHATWG just links to a bunch of W3C actual versioned standards for the majority of specifications, most of which they didn't actually want to do work on.
Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications.
Oh by the way, for people who actually read the specifications required to build a full web browser know that you still actually have to read WebKit, Chromium, and Gecko/Quantum codebases to understand what they have all silently agreed to do that isn't documented in the specifications.
Why? Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.
I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should?
> Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications.
They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that.
> Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.
Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)
Newer algorithms like flexbox have a formal algorithm with minor undefined details documented.
The entire box model has no normative processing standard. It basically tells implementors, "Well, it should look like this, but you know if you want to do something different, that's fine. We don't tell you how to process glyphs or lines, so figure it out."
Let me put it this way: there is no such thing as a collection of web standards that you can read today and implement a visually similar output to mainstream evergreen browsers. They don't exist. It's a farce, a lie, an illusion. However, you want to articulate it, there it is.
Some subsets are formally defined and provide an actual algorithm you can implement, others describe an output with no processing model, further some standards exist which implicitly require that an undefined formal processing model exists.
You MUST read existing web browser codebases and their explicit comments which specifically say things like, "This is what WebKit/Blink/Gecko/Quantum does, so we do it here, too," in order to create a web browser that does something similar.
It can be as basic as line processing to as nuanced as box shadow processing, or as complex as how subtrees affect framebuffers. Yes, there are CSS properties dedicated to altering the implementation level details of a CSS processing model that doesn't formally exist.
I know this specifically because I wrote a compositor that conforms to a subset of CSS 2.1 and additional CSS Modules.
I STILL don't know how one writes a performant compositor today because what you're supposed to do is write one with a tile-based rasterizer and virtualized graphics commands.
You can't just rasterize subtrees to framebuffers because the calculated CSS may result in dimensions larger than what your hardware can support for backing layers.
Try finding that in the CSS standards.
HTML parsing may have a formal standard now, I've never read it, but the fundamental truth is that it didn't matter if one existed anyway. There was no such thing as a conforming HTML parser prior to then, so what implementors did was read how other web browsers parsed HTML, because that was what users and developers expected, so that was the "true" standard.
This problem still exists today, just in other places.
There are also NO REAL TESTS. There are some manual, human-based, use-your-eyeballs web browser tests that exist, but you can't use them, because they rely on circular logic.
You can't test a web browser by referencing some ground truth that is produced by the web browser when you're testing the exact features that generate said "ground truth."
It's also impossible by definition to test browser rendered output because the output is implementation specific. There's no comparing output to a reference rasterization, because now you're dependent on properties that in the specification are left to the implementor to decide what they want to do.
There are really three independent things in play:
- DTD's define a set of valid elements and attributes.
- Quirks/standards rendering modes affect how CSS is rendered.
- The HTML/XHTML divide is about the low-level HTML syntax and how invalid syntax should be handled.
These are all independent concerns since CSS operates on the parsed tree of elements and doesn't care about lexical syntax or DTD's.
XHTML did not attempt to address the quirks/standards mode issues at all, since this is the domain of CSS.
The DTDs were a signal designed to opt into different parsing and rendering modes, including CSS rendering differences (and as I recall even differences in ES3 mode "option strict"/proto-ES5; though memory is hazy and I don't remember which browser I think did that in my testing at the time) and DTDs were a simpler signal than most of the other alternatives at the time and since (META tags/Headers). They were never independent concerns in practice, though sure they could have been in theory. Rendering changes were one of the reasons few developers opted into XHTML 1.x Strict.
The issue around DTD's is confusing because browsers use the <!DOCTYPE>-tag as a signal to switch between quirks and standards rendering modes. This might suggest a connection between the DTD's and the rendering modes, but in reality browsers have always ignored the DTDs. They just match the <!DOCTYPE> against some predefined strings to determine the mode. And the DTD's was never designed for this purpose, it was just a hack introduced by browser vendors.
> Rendering changes were one of the reasons few developers opted into XHTML 1.x Strict.
XHTML 1.x strict was rendered the same way as the corresponding HTML in standards mode. But given the confusion around the issues, it is possible some developers thought it would render differently.
https://whatwg.org/
https://en.wikipedia.org/wiki/WHATWG
The WHATWG was formed as a cartel of browser vendors that pretended to be a standards body. And these days even ‘cartel’ may be too generous, now it’s just a Chrome rubber-stamping committee.
In the meantime IE6 had all but won the browser wars and completely strangled innovation in a striking demonstration of the problems with a monopoly. The web needed to be shook up.
WHATWG was created in frustration with that approach and saw the XHTML and other XML stuff being a case of Architectural Astronomy (which is not to say they weren't doing anything, just they weren't doing anything seen as useful) and they created HTML5 which was a standard based on how HTML worked in the wild and explicitly codified how tag soup and other invalid pages should be shown.
HTML5 really revitalized the web at a time when it was pretty stagnant. WHATWG has always had a pretty practical approach to standards that boils down to the fact that whoever builds a browser ends up having the final say in what goes into the spec because it doesn't matter if there is some cool feature that nobody wants to ship, if nobody ships it it's fundamentally not part of the spec because it can't be used. This does end up meaning that WHATWG ends up being just made up of Microsoft, Google, Apple, and Mozilla. There is some irony as the descriptive HTML5 which tried to codify how HTML worked in the wild made it so complicated to create an HTML parser that now only a megacorp could actually afford to do so.
- Under the new model, corporations will be able to more aggressively influence funding, and thus be better able to ensure their interests are represented by new staff members responsible for shaping debate on features.
- But under W3C's old model, where budgets and hiring were subject to approval by university liasons, staff couldn't be hired with enough agility and bandwidth to prevent those corporations from being overly aggressive anyways. Perhaps with more non-corporate-aligned humans being able to wholly focus on standardization now, there will be more attention paid to community engagement.
I suppose time will tell. When it comes to things like FLoC (now Topics) [1] the privacy implications of having an agile standards board are more important than ever, and may actually have significant impacts on people's physical safety.
[0] https://associationsnow.com/2022/08/world-wide-web-consortiu...
[1] https://blog.google/products/chrome/get-know-new-topics-api-...
What ever Google wants, the W3C approves as "standard"
[1] tallying across chromium-based browsers: https://gs.statcounter.com/browser-market-share#monthly-2022...
What Google does, is publish a "draft" which is as far from a standard as their authors are from the Moon. This gives Chrome the leeway to call it an "emerging standard" and just ship it. It doesn't care if there are objections, or that other browser vendors will not implement it. It's now a "standard" in Google's dictionary.
For something to become a W3C standard even in the present world, you need a consensus and at least two independent implementations. None of that exists for stuff Google pushes out (hardware APIs, web transport, constructible stylesheets [1], the list goes on...).
The correct name for those is Chrome-only non-standards.
[1] These one isn't even a draft. It is.... "a collection of interesting ideas" in a working group https://wicg.github.io/construct-stylesheets/ Shipped by default in Chrome, of course
Calling it Chromium makes it sound like they somehow originate in the "open-source" version. They don't. We have to call them what they are.
Most of Chromium-based browsers will probably lag on those features because they either don't want them, or have their own release cadence, or are running an older version etc.
And it's only Chrome that pretends that their non-standard features are standard, and employs a large network of propaganda from web.dev[1] to dev rels[2] to advertise them as standards.
[1] Example WebTransport https://web.dev/webtransport/, multiple non-standard hardware APIs https://web.dev/devices-introduction/
[2] I sadly lost the link to tweet from either Justing Fagnani or Alex Russel where they called the decision to ship Constructible Stylesheets "bravery to move the platform forward". Context: trivial deadlock issues in the spec, both Mozilla and Safari were dead set against it until issues could be fixed, Google-led lit-html wanted the functionality, so Chrome just shipped it.
The real issue is allowing folks with a fat salary to advocate in bad faith against a healthy internet. (Along with shit like moving the Chrome team into the same building as Mozilla HQ and poaching employees for years.)
If anything, this is likely going to result in the W3C having fewer staff and lower costs, and thus only needing membership fees to cover a lower sum than it has previously.
This sounds like needless fear-mongering. Is there anything to backup any concerns about people's physical safety?
A good overview of the context: https://digiday.com/media/we-cant-un-floc-ourselves-googles-...
More detail: https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-...
When it comes to Topics, it's essential that there be hands on the wheel at W3C that approach the solidification of e.g. the Topics taxonomy https://github.com/patcg-individual-drafts/topics/blob/main/... from a neutral perspective that takes into account the various ways in which proposed topics could be dangerous, and how strongly to word the specification to prevent it from creeping in increasingly privacy-eroding ways in the future.
Ok the question is how to achieve these goals and are those having failed to deliver on these goals for 28 years now according to their own words really the ones to expect solutions from, as W3C, Inc of all things.
I'm sorry but all I can see is W3C, Inc. acting in their own interest, for job security. Because core web standards such as HTML are specified elsewhere (basically by random people on github, but mostly Google employees and other financially dependent people who're calling themselves the WHAT working group), leaving only CSS at W3C, and it's a fsking mess. Maybe we can get W3C to work on a formal CSS spec or, better even, a reference browser rather than la-la specs. Though I fail to see how that could be financed under either their old or new funding model.
This is more of a "what were they thinking?" situation than we actually losing anything.
Obviously CSS has evolved way beyond that nowadays and you need an extension on most browsers to even use something like that. But I think there's a value in a project like Amaya making these tools front and center instead of stashing them away in ways only "developers" are meant to use. I'd hope it'd cultivate a sense making the web work the way you want it to work amongst the general userbase
I would actually like to see the project reborn some day
It is painfully obvious that just about everybody who speaks in that certain way is primarily/exclusively concerned with their own job security. Welcome to Zombocom.
The above comment is a perfect example: criticising the W3C for being a "fsking mess" due to forces outside of their control (the ownership of web tech by a very small number of very wealthy web client corporations).
It's just the way things have gone.
You're right that the W3C has no actual power to dictate what gets standardised anymore; they squandered that, so now only WHATWG's word matters in the end. The only power the W3C has is their ability to influence public opinion, their voice is still rather meaningful in the public debate. They could've used that voice for good, taking the side of the EFF and other pro-freedom organisations to denounce DRM. In the end, they would have had to begrudgingly accept WHATWG's DRM standard if it came to that, but they could've made it clear along the way that it's a terrible idea. This would've put them squarely in the pro-open-web camp, and would've made it clear to the public that the WHATWG is in the anti-open-web camp.
Or they could've stayed out of the discussion, accepted their irrelevance, and just adopted the W3C spec.
But they chose to actively enter the public debate around DRM in favour of this user-hostile, anti-open-web standard. They chose to use their influence to convince people that DRM is a good thing. They're on the record as being in favour of a web where it is impossible to make a proper open-source web browser which can render any standard web page.
In my book, the W3C's stance is clear as day: they're actively hostile to an open web, and they're prepared to spend any influence they might have to fight against it.
I'm going to be Devil's advocate here and say that DRM ostensibly protects the IP of content originators who I think we'd agree should be rewarded for investing in or creating that content.
Perhaps you have some other scheme or perspective on how content originators/creators can/could/should monetize their IP without DRM? Genuinely curious what alternative schemes are viable for protecting and rewarding content creators.
(Yes; let's all acknowledge that even with DRM, pirating still exists)
1. Content is priced way the fuck higher than market value.
2. Content is so encumbered that it is difficult to even get it or use it.
The way I see it is that #1 is not a problem for content creators. It is relatively rare compared to people buying content and the person who would rather download an episode of The Office rather than paying Apple $1.99 for it was unlikely to pay if that was the only option in the first place. Their alternative to piracy isn’t to spend the money. It’s to watch something else.
As for #2, it is a self-inflicted wound. There was a time when the 6th Harry Potter movie was about to come out in theaters. I wanted to do a marathon watch of the first 5 movies with my family. I had the first 4 on DVD and wanted to buy the 5th. I checked all streaming services and none had it. In fact it appeared that some removed it a month prior. I then called several nearby stores and all were sold out. A store 20 miles away had a copy for $40. After spending nearly an hour to find this out, I spent 5 minutes downloading it off a torrent site. Maybe indestructible your content will net you more money even if you have some of your content pirated.
For $17/mo, I can access an endless stream of content on Netflix. This is way cheaper than I remember my cable subscriptions used to be (if we consider the cost of Internet access as fixed in either case). Verizon is even offering to throw in Hulu, Disney+, and a bunch of other streaming services "free" if I switch to FIOS + mobile.
I can watch Netflix on my phone, tablet, PC, TV, Chromecast, Roku, Apple TV. I can watch any show, any time I want, as many seasons and episodes as I want. 24x7x365. Is it really encumbered? Aside from IP owners walling off their services, content -- as long as you pay for it -- flows more freely now than ever, IMO. If I go to an Airbnb, I can log into my Netflix account and watch all of my shows. I can log into my Amazon account and watch all of my purchased movies. (Just don't forget to log out!)
Yes; I can't watch it offline or if I'm in a location with poor Internet speeds. But that is such a small fraction of my time that it hardly registers. Yes; my right to view content I've paid for can be revoked in some circumstance I'm sure, but it's never once happened to me.
$17/month for netflix is great when you have an income. As a poor student, that’s $17 I can save.
Part of the problem is that it’s not ‘content’ that you want to subscribe to, but ‘specific content’, which might be spread around 3-4 different services that all want that sweet sweet monthly fee.
Much like DVD region locking, the majority of the population doesn't care, and those who do are capable of overcoming the DRM anyway, but the latter is illegal, and leaves no room at all for people who want to comply with the law but not with Google's device mandates.
Maybe Netflix is a good value if your primary goal is to have an endless stream of content to watch and you don't really care what it is. But if you watch TV less frequently, it's absolutely terrible value. And if you want to choose what series to watch rather than which streaming service to watch, the constant switching between streaming services is terribly tedious, and another source of increased cost if your interests don't change perfectly aligned with billing periods.
I know someone who just wants to have copies of all movies and TV shows. He spends way more effort on keeping up his storage array and downloading things then he does enjoying the movies. But for every one of him there are 10,000 regular paying consumers. Is he worth worrying about?
Edit: Here's a worthy read for the topic:
https://web.archive.org/web/20140906214521/https://plus.goog...
In terms of convenience DRM doesn't change a thing, because from the consumer's perspective it's all there on a torrent site, there's no way to even know if something had DRM unless you look it up specifically.
Do you take the same view that game developers should just abandon anti-cheat because it can be cracked? Should online games just abandon anti-cheat schemes? Would that be a better experience for the gamers and the developers/publishers if we just abandoned anti-cheat because it's not perfect and there are always cheaters?
Let me get this straight, though: you would rather that CoD, Fortnite, LoL, Lichess, etc. just make it open season; no anti-cheat. You believe that as a gamer, your gaming experience would be enhanced if there was no anti-cheat.
If that's your logical conclusion -- that no anti-cheat is the answer because there are always going to be some cheaters -- then I have nothing. We'll just have to agree to disagree. As a gamer, I'm happy to install anti-cheat if it can defeat the majority of casual cheaters -- even if it costs some frames or adds overhead to the startup time.
Imagine that online banks would do login checks on client side, and you'd have to install anti-steal software before you can login. Would that be acceptable to reduce fraudalent transactions? Of course, there'll still be a signifcant amount of stolen funds, but it'd prevent most of your neighbors to login to your account.
Well, this is horrible design (and has basically happened with credit cards btw...) and you should address it at it's core, by bulding the architecture in a way that such fraudalent transactions are next-to impossible.
My point is: if cheating is so much of an issue, games should be architected in a way to avoid the ability of cheating from client-side at all, without additional monitoring required. Anti-cheat is a bad workaround to a core development problem, at the expense of the customer instead of developers.
FWIW, I pay for nearly all the streaming apps and still get the file itself through ${other means} because I want it for offline viewing/future viewing etc just like we used to be able to with DVDs. If the streaming provider provided this file, I wouldn’t need to resort to these other means and they wouldn’t lose a customer who now already has to have an alternate pathway to get a soft copy of the file.
Sure it would!
Without DRM, there would be no digital distribution the way we know it today.
That's the point. We want digital content without DRM that is not locked to players approved by the distributor.
Is there a scheme that you would propose that solves this problem?
EDIT: Wow, I didn't expect "it should be legal to make an open source web browser which can render any standard web page" to be so controversial. I'm disappointed.
FYI, widevine is not open source.
[1] https://news.ycombinator.com/item?id=29709939
Ostensibly is doing a lot of work here because it literally does not. I can torrent any show or movie that is otherwise being streamed with DRM. DRM is a complete farce that serves no actual purpose but to make idiotic media executives happy.
You might be able to torrent any show or movie in high quality with a private tracker, but it's hard to come by 4K HDR content just hanging out for free these days.
Even if that's the case, that's not an issue of DRM, that's an issue of distribution.
It's also just flat out not true. Sure, some of the 4k HDR content might originate from PTP/BTN/scene/w.e., but it's readily available on e.g. RARBG.
The latest 26 patents (the 2021 patents) are all in Apple's name. It's pretty clear what they do, which is different from the marketing speak.
[1] https://www.w3.org/2004/01/pp-impl/patents
DRM would exist on the web with or without standardization from the W3C.
>the WHATWG and the W3C has made it impossible to make an open source web browser which can render standard web pages.
Chromium is an open source browser which can do that.
a) Copyright infringement is not theft.
b) Copyright holders do not own the content, they hold a temporary monopoly over it.
Every DRM scheme out there has been broken (or will be soon, if it just came out). It is trivially easy for any interested party to find copies of content with DRM removed. In fact I'd say this content is more accessible than if there were no DRM and the only obstacle were having to splice together chunks of unencrypted stream data transmitted by the authorized source. I was at someone's house the other day, a Netflix subscriber mind you, and the Netflix app wouldn't work on his laptop for whatever reason. He went to a pirate site and had the show playing within 30 seconds.
What DRM does protect, is the market position of equipment and software vendors that have the resources to sign on as DRM licensees.
https://github.com/whatwg/html/issues/7810
[0] https://www.w3.org/TR/activitypub/
[1] https://support.mozilla.org/en-US/products/firefox-os/basic-...
Maybe W3C bungled things with XHMTL 10 years ago, trying to pull the web toward TBL's original vision of something like a giant Wikipedia. But things are very different now, having spent the interim in service to browser vendors and their monetization of control over user data.
The mission is arguably much clearer now.
Are people increasingly aware of that? Because society at large still seems to want to chanse after the latest shiny gadget without considering the full cost of the T&C.
Basic (x)html forms can do wonders.