11 ms·

Web Standards

358 points by maccman 15y ago

mceachen 15y ago
Dustin, I totally agree with you that the current system is whack. Glacial adoption of W3C standards has a real cost on developers and users, and ends up with rounded corners taking 16 lines of CSS, and gradient fills taking 8. I don't think that we'll be better off just by making the current process "go faster," though. There needs to be some proper vetting of features. You'd want to avoid the tyranny of the monied interests. It can't just be Apple/Microsoft/Google making the decisions about what goes in and what doesn't -- even though they're going to shoulder the cost on the user-agent side to implement the feature. It might just be as simple as leaving the current ecosystem as it is, looking at the adoption rate and success of a given construct, and folding those into the "living" spec (without the prefix, of course) -- and just do this process on a regular, fairly frequent interval, like every 6 months.
- deleted 15y ago
  [deleted]
- kaiuhl 15y ago
  I disagree about the proper vetting of features being a necessity. As long as open-source rendering engines like Webkit or Gecko are pushing forward and providing ideas and implementations of those ideas, we can let web developers vote with their websites. Everyone understands that advanced features of CSS can't be relied upon—this is now part of the collective front-end developer consciousness. Get rid of the W3C and let Mozilla and the Webkit project define the web moving forward; they've done a great job so far.
  - gioele 15y ago
    > Get rid of the W3C and let Mozilla and the Webkit project define the web moving forward; they've done a great job so far. The standardization of required codecs for the `<video>` element is indeed a wonderful accomplishment by the non-W3C HTML5 WHATWG. Seriously, a third-party neutral organization will always be needed. Who will you appeal to when the main companies start having different ideas about something? Another thing that organizations like W3C or IETF do is to provide some kind of shelter from patents and similar problems. We can discuss about the efficacy of such shelters and about the ability to mediate between different options, but the web is definitely under a better situation than wireless telephony, a field where company-run consortiums decide standards and "settle" disputes.
    - wmf 15y ago
      Who will you appeal to when the main companies start having different ideas about something? No one. If the browsers refuse to agree on something (codecs being a good example), there's nothing that anyone can do about it. Just say "no standard is possible in this area" and move on. OTOH, if two or more major browsers agree on the syntax and semantics of a feature, let's issue it as a standard (and de-prefix it) ASAP.
    - mappu 15y ago
      Speaking of `<video>`, i came across a site today that used <embed src="foo.wav">. As long as video and audio formats are loosely specified, we could've used the existing syntax and existing browser infrastructure (you still can't disable HTML5 audio/video in Chrome[1] for e.g. data cap reasons) __________________ 1. http://crbug.com/50132 http://crbug.com/50132
      - lmm 15y ago
        The irony is that <embed> was never a standard (unlike <object>); if you believe the W3C fans then you must be evil to use it. But it works, and has always worked, better than any of the alternatives. I hear with html5 they've given up and declared it part of the standard.
        Hixie 15y ago
        The "they" that "gave up" is a different group of people than the "they" who thought it was evil, by the way. The current group working on the contemporary HTML living standard just describes reality, by and large, so there was never really any doubt that "embed" would be part of the standard when we started back in 2004.
- jeremymcanally 15y ago
  I think you've hit it with watching the adoption rate. It's not as if Microsoft or Apple or Google can force these features on to people. Web developers have to actually use them. I fail to see how "monied interests" can affect much unless developers who are very much not part of these interests actually use these features. I think the way things are going (i.e., engines add features, developers use them or don't, the ones that get used get approved by de facto adoption, etc.) is perfect and fits the best with the pace at which things are moving in this industry. I don't think, as many do, that it will lead to the proliferation of a bunch of confusing, bloated features being shoved into the spec (as loose as that word can be applied here). We haven't seen much of that yet, and I really don't think we will.
- dedward 15y ago
  If you don't mind - I'm missing something here I think - does the W3C have any legal power whatsoever to force vendors who want to ignore them and develop proprietary closed features to fall into line? I don't believe they do, other than just some bad PR.....
huggyface 15y ago
The aggressive dismissal of the concerns are unwarranted and a bit ignorant. The concern is not, per se, vendor extensions -- such a mechanism exists for a reason -- but rather that many users of those extensions have lazily taken to only bothering with webkit extensions. Most of the time for no reason other than an IE-only like "suck it" attitude (many demos front-paged here on HN only work in single browser, despite often needing just trivial changes to work elsewhere). Dismiss the W3C and the purpose for standards at your peril. Webkit and its offshoots have the ability to innovate on the edge because that body and its impact kept the web open. EDIT: It's worth noting, with sober consideration, that exactly the same argument was made to support Internet Explorer during the ugliest days of the web. This could have been cribbed verbatim from something a Microsoft advocate would have said in the late 90s.
- georgemcbay 15y ago
  "Webkit and its offshoots have the ability to innovate on the edge because that body and its impact kept the web open." I don't agree. I'd say the web saving itself from IE's grip had a lot more to do with Microsoft sitting on its ass and doing virtually nothing to push things forward once they got 90% share. If Firefox didn't have its impressive extension mechanism or webkit in the form of Chrome wasn't so damned fast or the whole mobile browser didn't become a thing, people would still largely be using IE, and none of those circumstances has a single thing to do with the W3C, really. IMO, the fact that this is even being discussed but now in the context of Webkit instead of IE shows that the W3C isn't really that relevant when it comes to pushing the web along.
- kaiuhl 15y ago
  You miss the fact that Gecko and Webkit are open source projects. There will never be the case where something like ActiveX can exist with these projects.
  - recoiledsnake 15y ago
    Okay, so you now you have edited the source code and compiled a binary, is your recommendation that the binary be downloadable and installable by the user from the website? Open source is one thing, but if you're not able to convince Google and Apple to ship your changes, you've hit a wall. FF implementing support for the WebKit extensions is what will break the web back into the IE-dominant era.
georgemcbay 15y ago
"Despite having representatives from all of the major browser developers, the Working Group has not been able come up with a solution." IMO there's no "despite" about that, "Due to" would be more appropriate. Design by committee sucks even under the best of circumstances. When the committee is made up of very different companies each trying to use the web as a chip to bolster different parts of their businesses, of course the process is going to be broken. It probably can't not be broken.
- nerfhammer 15y ago
  I don't see how deciding the syntax for a gradient fill might affect one business concern vs another
  - georgemcbay 15y ago
    Actually there are very real ways in which this sort of thing can impact one vs another. eg. Adobe may push for a format that natively supports the double sided color filling rules they use in Flash to make it easier for them to produce Flash->HTML5 conversion frameworks without a lot of code rewriting while other parties may not have this as a concern. That aside, you picked a ridiculously low-hanging fruit of a concern. Consider something larger, like JavaScript and the fate of ECMAScript 4 due to the very situation I'm talking about. But even the minor bikeshedding concerns can be used as political levers one way or another regardless of how (in)significant one implementation is compared to another.
    - nerfhammer 15y ago
      There ought to be at least some things that literally none of the participants in w3c etc have any conflict of interest about and therefore would be able to decide quickly on. The debate over the <video> tag for example may never be decided on. But I have trouble thinking of any counter-examples.
3pt14159 15y ago
Aside: Please don't have a flashing beacon thing where I'm trying to read. I get visually distracted very, very easily.
- mortenjorck 15y ago
  I'm going to have to agree that's a usability gaffe. Peripheral animation that isn't in service of a notification or something else that actually requires the user's attention is, quite literally, only a distraction.
  - aidos 15y ago
    It's worse than that actually - hold your mouse over it and you give the author "Kudos." I find that particularly offensive /rant
sriramk 15y ago
Somewhere in building 50 on Redmond campus, the IE team is wondering why nobody ever said this in their defence when the exact same scenario was playing out with IE (dominant browser, not available on all platforms, glacial standards bodies, browser specific extensions, etc).
- cgranade 15y ago
  This is a very different situation in quite a few ways. For one, IE was not just a big browser, but was almost completely dominant. For another, many of IE's browser-specific features were Windows-only by design, such as ActiveX. Here, we have an open source rendering engine that clearly delineates browser-specific features (each of which is well-documented). The use of a prefix makes it possible to use the browser-specific features offered by WebKit without sacrificing compatibility with other browsers, something Microsoft actively resisted. For quite a while, it was very difficult, if not impossible, to make sites that looked and felt right both in IE and in other browsers. Had Microsoft extended standards in a way that played nice with the rest of the community, maybe they would have had someone saying something like this in their defence. Instead, they used browser-specific features as a way of undermining standards.
  - ootachi 15y ago
    NaCl is specific to individual processor architectures by design, much like ActiveX was specific to Windows. Prefixed WebKit features are certainly not consistently well-documented. CSS animations, transforms, etc. had to be carefully reverse engineered by other browsers.
    - calloc 15y ago
      NaCl is not part of WebKit.
    - jacobolus 15y ago
      CSS animations and transforms were released along with formal specs. The Webkit developers read mailing lists, hang out on IRC, etc. If anyone thought these were underspecified or ambiguous, they could easily ask for answers or adjustments to the spec. It’s not like the Webkit folks were trying to hide anything.
potch 15y ago
My complaint is not that -webkit CSS extensions are bad. I love how fast the browsers move. It's that people aren't careful to make sure they use all the prefixes when they're available. It's an education problem, but people using CSS preprocessors such as LESS and SASS have no real excuse.
- tjogin 15y ago
  That wouldn't be a problem if the non-vendored variants of the CSS attributes didn't take so god damn long to become proper standards. The problem is not the webkit vendor attributes, the problem is that proper standards aren't able to keep up. HTML5 is still not a proper W3C standard (or "recommendation"), it's still just a working draft, and was last updated in May of 2011. It's been six years. So far.
  - potch 15y ago
    100% agreed. The process has to move faster.
  - voyou 15y ago
    I don't really understand this objection. Sure, HTML 5 isn't officially a standard, but neither is -webkit-whatever; in both cases, you can use whichever non-standard you like, subject to browser support. The advantage of the W3C draft is that it is a non-standard that the browser makers are all working towards.
    - tjogin 15y ago
      The objection is that the standardization process is too slow. Not a little bit too slow, but so glacially slow it's almost indistinguishable from abandonment. So, progress of key web technologies needs to be put into vendors's hands. CSS border-radius is still not a W3C recommendation. It's been a draft for nine and a half years. So far. It was last updated one year ago. With a standardization process that broken, vendors need to take things into their own hands, and them doing so, especially webkit doing so, has been an astounding success, IMHO.
ronreiter 15y ago
Relax. Just relax. The web browsers are automatically updating themselves for a reason.
MeanderingCode 15y ago
Way to go, dcurtis, ranting about web standards and webkit's greatness while your website doesn't render sanely on my android devices' webkit browsers.
- bithive123 15y ago
  That's unfair, it says right at the top of the page that he's a superhero not a web developer.
jseims 15y ago
Does anyone have any insight as to why the W3C has taken over 10 years to converge on the spec for rounded corners? Any info more than just "bureaucracy"?
- th0ma5 15y ago
  you really do have to properly vet these things. i didn't realize the work involved either until i started following the rdfa spec. beyond the bureaucracy (which is actually pretty good, like a software development process) there are unintended use cases and side effects, and the concept needs to be as complete as possible and not self-contradictory. there must also be prior art to be researched and understood and incorporated wherever possible as to not throw out good ideas with an off-the-cuff implementation. second, it is actually done sort of slowly, and with your input if you want, and you can start to use a lot of the core features of drafts, just like a beta program.
- mbrubeck 15y ago
  While I the W3C CSS WG does take a long time to produce standards, I should point out that "border-radius" is in fact finalized already, and is supported without a vendor prefix in Firefox 4+, Chrome 4+, IE 9+, Opera 10.5+, and Safari 5+.
edd_dumbill 15y ago
This is a somewhat ungrateful perspective, just after the Eolas patent case was thrown out. Yes, the W3C process takes about half the lifespan of many HN readers. Yup, it's not ideal. But it's the only game in town and it's been going on so long because it works. Because it successfully brought Microsoft into the fold and conversation at a time where, had they decided, they could have broken everything. It's worth exercising a little perspective. Can you think of any endeavor that has so successfully united vendors to create something as broad and interoperable as the web, over such a relatively small period of history? The W3C has been fundamental to this. - What has the W3C ever done for us? -- Well, HTML. - Oh yeah, they gave us that. Yeah. That's true. -- And CSS you could view source and copy. --- Yeah, you remember how scared we all were of Microsoft Blackbird? - All right, I'll grant you that HTML and CSS are two things the W3C have done... (you get the idea.)
- gkoberger 15y ago
  W3C isn't the only game in town. There's the WHATWG because of W3C's shortcomings.
- tomjen3 15y ago
  Why are they the only game in town? And html is arguably a bad document language. Look at all the different conflicting ways in which it is rendered. And don't even get me started on css....
- lmm 15y ago
  Seriously, what has the pre-WhatWG W3C done for us that wasn't in "HTML 3.2"? I can't think of anything better in html4 than before, and plenty of things that're worse. As for CSS, it's evolved so slowly and refused to implement such basic features that people now use preprocessors to generate it, defeating the point entirely. (Not to mention that the most W3C-ey version was 2.1, which has still never been implemented). So what has the W3C actually done for us? XHTML?
sp332 15y ago
the developers of WebKit added the prefix -webkit to the experimental stylesheet declarations. This ensured they worked only in WebKit. No. This ensured that they didn't pollute the global namespace with experimental, partially-implemented ideas. If Mozilla, Opera, and Webkit each make e.g. "rounded-rect" declaration, and one browser takes the width as the first argument while another takes the radius first, then we're screwed. At least having "-moz-rounded-rect" and "-o-rouded-rect" means developers know how their pages will behave in each browser. I agree that the W3C is unacceptably slow, but that doesn't mean prefixes are a terrible idea.
- lwhi 15y ago
  Exactly. The vendor prefixes are a compromise. The majority of the time the prefixes are used to implement features which have been proposed (but haven't been ratified) now.
  - rhizome 15y ago
    I think if features are standardized, the economy in typing alone will force the vendor-specifics away. Just a phase that (CSS) standards might go through.
- deleted 15y ago
  [deleted]
- kule 15y ago
  What I still don't understand is why the global namespace isn't used straight away. You could, for example, just use one line of css for border-radius for all browsers. If one vendor does it differently you use their vendor specific namespace to override it. Surely that makes more sense than having to do a line of css for every vendor?
  - kbanman 15y ago
    I support this methodology. Have the globally-namespaced attribute already function, but give the vendor-specific one precedence. That way the developer only has to add vendor-specific declarations for the minority that implements it differently.
mattbeck 15y ago
This seems to be a fairly standard gripe from the W3C. "Listen to us, because if you don't the sky will fall!" They are making themselves increasingly irrelevant because they exist primarily to restrict and limit rather than to expand and innovate. Partly that's the nature of the beast, standards are after all rules. The problem is that the rules need a clear and timely mechanism to evolve. Clearly the W3C is the wrong answer to that problem. I remember well what things were like in the days of horrible tag soup trying to support internet explorer and netscape, and that sucked too. Standards are good, having a single rule set for everyone to test against is good. The W3C though, yeah they suck hard. Way past time to move to a usage-based standards adoption mechanism. Let people innovate, if that change sees wide support adopt it as a standard.
tptacek 15y ago
This is the result of a standards process running in reverse: first the specifications, then the implementation. There was a time when the "Internet" could if you squinted right be defined as "the collection of people who make fun of that process and do the opposite"; their motto was (literally) "loose consensus and working code". First you get things working. Then you standardize on them. Complain when the Webkit team refuses to implement standards. Have they shown any unwillingness to support W3C standards once published? No? Then what's the gripe? The browser vendors are doing exactly what they're supposed to do: come up with new things. If the W3C was doing its job, it would watch those new things carefully and, when enough momentum existed, start ratifying them as standards. It's not enough to say, "you could have used the same argument to defend Internet Explorer". To indict someone for "embrace & extend", you need both halves of the behavior: creation of new features, and unwillingness to support subsequent standards for those features.
- ootachi 15y ago
  "Have they shown any unwillingness to support W3C standards once published? No?" Unfortunately for your argument, the answer is indeed no. Apple is unwilling to support standards for touch events, due to its patent war against Android. Sources: [1] http://9to5mac.com/2011/12/19/apple-submits-invalid-patents-to-w3c-to-delay-touch-events-standard/ http://9to5mac.com/2011/12/19/apple-submits-invalid-patents-... [2] http://www.webmonkey.com/2011/12/is-apple-using-patents-to-hurt-open-standards/ http://www.webmonkey.com/2011/12/is-apple-using-patents-to-h...
  - tptacek 15y ago
    Did the W3C standardize touch events, and Apple prevent Webkit developers from implementing the standard?
    - ootachi 15y ago
      They showed an "unwillingness to support subsequent standards for those features", by blocking the creation of a standard in the first place. Stop being obtuse.
lwhi 15y ago
To me, the article comes across as a bit of an uninformed rant. > I hope it does kill the W3C and CSS Working Group standardization process. To this, I have to ask "Mr Curtis - are you _CRAZY_?"(!) Do you not realise that it's taken over 12 years to say good bye to IE6. Have you not had the pleasure of battling with the ramifications of a browser that doesn't play by the rules? -- There are some understandable reasons for not making use of vendor prefixes. The article that Dustin Curtis links to makes some valid points about the dangers of continuing to use vendor prefixes. A similar line of thinking is presented here [1] The alternative to using vendor tags isn't to stop using the features - it's to simply drop the vendor prefixes and use the property names from the (non-ratified) CSS specifications before they're fully approved. For all it's failings, the W3C does a grand job. Negotiations take time. Best we don't throw our toys out of the pram. -- [1] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p....
- tptacek 15y ago
  I think you're misinformed by what "the rules" are. W3C standards are not, in fact, an innovation speed limit. Vendors are free to implement whatever they'd like. The only way a vendor should be encumbered by the W3C is that if they choose to implement a feature, they should also support the W3C incarnation of that feature. That's it, full stop. The problem with IE6 isn't that it did extra things. It's that it did a variety of things (some extra, some not) badly, and then Microsoft refused to bring it into compliance. That's not a problem we have with Webkit. So what are you saying when you try to tar Webkit with the IE brush? How familiar are you with the development process behind Webkit?
  - lwhi 15y ago
    If you read the article referenced, you'd realise that web-kit isn't being picked on. The concept of using vendor-prefixes is being questioned. I'm not tarring webkit with an IE brush. I'm stating that without the W3C or similar body to set standards, we would in a far worse situation. The article spectacularly misses the point.
pygorex 15y ago
Browser developers are going to innovate new features. A standards body doesn't drive innovation. Innovation is not a top-down process. A standards body exists to ensure some level of interoperability between browsers. What Prefixgate shows is that a W3C standard is not a rigid set of laws like the 10 commandments. Rather a W3C standard is like a peace treaty - all adherents agree to respect certain protocols and behave in certain ways, buy are free to pass whatever laws they want within their own boundaries. Assuming that these proprietary laws do not conflict with existing treaty stipulations. Peace treaties give us access to the best of both worlds: vendors are free to innovate as they see fit, yet they still commit themselves to some level of interoperability. Innovations influence the standard and the standard ensures that all vendors adopt the best innovations at some point. The comparisons between IE of old and Webkit are incorrect. Microsoft has a history of implementing standards incorrectly (http://www.quirksmode.org/css/quirksmode.html http://www.quirksmode.org/css/quirksmode.html) and bullying standards bodies (http://techrights.org/2011/09/06/michel-levy-comes-out-swinging/ http://techrights.org/2011/09/06/michel-levy-comes-out-swing...). When it comes to standards Microsoft does not act in good faith.
- pbhjpbhj 15y ago
  >Innovation is not a top-down process. I don't see why it can't be. For example, going back 10 years the W3C could have said we're standardising a series of layout definition attributes (or multiple backgrounds, or colour fades, or bordering styles, or animation modes or whatever) and then waited for those to be implemented by the browsers. I don't see why the standards bodies can't anticipate a need that hasn't yet been coded for and implement a preliminary standard definition for browser writers to use. It probably wouldn't work in practice because it appears to rely on the standards body moving faster than the browser makers which is a laughable suggestion as things stand now. As I, probably shortsightedly, see things now it's the javascript (jquery, mootools, etc.) writers who're best placed to speak to the next iteration of web standards as they are actively filling the holes that are missing in the current iteration of HTML+CSS (and associate tech).
  - batista 15y ago
    don't see why it can't be. For example, going back 10 years the W3C could have said we're standardising a series of layout definition attributes (or multiple backgrounds, or colour fades, or bordering styles, or animation modes or whatever) and then waited for those to be implemented by the browsers. I don't see why the standards bodies can't anticipate a need that hasn't yet been coded for and implement a preliminary standard definition for browser writers to use. Well, people who have worked with standards bodies know why it can't be. Because of the natures of the processes involved there and the interests that have to be balanced. The fact that something is at all possible (= no laws in the universe prevent it from being so) don't mean it has a high enough probability. Yeah, a committee could work faster and flexibly. Experience has shown us that historically, they never do.
JoshTriplett 15y ago
I find it funny that that rant holds up as an example the magic bit of CSS animation on the right which treats a brief hover over it as a "kudo".
bradgessler 15y ago
W3C is a web standard, on paper. http://www.webkit.org/coding/lgpl-license.html http://www.webkit.org/coding/lgpl-license.html WebKit is living, breathing, open standard that anybody can fork and contribute to. Code talks, paper walks.
- fpgeek 15y ago
  Code is crucially important. That is why good standards bodies require implementations. Nevertheless, that doesn't make an implementation a standard (unless you are satisfied by under-specified, poorly documented, fragile, de facto "standards"). That you don't seem to care about (or possibly don't understand) the distinction suggests you are part of the problem. NevWebKit is an implementation, not a standard. That you
Finster 15y ago
Ohhhh, so it's okay when webkit does it... just not IE.
lifthrasiir 15y ago
It is correct that W3C certainly lacks the ability to coordinate different vendors. But is it good to abandon the coordination process altogether? No, the problem here is a standardization process and not a coordination process. You at least have to coordinate vendors to maintain the very baseline, no matter Web standard is means or not. (If you don't agree on this, you'd be better looking at the past...) Someone should really bring up the better alternative than Web standard, and not only criticize it.
ChuckMcM 15y ago
Welcome to the 'standards' world. It sucks big time. I've participated in standards in both POSIX working groups (network file systems, network apis), IEEE working groups (PCI express Advanced Switching), IETF working groups (RPC and XDR, heck I'm the 'owner' of port 111!), various CAD standards groups, and a whole bunch of things that never even rose to a level of relevance to get published. If standards bodies are effective, they take away power from companies to distort the playing field, if they are ineffective they allow folks to distort independently. So large companies send representatives to standards bodies to distort them in favor of their own company (Rambus is the canonical example) and other companies send representatives to make them ineffective so that they won't level the current field (Microsoft and XML is the canonical exemplar there). The bottom line is that Standards bodies whine that nobody lets them do their job, and they tolerate members who actively prevent them from making progress. I have long since given up feeling any sympathy for them whatsoever.
- masklinn 15y ago
  > Welcome to the 'standards' world. It sucks big time. Because a hegemony is so much better right? What fun that was last time around.
zobzu 15y ago
the guy proposes to kill standardization bodies, and that web engines should do w/e the hell they like, regardless of standards. coming from what appears to be a webkit dev, that's pretty bad. standardization bodies should certainly be deeply fixed - but this kind of reply is wrong.
gavanwoolery 15y ago
I am going to go out on a limb and say: fuck standards. Make a powerful, but extremely simple (as in: small instruction set) virtual machine and protocol. That way anyone can make their own standards.
- jarek 15y ago
  Sir, do you understand the World Wide Web?
  - gavanwoolery 15y ago
    Apparently not - what am I misunderstanding?
    - jarek 15y ago
      More-or-less assured interoperability and complexity of content creation stand out as two of the larger issues. Episodes of the web's history when organizations did create their own standards might be another one.
eslaught 15y ago
Why doesn't the standards body ask webkit to deprecate and begin to phase out any -webkit-* CSS selectors which have been fully standardized? That seems like an effective way to force people to use the standards once they actually exist. Complaining about people using -webkit-* before the standards exist is obviously unreasonable, considering the implications of populating the global namespace with conflicting versions of the same feature.
- deleted 15y ago
  [deleted]
  - ootachi 15y ago
    Bringing up racism, sexism, and homophobia in a discussion of Web standards is a little bit extreme, don't you think?
- bzbarsky 15y ago
  The standards body has asked WebKit to do that, in fact. Apple flat-our refused to ever remove -webkit prefixes that they have once shipped. Note that no one is complaining about the mere existence of the prefixes; the problem is: 1) The way they're being used by web developers. 2) The fact that some of these properties are not standards-track, with Apple actively refusing to allow them to be standardized.
jmsduran 15y ago
Kudos to the author of the article. I read the referenced article on glazman.org, and once "glazou" described -webkit-* as having "hardware market dominance", I could not stop LOL'ing until I finished reading his blog post. Seriously?! I second that the web is constantly evolving, whether or not it benefits the ego-fat cats at Google, Apple, or Mozilla. Get used to it and adapt, at least that's what I remember hearing in a Google Tech Talk back in 2008, does anyone still tune in to those?
readme 15y ago
Great points. I'm going to automatically concur on the grounds that I don't think bureaucracies that produce nothing should have a say in the production of anything.
jerfelix 15y ago
I'm glad that the webkit-specific features were prefixed. I just wish they would have chosen a prefix that was a wake-up call to anyone relying on them. Perhaps a prefix like "this-feature-will-be-deprecated-in-2013-". Slightly off-topic, but in a similar manner, when we struggled with users permanently deleting records, ignoring the warning that they were permanently deleting records, and calling us to retrieve the irretrievable, we changed the confirmation box from "click OK" to "type the word 'irreversible". This cut the calls to near zero.
meow 15y ago
I think the reason for this kind of slow evolution is lack of generic properties (like --surprise-- internet explorer's filters ) which lets developers push the boundaries on their own with in a reasonable limit. For example, support for border-radius, linear gradient, box shadow, text shadow etc all deal with rendering of elements at various levels. If there is a generic property which lets us control rendering and positioning of elements to a limited extent, the current evolution and standardization processes will be much less of a problem (I'm not saying internet explorer's filters are the way to go. But you have to give them credit for putting such a generic property in developer's hands).
BillPosters 15y ago
Front end Developers seem to disagree a lot. Some embrace the webkit prefix and sprinkle it all through their CSS. Others prefer not to resort to old fashioned site building techniques and instead aim to get the functionality working everywhere in one hit without coding like it's 1996.
dedward 15y ago
Let's broaden the picture a bit here and look at the internet as a whole. There are no standards - there are suggestions (RFCs), lots of open stuff (open source, free, whatever), and some closed stuff, and then there's what really happens. It turns out that IPv4 and DNS worked pretty well, though of course the internet at-large only uses a portion of those "standards". We didn't need an organization to tell us every last little detail and how it would work and "approve" it before we use it. People found out what worked, documented it, and it became the de-facto standard. We've never waited on the various internet "governing" bodies while keeping our own progress at bay. THere's absolutely no reason to. Know why everyone (more or less) obeys the allocations issued by ARIN? Because we recognize someone has to manage that limited resource pool, and they do an okay job of it. We're all free, more or less, to set up networks in whatever way we want, with whatever IP space we want - we just can't expect cooperation from our neighbours without some discussion and agreement so we don't stomp on each other's space - so we look to ARIN and their brethren to manage this. If they ceased to do so efficiently, they'd be replaced. The W3C has no power to force a developer or vendor to implement a given feature or not, and nobody really cares whether or not something is "officially" compliant. Most web pages are not fully compliant... yet the web, built by kids and adults and everything in between grew up and here we are, talking on HN. It'd be great if people could agree when we end up with overlapping features from different vendors...... it makes it hard for the developers right? That should be obvious to all. But we've switched browsers over the years, and will again, and whichever ones actually do what people need them to do, as well as keep developers happy, will prosper - w3c has little to do with it as far as I can see. Same for DNS (gripes aside - let's be realistic). We implemented IPv4 and it works great, but does the internet at large obey the type of service bits which are part of that standard? heck no. It's a big, evolving, organic thing. The web - same deal. Know what makes a standard? Something people adopt and continue using. Usage defines the standards - nobody is compelled to do anything just because it's a "standard" according to some group.
dreamdu5t 15y ago
... dcurt.is is an abuse of the TLD standards...
pippy 15y ago
>The reason the -webkit prefix was necessary is simple: the W3C and the CSS Working Group are ineffective, failed organizations. This is a bit too far. The -webkit prefix was a gesture of courtesy. What if other browsers implement it differently, and the spec changes? then older webkit browsers will render it incorrectly. The solution is simple: code to the standards, then target the fringe browsers. It doesn't matter if it's webkit or IE, this is a future proof, cross compatible solution that will solve both problems.
starfox 15y ago
I fully agree with this. CSS set the web back years with it's inability to handle simple layout. The W3C organization is run by representatives of major corporations, and the standards take years to roll out.

358 points by maccman 15y ago

Dustin, I totally agree with you that the current system is whack. Glacial adoption of W3C standards has a real cost on developers and users, and ends up with rounded corners taking 16 lines of CSS, and gradient fills taking 8. I don't think that we'll be better off just by making the current process "go faster," though. There needs to be some proper vetting of features. You'd want to avoid the tyranny of the monied interests. It can't just be Apple/Microsoft/Google making the decisions about what goes in and what doesn't -- even though they're going to shoulder the cost on the user-agent side to implement the feature. It might just be as simple as leaving the current ecosystem as it is, looking at the adoption rate and success of a given construct, and folding those into the "living" spec (without the prefix, of course) -- and just do this process on a regular, fairly frequent interval, like every 6 months.

deleted 15y ago
[deleted]
kaiuhl 15y ago
I disagree about the proper vetting of features being a necessity. As long as open-source rendering engines like Webkit or Gecko are pushing forward and providing ideas and implementations of those ideas, we can let web developers vote with their websites. Everyone understands that advanced features of CSS can't be relied upon—this is now part of the collective front-end developer consciousness. Get rid of the W3C and let Mozilla and the Webkit project define the web moving forward; they've done a great job so far.
- gioele 15y ago
  > Get rid of the W3C and let Mozilla and the Webkit project define the web moving forward; they've done a great job so far. The standardization of required codecs for the `<video>` element is indeed a wonderful accomplishment by the non-W3C HTML5 WHATWG. Seriously, a third-party neutral organization will always be needed. Who will you appeal to when the main companies start having different ideas about something? Another thing that organizations like W3C or IETF do is to provide some kind of shelter from patents and similar problems. We can discuss about the efficacy of such shelters and about the ability to mediate between different options, but the web is definitely under a better situation than wireless telephony, a field where company-run consortiums decide standards and "settle" disputes.
  - wmf 15y ago
    Who will you appeal to when the main companies start having different ideas about something? No one. If the browsers refuse to agree on something (codecs being a good example), there's nothing that anyone can do about it. Just say "no standard is possible in this area" and move on. OTOH, if two or more major browsers agree on the syntax and semantics of a feature, let's issue it as a standard (and de-prefix it) ASAP.
  - mappu 15y ago
    Speaking of `<video>`, i came across a site today that used <embed src="foo.wav">. As long as video and audio formats are loosely specified, we could've used the existing syntax and existing browser infrastructure (you still can't disable HTML5 audio/video in Chrome[1] for e.g. data cap reasons) __________________ 1. http://crbug.com/50132 http://crbug.com/50132
    - lmm 15y ago
      The irony is that <embed> was never a standard (unlike <object>); if you believe the W3C fans then you must be evil to use it. But it works, and has always worked, better than any of the alternatives. I hear with html5 they've given up and declared it part of the standard.
      - Hixie 15y ago
        The "they" that "gave up" is a different group of people than the "they" who thought it was evil, by the way. The current group working on the contemporary HTML living standard just describes reality, by and large, so there was never really any doubt that "embed" would be part of the standard when we started back in 2004.
jeremymcanally 15y ago
I think you've hit it with watching the adoption rate. It's not as if Microsoft or Apple or Google can force these features on to people. Web developers have to actually use them. I fail to see how "monied interests" can affect much unless developers who are very much not part of these interests actually use these features. I think the way things are going (i.e., engines add features, developers use them or don't, the ones that get used get approved by de facto adoption, etc.) is perfect and fits the best with the pace at which things are moving in this industry. I don't think, as many do, that it will lead to the proliferation of a bunch of confusing, bloated features being shoved into the spec (as loose as that word can be applied here). We haven't seen much of that yet, and I really don't think we will.
dedward 15y ago
If you don't mind - I'm missing something here I think - does the W3C have any legal power whatsoever to force vendors who want to ignore them and develop proprietary closed features to fall into line? I don't believe they do, other than just some bad PR.....

huggyface 15y ago

The aggressive dismissal of the concerns are unwarranted and a bit ignorant. The concern is not, per se, vendor extensions -- such a mechanism exists for a reason -- but rather that many users of those extensions have lazily taken to only bothering with webkit extensions. Most of the time for no reason other than an IE-only like "suck it" attitude (many demos front-paged here on HN only work in single browser, despite often needing just trivial changes to work elsewhere). Dismiss the W3C and the purpose for standards at your peril. Webkit and its offshoots have the ability to innovate on the edge because that body and its impact kept the web open. EDIT: It's worth noting, with sober consideration, that exactly the same argument was made to support Internet Explorer during the ugliest days of the web. This could have been cribbed verbatim from something a Microsoft advocate would have said in the late 90s.

georgemcbay 15y ago
"Webkit and its offshoots have the ability to innovate on the edge because that body and its impact kept the web open." I don't agree. I'd say the web saving itself from IE's grip had a lot more to do with Microsoft sitting on its ass and doing virtually nothing to push things forward once they got 90% share. If Firefox didn't have its impressive extension mechanism or webkit in the form of Chrome wasn't so damned fast or the whole mobile browser didn't become a thing, people would still largely be using IE, and none of those circumstances has a single thing to do with the W3C, really. IMO, the fact that this is even being discussed but now in the context of Webkit instead of IE shows that the W3C isn't really that relevant when it comes to pushing the web along.
kaiuhl 15y ago
You miss the fact that Gecko and Webkit are open source projects. There will never be the case where something like ActiveX can exist with these projects.
- recoiledsnake 15y ago
  Okay, so you now you have edited the source code and compiled a binary, is your recommendation that the binary be downloadable and installable by the user from the website? Open source is one thing, but if you're not able to convince Google and Apple to ship your changes, you've hit a wall. FF implementing support for the WebKit extensions is what will break the web back into the IE-dominant era.

georgemcbay 15y ago

"Despite having representatives from all of the major browser developers, the Working Group has not been able come up with a solution." IMO there's no "despite" about that, "Due to" would be more appropriate. Design by committee sucks even under the best of circumstances. When the committee is made up of very different companies each trying to use the web as a chip to bolster different parts of their businesses, of course the process is going to be broken. It probably can't not be broken.

nerfhammer 15y ago
I don't see how deciding the syntax for a gradient fill might affect one business concern vs another
- georgemcbay 15y ago
  Actually there are very real ways in which this sort of thing can impact one vs another. eg. Adobe may push for a format that natively supports the double sided color filling rules they use in Flash to make it easier for them to produce Flash->HTML5 conversion frameworks without a lot of code rewriting while other parties may not have this as a concern. That aside, you picked a ridiculously low-hanging fruit of a concern. Consider something larger, like JavaScript and the fate of ECMAScript 4 due to the very situation I'm talking about. But even the minor bikeshedding concerns can be used as political levers one way or another regardless of how (in)significant one implementation is compared to another.
  - nerfhammer 15y ago
    There ought to be at least some things that literally none of the participants in w3c etc have any conflict of interest about and therefore would be able to decide quickly on. The debate over the <video> tag for example may never be decided on. But I have trouble thinking of any counter-examples.

3pt14159 15y ago

Aside: Please don't have a flashing beacon thing where I'm trying to read. I get visually distracted very, very easily.

mortenjorck 15y ago
I'm going to have to agree that's a usability gaffe. Peripheral animation that isn't in service of a notification or something else that actually requires the user's attention is, quite literally, only a distraction.
- aidos 15y ago
  It's worse than that actually - hold your mouse over it and you give the author "Kudos." I find that particularly offensive /rant

sriramk 15y ago

Somewhere in building 50 on Redmond campus, the IE team is wondering why nobody ever said this in their defence when the exact same scenario was playing out with IE (dominant browser, not available on all platforms, glacial standards bodies, browser specific extensions, etc).

cgranade 15y ago
This is a very different situation in quite a few ways. For one, IE was not just a big browser, but was almost completely dominant. For another, many of IE's browser-specific features were Windows-only by design, such as ActiveX. Here, we have an open source rendering engine that clearly delineates browser-specific features (each of which is well-documented). The use of a prefix makes it possible to use the browser-specific features offered by WebKit without sacrificing compatibility with other browsers, something Microsoft actively resisted. For quite a while, it was very difficult, if not impossible, to make sites that looked and felt right both in IE and in other browsers. Had Microsoft extended standards in a way that played nice with the rest of the community, maybe they would have had someone saying something like this in their defence. Instead, they used browser-specific features as a way of undermining standards.
- ootachi 15y ago
  NaCl is specific to individual processor architectures by design, much like ActiveX was specific to Windows. Prefixed WebKit features are certainly not consistently well-documented. CSS animations, transforms, etc. had to be carefully reverse engineered by other browsers.
  - calloc 15y ago
    NaCl is not part of WebKit.
  - jacobolus 15y ago
    CSS animations and transforms were released along with formal specs. The Webkit developers read mailing lists, hang out on IRC, etc. If anyone thought these were underspecified or ambiguous, they could easily ask for answers or adjustments to the spec. It’s not like the Webkit folks were trying to hide anything.

potch 15y ago

My complaint is not that -webkit CSS extensions are bad. I love how fast the browsers move. It's that people aren't careful to make sure they use all the prefixes when they're available. It's an education problem, but people using CSS preprocessors such as LESS and SASS have no real excuse.

tjogin 15y ago
That wouldn't be a problem if the non-vendored variants of the CSS attributes didn't take so god damn long to become proper standards. The problem is not the webkit vendor attributes, the problem is that proper standards aren't able to keep up. HTML5 is still not a proper W3C standard (or "recommendation"), it's still just a working draft, and was last updated in May of 2011. It's been six years. So far.
- potch 15y ago
  100% agreed. The process has to move faster.
- voyou 15y ago
  I don't really understand this objection. Sure, HTML 5 isn't officially a standard, but neither is -webkit-whatever; in both cases, you can use whichever non-standard you like, subject to browser support. The advantage of the W3C draft is that it is a non-standard that the browser makers are all working towards.
  - tjogin 15y ago
    The objection is that the standardization process is too slow. Not a little bit too slow, but so glacially slow it's almost indistinguishable from abandonment. So, progress of key web technologies needs to be put into vendors's hands. CSS border-radius is still not a W3C recommendation. It's been a draft for nine and a half years. So far. It was last updated one year ago. With a standardization process that broken, vendors need to take things into their own hands, and them doing so, especially webkit doing so, has been an astounding success, IMHO.

ronreiter 15y ago

Relax. Just relax. The web browsers are automatically updating themselves for a reason.

MeanderingCode 15y ago

Way to go, dcurtis, ranting about web standards and webkit's greatness while your website doesn't render sanely on my android devices' webkit browsers.

bithive123 15y ago
That's unfair, it says right at the top of the page that he's a superhero not a web developer.

jseims 15y ago

Does anyone have any insight as to why the W3C has taken over 10 years to converge on the spec for rounded corners? Any info more than just "bureaucracy"?

th0ma5 15y ago
you really do have to properly vet these things. i didn't realize the work involved either until i started following the rdfa spec. beyond the bureaucracy (which is actually pretty good, like a software development process) there are unintended use cases and side effects, and the concept needs to be as complete as possible and not self-contradictory. there must also be prior art to be researched and understood and incorporated wherever possible as to not throw out good ideas with an off-the-cuff implementation. second, it is actually done sort of slowly, and with your input if you want, and you can start to use a lot of the core features of drafts, just like a beta program.
mbrubeck 15y ago
While I the W3C CSS WG does take a long time to produce standards, I should point out that "border-radius" is in fact finalized already, and is supported without a vendor prefix in Firefox 4+, Chrome 4+, IE 9+, Opera 10.5+, and Safari 5+.

edd_dumbill 15y ago

This is a somewhat ungrateful perspective, just after the Eolas patent case was thrown out. Yes, the W3C process takes about half the lifespan of many HN readers. Yup, it's not ideal. But it's the only game in town and it's been going on so long because it works. Because it successfully brought Microsoft into the fold and conversation at a time where, had they decided, they could have broken everything. It's worth exercising a little perspective. Can you think of any endeavor that has so successfully united vendors to create something as broad and interoperable as the web, over such a relatively small period of history? The W3C has been fundamental to this. - What has the W3C ever done for us? -- Well, HTML. - Oh yeah, they gave us that. Yeah. That's true. -- And CSS you could view source and copy. --- Yeah, you remember how scared we all were of Microsoft Blackbird? - All right, I'll grant you that HTML and CSS are two things the W3C have done... (you get the idea.)

gkoberger 15y ago
W3C isn't the only game in town. There's the WHATWG because of W3C's shortcomings.
tomjen3 15y ago
Why are they the only game in town? And html is arguably a bad document language. Look at all the different conflicting ways in which it is rendered. And don't even get me started on css....
lmm 15y ago
Seriously, what has the pre-WhatWG W3C done for us that wasn't in "HTML 3.2"? I can't think of anything better in html4 than before, and plenty of things that're worse. As for CSS, it's evolved so slowly and refused to implement such basic features that people now use preprocessors to generate it, defeating the point entirely. (Not to mention that the most W3C-ey version was 2.1, which has still never been implemented). So what has the W3C actually done for us? XHTML?

sp332 15y ago

the developers of WebKit added the prefix -webkit to the experimental stylesheet declarations. This ensured they worked only in WebKit. No. This ensured that they didn't pollute the global namespace with experimental, partially-implemented ideas. If Mozilla, Opera, and Webkit each make e.g. "rounded-rect" declaration, and one browser takes the width as the first argument while another takes the radius first, then we're screwed. At least having "-moz-rounded-rect" and "-o-rouded-rect" means developers know how their pages will behave in each browser. I agree that the W3C is unacceptably slow, but that doesn't mean prefixes are a terrible idea.

lwhi 15y ago
Exactly. The vendor prefixes are a compromise. The majority of the time the prefixes are used to implement features which have been proposed (but haven't been ratified) now.
- rhizome 15y ago
  I think if features are standardized, the economy in typing alone will force the vendor-specifics away. Just a phase that (CSS) standards might go through.
deleted 15y ago
[deleted]
kule 15y ago
What I still don't understand is why the global namespace isn't used straight away. You could, for example, just use one line of css for border-radius for all browsers. If one vendor does it differently you use their vendor specific namespace to override it. Surely that makes more sense than having to do a line of css for every vendor?
- kbanman 15y ago
  I support this methodology. Have the globally-namespaced attribute already function, but give the vendor-specific one precedence. That way the developer only has to add vendor-specific declarations for the minority that implements it differently.

mattbeck 15y ago

This seems to be a fairly standard gripe from the W3C. "Listen to us, because if you don't the sky will fall!" They are making themselves increasingly irrelevant because they exist primarily to restrict and limit rather than to expand and innovate. Partly that's the nature of the beast, standards are after all rules. The problem is that the rules need a clear and timely mechanism to evolve. Clearly the W3C is the wrong answer to that problem. I remember well what things were like in the days of horrible tag soup trying to support internet explorer and netscape, and that sucked too. Standards are good, having a single rule set for everyone to test against is good. The W3C though, yeah they suck hard. Way past time to move to a usage-based standards adoption mechanism. Let people innovate, if that change sees wide support adopt it as a standard.

tptacek 15y ago

This is the result of a standards process running in reverse: first the specifications, then the implementation. There was a time when the "Internet" could if you squinted right be defined as "the collection of people who make fun of that process and do the opposite"; their motto was (literally) "loose consensus and working code". First you get things working. Then you standardize on them. Complain when the Webkit team refuses to implement standards. Have they shown any unwillingness to support W3C standards once published? No? Then what's the gripe? The browser vendors are doing exactly what they're supposed to do: come up with new things. If the W3C was doing its job, it would watch those new things carefully and, when enough momentum existed, start ratifying them as standards. It's not enough to say, "you could have used the same argument to defend Internet Explorer". To indict someone for "embrace & extend", you need both halves of the behavior: creation of new features, and unwillingness to support subsequent standards for those features.

ootachi 15y ago
"Have they shown any unwillingness to support W3C standards once published? No?" Unfortunately for your argument, the answer is indeed no. Apple is unwilling to support standards for touch events, due to its patent war against Android. Sources: [1] http://9to5mac.com/2011/12/19/apple-submits-invalid-patents-to-w3c-to-delay-touch-events-standard/ http://9to5mac.com/2011/12/19/apple-submits-invalid-patents-... [2] http://www.webmonkey.com/2011/12/is-apple-using-patents-to-hurt-open-standards/ http://www.webmonkey.com/2011/12/is-apple-using-patents-to-h...
- tptacek 15y ago
  Did the W3C standardize touch events, and Apple prevent Webkit developers from implementing the standard?
  - ootachi 15y ago
    They showed an "unwillingness to support subsequent standards for those features", by blocking the creation of a standard in the first place. Stop being obtuse.

lwhi 15y ago

To me, the article comes across as a bit of an uninformed rant. > I hope it does kill the W3C and CSS Working Group standardization process. To this, I have to ask "Mr Curtis - are you _CRAZY_?"(!) Do you not realise that it's taken over 12 years to say good bye to IE6. Have you not had the pleasure of battling with the ramifications of a browser that doesn't play by the rules? -- There are some understandable reasons for not making use of vendor prefixes. The article that Dustin Curtis links to makes some valid points about the dangers of continuing to use vendor prefixes. A similar line of thinking is presented here [1] The alternative to using vendor tags isn't to stop using the features - it's to simply drop the vendor prefixes and use the property names from the (non-ratified) CSS specifications before they're fully approved. For all it's failings, the W3C does a grand job. Negotiations take time. Best we don't throw our toys out of the pram. -- [1] http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p....

tptacek 15y ago
I think you're misinformed by what "the rules" are. W3C standards are not, in fact, an innovation speed limit. Vendors are free to implement whatever they'd like. The only way a vendor should be encumbered by the W3C is that if they choose to implement a feature, they should also support the W3C incarnation of that feature. That's it, full stop. The problem with IE6 isn't that it did extra things. It's that it did a variety of things (some extra, some not) badly, and then Microsoft refused to bring it into compliance. That's not a problem we have with Webkit. So what are you saying when you try to tar Webkit with the IE brush? How familiar are you with the development process behind Webkit?
- lwhi 15y ago
  If you read the article referenced, you'd realise that web-kit isn't being picked on. The concept of using vendor-prefixes is being questioned. I'm not tarring webkit with an IE brush. I'm stating that without the W3C or similar body to set standards, we would in a far worse situation. The article spectacularly misses the point.

pygorex 15y ago

Browser developers are going to innovate new features. A standards body doesn't drive innovation. Innovation is not a top-down process. A standards body exists to ensure some level of interoperability between browsers. What Prefixgate shows is that a W3C standard is not a rigid set of laws like the 10 commandments. Rather a W3C standard is like a peace treaty - all adherents agree to respect certain protocols and behave in certain ways, buy are free to pass whatever laws they want within their own boundaries. Assuming that these proprietary laws do not conflict with existing treaty stipulations. Peace treaties give us access to the best of both worlds: vendors are free to innovate as they see fit, yet they still commit themselves to some level of interoperability. Innovations influence the standard and the standard ensures that all vendors adopt the best innovations at some point. The comparisons between IE of old and Webkit are incorrect. Microsoft has a history of implementing standards incorrectly (http://www.quirksmode.org/css/quirksmode.html http://www.quirksmode.org/css/quirksmode.html) and bullying standards bodies (http://techrights.org/2011/09/06/michel-levy-comes-out-swinging/ http://techrights.org/2011/09/06/michel-levy-comes-out-swing...). When it comes to standards Microsoft does not act in good faith.

pbhjpbhj 15y ago
>Innovation is not a top-down process. I don't see why it can't be. For example, going back 10 years the W3C could have said we're standardising a series of layout definition attributes (or multiple backgrounds, or colour fades, or bordering styles, or animation modes or whatever) and then waited for those to be implemented by the browsers. I don't see why the standards bodies can't anticipate a need that hasn't yet been coded for and implement a preliminary standard definition for browser writers to use. It probably wouldn't work in practice because it appears to rely on the standards body moving faster than the browser makers which is a laughable suggestion as things stand now. As I, probably shortsightedly, see things now it's the javascript (jquery, mootools, etc.) writers who're best placed to speak to the next iteration of web standards as they are actively filling the holes that are missing in the current iteration of HTML+CSS (and associate tech).
- batista 15y ago
  don't see why it can't be. For example, going back 10 years the W3C could have said we're standardising a series of layout definition attributes (or multiple backgrounds, or colour fades, or bordering styles, or animation modes or whatever) and then waited for those to be implemented by the browsers. I don't see why the standards bodies can't anticipate a need that hasn't yet been coded for and implement a preliminary standard definition for browser writers to use. Well, people who have worked with standards bodies know why it can't be. Because of the natures of the processes involved there and the interests that have to be balanced. The fact that something is at all possible (= no laws in the universe prevent it from being so) don't mean it has a high enough probability. Yeah, a committee could work faster and flexibly. Experience has shown us that historically, they never do.

JoshTriplett 15y ago

I find it funny that that rant holds up as an example the magic bit of CSS animation on the right which treats a brief hover over it as a "kudo".

bradgessler 15y ago

W3C is a web standard, on paper. http://www.webkit.org/coding/lgpl-license.html http://www.webkit.org/coding/lgpl-license.html WebKit is living, breathing, open standard that anybody can fork and contribute to. Code talks, paper walks.

fpgeek 15y ago
Code is crucially important. That is why good standards bodies require implementations. Nevertheless, that doesn't make an implementation a standard (unless you are satisfied by under-specified, poorly documented, fragile, de facto "standards"). That you don't seem to care about (or possibly don't understand) the distinction suggests you are part of the problem. NevWebKit is an implementation, not a standard. That you

Finster 15y ago

Ohhhh, so it's okay when webkit does it... just not IE.

lifthrasiir 15y ago

It is correct that W3C certainly lacks the ability to coordinate different vendors. But is it good to abandon the coordination process altogether? No, the problem here is a standardization process and not a coordination process. You at least have to coordinate vendors to maintain the very baseline, no matter Web standard is means or not. (If you don't agree on this, you'd be better looking at the past...) Someone should really bring up the better alternative than Web standard, and not only criticize it.

ChuckMcM 15y ago

Welcome to the 'standards' world. It sucks big time. I've participated in standards in both POSIX working groups (network file systems, network apis), IEEE working groups (PCI express Advanced Switching), IETF working groups (RPC and XDR, heck I'm the 'owner' of port 111!), various CAD standards groups, and a whole bunch of things that never even rose to a level of relevance to get published. If standards bodies are effective, they take away power from companies to distort the playing field, if they are ineffective they allow folks to distort independently. So large companies send representatives to standards bodies to distort them in favor of their own company (Rambus is the canonical example) and other companies send representatives to make them ineffective so that they won't level the current field (Microsoft and XML is the canonical exemplar there). The bottom line is that Standards bodies whine that nobody lets them do their job, and they tolerate members who actively prevent them from making progress. I have long since given up feeling any sympathy for them whatsoever.

masklinn 15y ago
> Welcome to the 'standards' world. It sucks big time. Because a hegemony is so much better right? What fun that was last time around.

zobzu 15y ago

the guy proposes to kill standardization bodies, and that web engines should do w/e the hell they like, regardless of standards. coming from what appears to be a webkit dev, that's pretty bad. standardization bodies should certainly be deeply fixed - but this kind of reply is wrong.

gavanwoolery 15y ago

I am going to go out on a limb and say: fuck standards. Make a powerful, but extremely simple (as in: small instruction set) virtual machine and protocol. That way anyone can make their own standards.

jarek 15y ago
Sir, do you understand the World Wide Web?
- gavanwoolery 15y ago
  Apparently not - what am I misunderstanding?
  - jarek 15y ago
    More-or-less assured interoperability and complexity of content creation stand out as two of the larger issues. Episodes of the web's history when organizations did create their own standards might be another one.

eslaught 15y ago

Why doesn't the standards body ask webkit to deprecate and begin to phase out any -webkit-* CSS selectors which have been fully standardized? That seems like an effective way to force people to use the standards once they actually exist. Complaining about people using -webkit-* before the standards exist is obviously unreasonable, considering the implications of populating the global namespace with conflicting versions of the same feature.

deleted 15y ago
[deleted]
- ootachi 15y ago
  Bringing up racism, sexism, and homophobia in a discussion of Web standards is a little bit extreme, don't you think?
bzbarsky 15y ago
The standards body has asked WebKit to do that, in fact. Apple flat-our refused to ever remove -webkit prefixes that they have once shipped. Note that no one is complaining about the mere existence of the prefixes; the problem is: 1) The way they're being used by web developers. 2) The fact that some of these properties are not standards-track, with Apple actively refusing to allow them to be standardized.

jmsduran 15y ago

Kudos to the author of the article. I read the referenced article on glazman.org, and once "glazou" described -webkit-* as having "hardware market dominance", I could not stop LOL'ing until I finished reading his blog post. Seriously?! I second that the web is constantly evolving, whether or not it benefits the ego-fat cats at Google, Apple, or Mozilla. Get used to it and adapt, at least that's what I remember hearing in a Google Tech Talk back in 2008, does anyone still tune in to those?

readme 15y ago

Great points. I'm going to automatically concur on the grounds that I don't think bureaucracies that produce nothing should have a say in the production of anything.

jerfelix 15y ago

I'm glad that the webkit-specific features were prefixed. I just wish they would have chosen a prefix that was a wake-up call to anyone relying on them. Perhaps a prefix like "this-feature-will-be-deprecated-in-2013-". Slightly off-topic, but in a similar manner, when we struggled with users permanently deleting records, ignoring the warning that they were permanently deleting records, and calling us to retrieve the irretrievable, we changed the confirmation box from "click OK" to "type the word 'irreversible". This cut the calls to near zero.

meow 15y ago

I think the reason for this kind of slow evolution is lack of generic properties (like --surprise-- internet explorer's filters ) which lets developers push the boundaries on their own with in a reasonable limit. For example, support for border-radius, linear gradient, box shadow, text shadow etc all deal with rendering of elements at various levels. If there is a generic property which lets us control rendering and positioning of elements to a limited extent, the current evolution and standardization processes will be much less of a problem (I'm not saying internet explorer's filters are the way to go. But you have to give them credit for putting such a generic property in developer's hands).

BillPosters 15y ago

Front end Developers seem to disagree a lot. Some embrace the webkit prefix and sprinkle it all through their CSS. Others prefer not to resort to old fashioned site building techniques and instead aim to get the functionality working everywhere in one hit without coding like it's 1996.

dedward 15y ago

Let's broaden the picture a bit here and look at the internet as a whole. There are no standards - there are suggestions (RFCs), lots of open stuff (open source, free, whatever), and some closed stuff, and then there's what really happens. It turns out that IPv4 and DNS worked pretty well, though of course the internet at-large only uses a portion of those "standards". We didn't need an organization to tell us every last little detail and how it would work and "approve" it before we use it. People found out what worked, documented it, and it became the de-facto standard. We've never waited on the various internet "governing" bodies while keeping our own progress at bay. THere's absolutely no reason to. Know why everyone (more or less) obeys the allocations issued by ARIN? Because we recognize someone has to manage that limited resource pool, and they do an okay job of it. We're all free, more or less, to set up networks in whatever way we want, with whatever IP space we want - we just can't expect cooperation from our neighbours without some discussion and agreement so we don't stomp on each other's space - so we look to ARIN and their brethren to manage this. If they ceased to do so efficiently, they'd be replaced. The W3C has no power to force a developer or vendor to implement a given feature or not, and nobody really cares whether or not something is "officially" compliant. Most web pages are not fully compliant... yet the web, built by kids and adults and everything in between grew up and here we are, talking on HN. It'd be great if people could agree when we end up with overlapping features from different vendors...... it makes it hard for the developers right? That should be obvious to all. But we've switched browsers over the years, and will again, and whichever ones actually do what people need them to do, as well as keep developers happy, will prosper - w3c has little to do with it as far as I can see. Same for DNS (gripes aside - let's be realistic). We implemented IPv4 and it works great, but does the internet at large obey the type of service bits which are part of that standard? heck no. It's a big, evolving, organic thing. The web - same deal. Know what makes a standard? Something people adopt and continue using. Usage defines the standards - nobody is compelled to do anything just because it's a "standard" according to some group.

dreamdu5t 15y ago

... dcurt.is is an abuse of the TLD standards...

pippy 15y ago

>The reason the -webkit prefix was necessary is simple: the W3C and the CSS Working Group are ineffective, failed organizations. This is a bit too far. The -webkit prefix was a gesture of courtesy. What if other browsers implement it differently, and the spec changes? then older webkit browsers will render it incorrectly. The solution is simple: code to the standards, then target the fringe browsers. It doesn't matter if it's webkit or IE, this is a future proof, cross compatible solution that will solve both problems.

starfox 15y ago

I fully agree with this. CSS set the web back years with it's inability to handle simple layout. The W3C organization is run by representatives of major corporations, and the standards take years to roll out.