Standards should be standards regardless of vendor client adoption #89
Comments
|
Guess my previous comment fits in here better too: In general the question is why bowing down to the dictatorship of one single developer and one single browser (Google/Chrome)? Chrome/Chromium has in the meantime such a high market share and the people behind have more or less the decision power of what should and should not be standard or desirable - it should be evaluated if this is really the way today the web is going to go. Such things are highly questionable and not desirable at all - because if one single developer group - Google/Chromium - has the ultimate decision power... then there is clearly something more than wrong! And if that alone would not be worse enough... Just compare it with years ago.. We had many different browsers with different feature sets and a wide variety of engines - even that has gone lost and all the feature diversity has been replaced by Google's design principles - how a browser should look and work - and adopted without questioning by Mozilla and Opera and now even by Microsoft! How about doing the right thing and showing Google that they are not omnipotent? |
|
Adding my feedback which was Note about your working mode: your working mode is going to be increasingly unworkable as the number of browser engines diminishes and you would still require two browser engines to indicate interest. We're heading towards a monoculture here. Also, there have been more than a few occasions where something was added or changed in the spec to reflect what Chromium implemented, and other browsers only adopted or shown interest in adopting it after it was added to the spec. That did not meet your criterion of "at least two". In line with what @mattatobin said above I'd say the <style scoped> issue is a clear case of a feature authors have wanted for many years (see whatwg/html#552 for details), and the HTML standard should stick to its own design principles where implementers should "listen to" the spec in the vast majority of cases (and spec changes in the other direction should only occur on rare occasions if the spec really is wrong or asking for something disproportionately illogical/difficult to achieve). Users and web authors should lay the groundwork for specifications, and specifications should give incentive to implementers to add features. The fact that we got to that point and then was reversed because an implementer refused to show interest (while I didn't see any disproportionate difficulties in the implementation) goes right against this. One implementer not only displayed interest but actually -had- and implementation of it and shipped it. Why was it removed from the spec in that situation? There being interest of an implementer AND an great desire for a feature from the web author corner should IMHO simply have left implementers refusing to "do their job" being not in compliance with the spec, and not have the spec be molded to appease an implementer no matter how much market share they have. |
|
The Steering Group has not discussed this yet, but here are some preliminary thoughts and clarifications:
I personally think these policies are largely good as they are, and do not give a single vendor effective veto power over the web platform. If the web platform dropped down to only two implementations or only one, the rules would not be very workable as written. But today we have at least three active independent implementations. So in response to the general claims here:
Now, that's all generalities, let's get to the specific
(Side note: while I work on WebKit at Apple, I don't actually know offhand what our opinion is. Styling experts would be the right people to ask.) |
|
Thanks for your feedback. I have a few points of my own about the "general points":
Regarding the |
|
Thank you for your further thoughts @wolfbeast. Some comments:
I agree that the shrinking number of engines is concerning. If it falls any lower, the web standards process could become entirely dysfunctional. I think it will work ok with 3. Of course, it's also possible the number will go up, either due to forks or innovation.
I think it's important to clarify that the WHATWG process is very different from the W3C process. When a change is integrated into the specification, it's part of a Living Standard, not just a proposal. The requirements for changes to be incorporated in a Living Standard are closer to the expectations for the W3C's REC maturity level than CR, WD or ED. The WHATWG's Working Mode suggests a number of ways to develop proposals that aren't quite ready to be folded into a Living Standard. Anyone who wants to could take one of those approaches even without indications of implementor interest.
In my view, it's beneficial, not a dangerous conflict of interest, for implementors to be actively involved in standards. The standards world is healthier for their involvement. I'm not in a position to speak for other standards orgs. But at least in WHATWG, I can vouch for the integrity of editors, deputy editors and other contributors, and their willingness to follow the WHATWG Working Mode and other rules.
It's definitely healthier if implementors state their reasons for not being willing to implement something. That way, it's sometimes possible to figure out refinements or a compromise that would lead to broader interest. However, the WHATWG does not judge the validity of reasons as part of its process for reviewing additions and removals. In our view, as codified in the Principles, it is a disservice to the web platform to call something a standard if it will never be implemented, or if it will forever be a single-browser feature. Many other SDOs take an initially aspirational view of standards. But almost all of them have a reality check at some point in the process, where things that aren't implemented can't become full standards. In WHATWG, that point is earlier than in some other cases. The Living Standard model requires this level of scrutiny, because anything that's incorporated is considered a standard, not just a proposal. There are however many ways to have proposals or drafts that are not yet incorporated into the main document. While this is somewhat unusual, it has served us well, and I don't foresee the WHATWG changing course on this approach. |
|
Okay, here is the simple and direct process in the practical real world as it has been observed in recent years. Something is perposed. Mozilla may or may not support it. Chrome developers approve and implement or reject it. Mozilla files Chrome parity bug. Thing is either implemented or removed from Mozilla in accordance with Chrome Developers final decision. WhatWG uses their rules to push or drop the thing in regards to standards. In another case, standard is modified, extended, changed. Chrome yay or nays it likely based on their corporate plans and intrests. Bug is filed for Chrome parity at Mozilla. Both are aligned. WhatWG rules reenforce that decision. So what I see here is that the WhatWG rules and much of its personnel cator to Google and as per rules pretty much anything that can happen does happen because with little exception Mozilla is going to follow along with a Chrome parity bug. Thus the rule of two now and going forward is effectively a rule of one. Google. There seems to be no way to avoid it going forward without adapting the rules and processes to counter today's real world reality of a defacto if not actual monoculture in who exactly defines these standards. This right now effectively bypasses and nullifys Webkit, Goanna, and any other engine as well as web developers in any practical sense. You are saying everything is as it should be? I am not so sure. |
|
The bottom line seems to also remain that in your current working mode implementers are given deciding power either way, since they both propose new features to the standard (whether the real world has any desire or use for them or not) and decide on their inclusion. As stated before that seems to be very wrong. What about the "Priority of Constituencies"? Shouldn't it be that authors should be considered over implementers? Your decision making seems to be flowing in the opposite direction of what the design principles state.
Unfortunately the real world now is one where one (or maybe two) browser vendors decide which feature will be added or survive (and as stated browser parity quickly makes that a "the largest market force decides" because the real world is that users will have their mantra "but it works in Chrome", causing the dreaded browser-parity-despite-the-spec responses from other vendors). All of the things I indicated above play into favor of this, and should be re-evaluated. |
There's a difference between 'involvement' and 'voting power'. Further, granting voting power to implementors makes total sense when said implementors are acting in the best interest of users and web developers, essentially acting as their delegated representative; but especially for Google, some hard questions need to be asked as to whether that assumption of good faith still holds today. |
|
I have a clarifying question. What do people think would be the gain of putting something in a standard that zero browsers implement? Or putting something in a standard that is a single-vendor-only feature? That seems to be what you're advocating, instead of our current position of requiring multi-implementer support. In our experience, having proprietary (single-vendor) or fictional (zero-vendor) features in the standard has only served to increase confusion among web developers and users of the platform. I do not want to return to that world, but some in this thread are advocating for doing so, and I don't understand what they think would be accomplished. |
|
The problem is, @domenic, is that you and several people in WhatWG and a half a dozen other working groups are those with huge conflicts of intrest because you are Google employees and Google is the dominant or indeed arguably the defacto master of web standards. As I stated, anything Google proposes Google gets because Mozilla (or Webkit) will follow with a browser parity bug that aligns it to whatever Chrome Developers decide while web developers have little to no practical say or recourse. Just because the majority of web standards originated by Google are officially sanctioned by parity bugs and reenforced by WhatWG doesn't mean that the system isn't stacked in Google's favor. No company or indeed person should have that much broad power and influence in defining all these standards. It should happen natually and organically. Here is a theoretical case to consider: Mozilla and Webkit decided to adopt something and it by rule of two became a standard but Chrome refused to implement or decided alternative behavior was better. What do you think will happen then? We have seen what happens before. Google being dominate would have their behavior or lack of the feature be the deciding factor over time and removal from Mozilla and/or Webkit or those engines would align to Chrome behavior and the spec would be changed even if web developers prefered the Mozilla/Webkit behavior. All this isn't anti-Google perse because the same applies if this was the old days of Mozilla being dominant or Trident based Internet Explorer or indeed someone else. I want to be clear on that because I know it will be in the back of the minds of some people. What ever happens going forward something needs to change because the playing field isn't very fair as it stands today and indeed the center can't hold less WhatWG becomes a figurehead for whomever has the dominate market share no matter who it is at the moment. |
|
I don't feel that answered my question. |
|
I am sorry you feel that way but I think that it does. |
Let me answer that with a (kind of rhetorical) question of my own: Where do web standards come from? Standards should come from features that enhance the web. These features come from a desire of web authors or users for specific functionality to be present. They shouldn't come from any vendor or implementer who has a selfish motivation of creating and implementing such a feature (ding-dong proprietary feature anyone?), which in turn, with peer pressure, is forced upon other vendors and implementers who might otherwise fear becoming insignificant -- I only have to think about MSE and EME here to have a painfully-clear example of that -- leading to browser-parity bugs on features nobody (except the first implementer) actually asked for in the first place! But I'm feeling I'm having to come up with different ways of saying the exact same thing over and over -- that is not my function. I'll summarize key points here:
|
|
This thread is getting out of hand. Piling on Google is not appropriate and some posters are coming close to violating the WHATWG Code of Conduct. Nor is piling on implementors in general. Proposals for how to change the Working Mode, Workstream Policy, Principles, or other policy documents, would be on topic. Attacks on Google or browser implementors in general are not. If posters cannot remain constructive and continue with personal attacks, I will start handing out bans or lock the thread. That said, I want to respond to the claim that only implementors can make proposals, or that there's no room for proposals from content authors, server developers, experts, or whatever. That is simply not true. I cited the many ways to make a proposal earlier, and none of them require working for an implementor. In practice, employees of non-browser companies like Akamai or Cloudflare, or independent contributors, have been able to propose ideas that have been duly incorporated. Claims to the contrary should be backed by evidence. |
|
I feel defining the issue is important to then move along to solving the issue. At the moment, I think the issue has been well defined and on-topic but some may disagree with the latter but I am sure the former is clear so let's move forward. I was initially going to ask to which specific standards Akamai or CF contributed to that became standards without the involvement or support of any implementers? Then I realized my error based on your error in your assumption. You responded to "the claim that only implementers can make proposals" which this whole thing isn't about and I don't think anyone made a claim otherwise because of course anyone can propose something.. This is about how the standards are entirely justified and sanctioned by implementer willingness instead of standards justifying them selves based on natural and organic needs of the web by users and web developers etc with implementers responding in kind. The entire process is what needs to be changed. This, btw, is why everything that has been said is on-topic. Implimenters have too much power and via situations like those outlined above result in one party making the decision and one party following along and bam you get your "multiple implementers on board" to push the proposal into being added to the standards. So on one hand we have a strawman argument for not changing anything and on the other hand we have a response to a claim that never happened. |
As an Akamai employee, I have implemented Preload, Preconnect, and Client Hints. Before that, as an independent, I implemented As @othermaciej pointed out, there are multiple misconceptions in this thread that need to be dispelled. Anyone can contribute to standards. Anyone can point out missing use-cases, work on proposals to address them and integrate them into WHATWG and other standards. On top of that, anyone can implement browser features, as all engines today are open-source. But the engines reserve the right to accept or refuse patches, as well as the right to decide what they ship, which is their prerogative. That means that non-browser-vendor contributors can drive specification and implementation of features browsers deem useful, but not ones they consider harmful or in conflict with other proposals. @mattatobin - you don't say that explicitly, but I suspect you're thinking that removing the WHATWG's restrictions would somehow result in spec authors forcing implementers to implement and ship features. That was never the case neither in the WHATWG nor the W3C. (nor other standard bodies, e.g. the IETF) I highly recommend you read @slightlyoff's blog posts on that front (1, 2) to get a better understanding of how standardization efforts work. |
|
I don't want to force anyone to do anything. I just think that implementers should implement standards not dictate or at the very least not be able to approve or reject them. Getting into situations where they can propose AND approve via support and interest should not even be something that is allowed to happen. Natural market forces and user demand can decide what standards are implemented in what browsers. The same can be said for making the standards.. standards themselves. If one browser/engine or another doesn't or implements it poorly then that is their decision. Of course, it is in their best interest to do it according to the standards as 20 years of hindsight will attest to. As far as the proposal stage, well browser makers, corporate entities, web developers, and general users should all be equals. That is how the web can evolve naturally. If things stay the way they are then the web will always be bias to corporate whims implementing features to support their corporate goals and making them standards with little trouble and not always for the betterment of us all. Standards should be deemed standards by the people not corporate entities or their agents and certainly not by a mere two of them for reasons outlined above. What if as a transitional action it was expanded to include interest and support of three engines. Namely, Blink, Gecko/Servo, and Webkit? Would that be an interim solution that would be acceptable? Though, ultimately the core issue remains but at least it would reduce the real issues I have outlined above. |
|
So, it seems that giving a description of the way things work in the real world now is considered a breach of conduct and grounds for bans? My, how far we've fallen. If you think me, speaking my mind and trying to improve the working mode here for everyone's benefit by asking critical questions and making critical observations about how things are done incorrectly and not in the best interest of the larger community of internet users and companies alike, should be subject to a ban, then so be it. You'll be banning an implementer who has the common sense not to be heavily involved in spec writing because it would, without a doubt, lead to heavy bias if so. I think that bias is shining through pretty heavily already here -- some might even call some people taking part in this discussion strawmen, just by reading through what's being said. Let me just add this, condensing it all into one, easily digestible statement, even for those less educated in software market dynamics who seem to have trouble grasping concepts like "peer pressure", "browser parity", and "fear of becoming insignificant by not adopting an extended/proprietary implementation": Standards should primarily be defining in nature, not describing. Before you go and harp again on the "don't write fiction" point which has been used as the sole pivot to push changes, let me remind you that a request leading to a feature is not fiction. The request and desire for a feature is real, and should lead to a real specification. Whether that specification is implemented by anyone at the point it is added should not matter, and the specification should, as I stated several times now, be an incentive for implementers to "do their job" and implement it because the spec asks for it. That is how things were done for a while, and we were in fact going into a good direction as a whole -- up to the point where the whole "Oh but we can't have anything in the spec that implementers might find offensive" became a thing and editors were looking at what was implemented before looking at what was desired, becoming primarily describing in nature. Also because, once more, it would be the editor's back yard, doubling as an implementer. |
|
There's a lot to consider in this issue thread:
I think we can answer #1 pretty clearly: WHATWG was created because W3C mistakenly thought "Standards should primarily be defining in nature, not describing". W3C effectively deprecated HTML in the period 1999-2004 and defined an alternative XML-based web platform. They thought would be a better basis for the web, and expected browsers to go implement it because it was "the standard". Nobody did, and the HTML development community created WHATWG to maintain and evolve HTML. The thinking crystallized in about 2011 as the idea of Living Standards that describe the ever-changing reality of the web. New standards are incubated by various means (prototypes, experimental features behind flags, polyfills, etc.) and they don't become part of the Living Standard until there is rough consensus, running code, and implementer buy-in. So clearly WHATWG isn't interested in changing the working mode to be something that is fundamentally incompatible with its founding philosophy. That said, there's lots of room for improvement in #2, how browser implementers and web developers work together at WHATWG. I think the basic approach in the working mode is sound: website developers and other consumers of the browser engines are encouraged to tell the community about problems they're having using today's web platform described by the Living Standards, why existing features aren't doing the job, and engage in dialog with the spec editors and implementers on what would do the job better. But if there is a spec being incubated out there that you want the browsers to actually implement, this isn't the venue, and WHATWG putting it in a spec won't really pressure anyone to implement it. All the browser engines are open source projects that (in principle) take code contributions, and in practice have public discussions about their "intent to implement" and "intent to ship". WHATWG could be a good venue to discuss how to change specs to overcome the reasons implementer won't ship them. I suspect the SG would appreciate constructive suggestions on how to make the WHATWG culture and working mode more welcoming to hands-on developers with ideas for how to evolve the web platform make their jobs easier. #3 and #4 above are interesting things to discuss, but I don't think are all that relevant to an SG issue about the working mode. |
|
Hi there. Google web standards person here. Former Microsoft IE standards maven, during their dominant days. I have a really good idea of how many different ways standards can go wrong. @wolfbeast and @mattatobin, I think you're both underestimating the role that authors and others play in the creation of standards today, and missing out on the importance of having standards that actually ARE descriptive. @wolfbeast says "Only on the very rare occasions that in hind sight a written specification turns out to be wholly unrealistic or disproportionately difficult to implement and maintain" - but I can tell you from direct and indirect experience than a request and a desire for a feature is the beginning of a journey, not the end, nor even the midpoint; and final written specifications that weren't based on implementation experience while they were being designed are nearly ALWAYS disproportionately difficult to implement across different platforms and engines. The WHATWG's "don't write fiction" applies, as @othermaciej said, to not putting possibly-desirable-but-unimplemented features in a Living Standard - which is supposed to be an accurate representation of the platform as it is implemented. The proposition that features should be written into a spec as 'an incentive for implementers to "do their job" and implement it because the spec asks for it' is extremely naive; it just changes the prioritization from "how do I get this feature slammed into the spec" instead of the mature necessities of shepherding a feature from idea through incubation, implementation, proving it's viable across platforms, and shipping. Aside from that, I'd point out that no vendor in my experience has EVER shipped features just because a spec demands it. (And I've worked for 4 different browser vendors across the last 25 years, and am close personal and professional friends with people at the other engine companies AND across the standards community, and I don't think any of them would say any different.) For PR reasons, like filling out some of the more esoteric bits of the CSS Acid Tests, sure. For compatibility with other vendors, absolutely. Just because it's in the spec? Not in my experience. The proposal that "features can be proposed and considered by spec writers for inclusion in a standard while there is only 1 or 0 implementers currently supporting it" is not prevented today - in fact, it's highly recommended: you can propose and develop features in the incubator (WICG) with no implementer interest at all. Specifications don't give incentive to implementers to add features - solid developer demand for well-designed features does. We (collective "we" of browser engine workers) DO pay attention to developer needs, you know. (Side note - your recasting of EME and MSE as single-browser-driven is not, in fact, true. It was driven by developer demand - a relatively small set of developers, perhaps, but definitely not by a single browser vendor.) I do strongly disagree with the idea that "Standards should dictate what html, css, javascript, etc is supposed to be and clients should respond with support or not at their discretion with all the consequences of that decision." That world actually has provable ended up WORSE for authors and web developers, with massive incompatibilities of how to do things. If you don't gather experience as you incubate features, prior to declaring them as standards, they will be broken. But at the end of the day, I'd suggest thinking of it this way - browser engine vendors don't dictate what's in the standard. They do spend an inordinate amount of money building and shipping the web platform, and they do control what they ship; good engines prioritize features that benefit the community, not themselves, and they sink their resources into incubating what they perceive as the community's needs. If you feel needs are being unmet, I'd strongly encourage you to propose features in incubation and help develop them there, rather than rage against how the final standards are polished up. But you are, of course, free to disagree - we browser engine vendors have deliberately gone out of our way to open up the standardization mechanisms, from pushing hard to incubate all features (enabling community members to participate in the early days of features) to ensuring that standards are in fact forkable, if the whole game ever did go south. If you believe "implementers have too much power," you can create a different standard. Note that the "close to violation of CoC" comments here are the implications that Google is not acting in good faith (if you have specific examples, please do share them), implications that browser vendors are merely implementing their corporate goals and do not count as "people" (we are), and statements like "with little exception Mozilla is going to follow along with a Chrome parity bug" (absolutely provable false). |
|
I’d also like to see e.g.: the following would be valid: <button id="something">Something</button>
<menu type="context">
<!-- menu item is an ID reference, so the label is the content of `<button id="something">` -->
<menuitem command="something" />
<!-- menu item isn't a command, so the label is the text content -->
<menuitem type="checkbox">Checkbox</menuitem>
</menu>and would produce the following DOM: But sadly, Google rejected it, and now Mozilla is the only implementor. |
|
The Unified XUL Platform's Goanna Rendering Engine also supports it. But I think that is off topic to this issue. |
No reason given. How disappointing (yet not entirely unexpected, considering the way things are handled in the current soon-to-be-monoculture approach). let's just say I'm sorely disappointed that y'all seem to ber OK with trying to silently sweep this major issue under the rug. What did you think... (almost exactly) 2 years was "enough time for people to forget"? |
|
@wolfbeast, @annevk asked me before closing and I agreed with it. I'll give a reason. The discussion in this issue isn't leading to any concrete suggestion that seems like an improvement to how the WHATWG is operated, at least not for browser vendors. Meanwhile, there are lots of venues of writing web standards that have a lower bar for implementation interest, as it should be for ideas in incubation, in https://wicg.io/. Right now the WHATWG doesn't have an incubation track, and I think maybe that would be nice, but it would be something separate from what we label Living Standards, which should follow https://whatwg.org/working-mode because in our experience that leads to better outcomes in terms of interoperability. |
|
It would have been nice if that reasoning was given before closure, not as an afterthought. I'm sorry but suggestions were given in the discussion in this issue. As an outsider to the WG there's very little I (or others in this discussion) can do to make it more concrete, is there? After all only WG members can decide how best to translate this concern into something practical for the WG to follow. This issue indicates a major problem in the way the standards are defined and enforced. Something needs to be done about it. Just ignoring it and redirecting people to an incubator won't do anything to deter or slow down the current vendors with an iron grasp on what is fast-tracked into standards. Your working mode for "living standards" does nothing but support that inverse flow of feature development on the web that is solidly in the hands of implementers, as explicitly detailed here by a number of people. |
I think that's a misunderstanding of WHATWG and the web standards process in general, at IETF, W3C, TC 39, as well as WHATWG. All rely on the broader stakeholder community to draft spec text, write tests, express support or opposition to implementing and using a spec in actual browsers, frameworks, websites, and so on. But all have filters to keep people from "writing fiction", that is, supposed standards that aren't actually usable by web developers. Also remember that the "vendors" such as the companies on the SG are fierce business competitors at the corporate level even though they collaborate on joint interests in the standards organizations. Standards that serve multiple vendors PROBABLY serve their customers as well. In my experience (at a big "browser vendor" from 2005 - 2020) it is customer feedback on implementations that drives investment (or lack of it) in working on standards and getting them interoperably implemented. When the joint customers of Google, Microsoft, Apple, Mozilla, etc. push for them to address a real problem or implement a particular solution, the vendors listen. That said, the web standards orgs are all discussing how to do a better job of living by the "priority of constituencies" design principle https://www.w3.org/TR/html-design-principles/#priority-of-constituencies (this is published by W3C but came out of WHATWG and authorship is attributed to @othermaciej and @annevk) . WHATWG references this in https://github.com/whatwg/meta/blob/main/CONTRIBUTING.md as a general guideline for contributing to WHATWG standards, but arguably this should be referenced more explicitly from one of the Policies to make it clearer that WHATWG prioritizes the concerns of users over those of implementers. I'm sure the WHATWG community would respectfully consider a specific proposal to do something along these lines. Furthermore, it's not really clear what it would mean in practice to prioritize the needs of users above other stakeholders in standards work. See https://github.com/WebStandardsFuture/Users1st for some links to resources and a possible place to discuss it across standards communities. |
|
I am done pussyfooting around. Riddle me this: How can WhatWG even maintain the pretense of not being a corporate cabal who's only reason for existing was to take power from the W3C? Should companies as browser vendors all using the same engine Google develops be given defacto majority rights in every decision regarding the web? Because aside from Mozilla and to VERY MINOR extent Apple everything else is pretty much a Chrome flavor resulting in a near-single engine mono-culture. |
I was directed to move my generally overview comment regarding standards here.
Shouldn't the standards dictate what html, css, javascript, etc is supposed to be and clients respond with support or not at their discretion with all the consequences of that decision?
What I mean is a standard should be able to justify its own existance as what should be agreed on as a standard regardless of special intrests of one class of rendering engine or vendor.
How else can you foster natural growth of those standards without interference?
This is even more important now than in the previous decade because with exception of gecko and the smaller engines (goanna, apple webkit, pure khtml, and others) it is just going to be all flavors of chromium from the top vendors.
One rendering engine regardless of multiple vendor clients should not be given absolute or defacto veto power over standards like
<style scoped>.The standards should be standards regardless and natural market forces can drive the implementation and conformity of those standards in vendor clients regardless of rendering engine (or flavor there of).
The text was updated successfully, but these errors were encountered: