Every Time You Call a Proprietary Feature CSS3, a Kitten Dies
Issue № 344

Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies

by
Published in Browsers, CSS, HTML

Public service announcement: Every time you call a proprietary feature “CSS3,” a kitten dies. Any -webkit- feature that doesn’t exist in a specification (not even an Editor’s draft) is not CSS3. Yes, they are commonly evangelized as such, but they are not part of CSS at all.

Article Continues Below
Article Continues Below

This distinction is not nitpicking. It’s important because it encourages certain vendors (*cough* Apple *cough*) to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread. The shiny new toys dazzle us and we start promoting them too, contributing to the echo chamber.

In our eagerness to use the new bling, we often forget how many people fought in the past decade to enable us to write code without forks and hacks and expect it to work interoperably. If you have been in this field more than a few years, you surely remember that it wasn’t always like this. The reason we now have this convenience is web standards, hard won in the Browser Wars.

You might be surprised to hear that web standards did exist during the Browser Wars too. The W3C was founded in 1994. However, authors didn’t care, and were perfectly willing to embrace proprietary extensions. As a result, browsers didn’t bother much with web standards. Does this remind you of something? The proprietary features of today are no better than ActiveX and IE filters. Their only difference is better PR, as we haven’t faced the consequences yet. Believe it or not, those features were also welcomed with excitement back in the day.

Yes, sometimes browsers come up with good stuff that does get standardized eventually (XMLHttpRequest, Drag and Drop API, contentEditable, Web fonts, to mention a few). However, nothing prevents them from innovating and following the standards process. Nothing prevents them from coming up with something cool, proposing it to the appropriate W3C Working Group, and improving it through collective feedback before rushing to implement it. If Microsoft had done this for the Drag & Drop API, it wouldn’t be such a PITA to use.

Proprietary features that haven’t been through the standards process usually suffer from poor design, even when the general idea is good. For instance, CSS gradients were a great idea, but -webkit-gradient() was a verbose, error-prone mess. Web fonts were a great idea, but requiring .eot files was not. The standards process doesn’t only help with interoperability, it also helps improve the design of every feature, due to the greater number and diversity of opinions.

So, which are these infamous features? In CSS, some of the most popular ones are:

  • -webkit-box-reflect
  • -webkit-text-stroke
  • -webkit-mask
  • -webkit-background-clip: text;
  • -webkit-text-size-adjust
  • -webkit-tap-highlight-color
  • -webkit-text-fill-color

Not every prefixed feature is proprietary. Some of them are just experimental implementations of features included in draft specifications. Which brings us to your next question.

“How do I detect whether a certain feature is proprietary?”#section2

A way that works for me is to search in Google for the feature (in quotes) and append site:w3.org to the search term, in order to only search within the w3.org domain. Two examples:

As you can see, one of the very first results for the first feature is a W3C specification. The results for the second one are merely discussions on mailing lists, which indicates there is no specification for it yet.

“How can I help?”#section3

The easy rule of thumb is to avoid proprietary features altogether. Don’t use them, don’t evangelize them, and most certainly, don’t depend on them. However, I understand that this might be more easily said than done. If you can’t completely shut proprietary stuff out of your life, here are a few guidelines I’m sure you can follow:

  • Make sure their usage complies with the principles of progressive enhancement so that the design works fine without them.
  • Don’t evangelize them or, if you have to, make sure to explain that these features are proprietary and what that means.
  • If you have to use them in your code, add a comment about this. Something like /* Warning: Non-standard */ would suffice. Many people learn front-end coding by viewing the source of existing websites. Even if you don’t give talks or write tutorials, you are probably indirectly teaching folks with every piece of code you put out there.
  • Call out articles, talks, demos, etc. that evangelize these features with no warnings, or that only use a single vendor’s prefix (which is also a very serious problem). Or, even better, fix them yourself, if possible.

“How can I help standardize a feature?”#section4

If you find yourself needing a proprietary feature too frequently, take action to standardize something similar. A series of steps I’d recommend is the following, most of which can be applied to new proposals in general:

Step 1: Research standards-compliant alternatives#section5

First of all, research standards-compliant alternatives. They might have worse or non-existent browser support, but at least you will know what to push for. You can even add it as a fallback, so that you don’t shut other vendors out even after they implement this feature.

You can even help to speed up implementation, by filing a bug in the browsers that don’t support it. Make sure to search for existing bug reports first. If it’s reported, you can still show that it’s important to you, by writing a comment (be polite!). Browsers take author demand into account when prioritizing which features to implement. Show them that a certain feature matters to you.

Step 2: See if the feature is already proposed#section6

The W3C discusses which features to add and how to tweak them to perfection in their mailing lists. There is one per Working Group (WG), and sometimes more, as Working Groups can collaborate in developing features that affect multiple technologies. For example, the CSS WG uses the www-style mailing list and the SVG WG uses the www-svg mailing list. However, for features that affect both CSS and SVG, there is the public-fx mailing list.

Before you post in any of these lists, please search for prior discussion of the issue. Every minute a WG member spends responding to duplicate suggestions is one less minute spent developing web standards. To search the archives, you can again use ol’ mighty Google. Type your keywords as you normally would and append site:lists.w3.org to your search query.

If you see that the feature is already suggested, but the discussion has stalled with no resolution, you can reply (once!) to bring it up. Please avoid coming off as impatient or irritated in your email. Keep reading the discussion for ideas on what to add that someone hasn’t covered already.

Step 3: Propose the feature#section7

Try to include as many relevant data as possible.

Some kinds of information that you could include are:

  • Use cases the feature is useful for. This is very important. No WG wants to standardize things that are going to be used in edge cases only. Show that what you’re suggesting is common. A useful technique to gather such use cases is to google for the proprietary feature and see what people are using it for.
  • Your experience from using that feature. What you like, what you’d change in the way it works, how could it be generalized, etc.

Also, decide which specification it’s for. You can find a list of the CSS specifications here. Then prepend the title of your thread with that specification’s ID in brackets. For example, if it’s for Values & Units, prepend it with [css3-values]. (The ID of each specification can be found in its URL.) This ensures that the editors of that specification will notice your thread more easily, and tagging helps everyone to follow the development of certain specs they’re interested in.

Another thing to keep in mind is that new features don’t get added to specifications that have reached, or are about to reach Candidate Recommendation status. Of course this applies to every status that comes after that, i.e. Proposed Recommendation and Recommendation. For example, if your suggestion is about adding a new selector, don’t suggest it for Selectors Level 3 (ID: css3-selectors), which is in Recommendation status, but for Selectors Level 4.

If you want to know more about how the standards process works, you can read fantasai’s excellent article series “Inside the CSS WG.”

“All this is hard and boring!”#section8

The same can be said for recycling vs. throwing everything in the same bin. Yes, it surely is harder than just using proprietary features and calling it a day. However, in the long run it’s in everyone’s best interests, including your future self.

Thanks a lot to David Storey, Sylvain Galineau, and Eric Meyer for their feedback.

37 Reader Comments

  1. What an absolute load of tosh. Talk about a Stalinist line on web standards.

    We should be encouraging browser developers to experiment with new CSS features, not dissuade them. It’s from these types of experiments that the W3C can learn from. It’s the same with LESS and Sass. In many ways I hate the philosophy behind these projects, that is, creating mutually exclusive CSS branches; but at least they provide a working example of a radically different CSS as laid down by the Central Committee of the W3C. We can learn from them even if we have don’t use them in our projects.

    You write:

    bq. It’s important because it encourages certain vendors (*cough* Apple *cough*) to circumvent the standards process, implement whatever they come up with in WebKit, then evangelize it to developers as the best thing since sliced bread.

    Hold on. Why single out Apple? Mozilla have got a tone of Firefox only CSS. Look: “https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions”:https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions. You are probably not aware of them because they are not as loud in shouting about their CSS experiments as Apple / Google / Chrome / Safari / Webkit are.

  2. “If you have been in this field more than a few years, you surely remember that it wasn’t always like this.” Yes; but it doesn’t follow (necessarily) that those who’ve been in the field for just a few years aren’t showing their elders enough respect. No need to make it an age thing, unless you have some data on that.

    But anyway, yeah. Andy Walpole, you’re kind of off the mark. She’s saying “don’t call it CSS when it isn’t,” and offering suggestions for just what to do about it. This is a productive way of doing almost exactly what you’re suggesting. That Mozilla page, btw, starts off by saying “CSS Properties that are Mozilla Extensions (ie: not part of the CSS Standard) should be tagged with CSS:Mozilla_Extensions.” I.e., it is helpful toward to the goal of standardization of exciting new features.

  3. Thanks for your article! However some of these features are great as long as they are used with extreme care and consideration for those who don’t have these features. Opera is doing wonderful things with pagination and Adobe is creating regions, some very useful ideas that would mean a lot, at least for me at my job at “Treesaver”:http://treesaver.net/ . The creativity from these development teams is fantastic and while no developer should rely on them they are important for the advancements of the web.

  4. You seem to be under the impression that W3C is a separate authority (the “W3C Central Committee”? ROFL. The staff contacts hardly participate in most WGs), coercing the poor browsers into following their dictatorship and stiffling innovation. This couldn’t be further from the truth. If you’d follow *any* Working Group, you’d see that implementors of all engines work together in harmony to form new standards. W3C *is* the browsers. But all of them, not just one.

    Mozilla is actually an excellent example of this, showing that innovation and web standards can go hand in hand, and end up in better results. Of course I am aware of their extensions. However, when they implement something they deem useful for web content, they propose it to the W3C and actively devote work hours to craft the specification. Apple doesn’t even have a dedicated standards person, unlike ALL the other vendors. They’ve even downright ignored requests by other browsers to provide specifications for their proprietary features. That on its own shows a lot about their attitude towards web standards.

  5. Opera and Adobe are not circumventing the standards process with these innovations, they’re actively working *with* the CSS WG to perfect these features and craft good specifications about them that other browsers can also implement. This is not just different, it’s the exact opposite from what I discussed here, and it worries me that you don’t see the difference.

  8. Other than reading “this other article”:http://lea.verou.me/2012/02/vendor-prefixes-the-css-wg-and-me/, I’m trying to find a reason why _this_ article was necessary.

    Vendor prefixes are quite helpful in moving the web along, and allowing authors to play with proposed vendor ideas, and submit feedback and bugs. Regardless of the fact of whether or not they have been proposed to the W3C working group (and I don’t see why that should be an issue), _authors_ need to understand what vendor prefixes are before they use them.

    It’s true the vendor prefixes have become ubiquitous, but that’s because the W3C has been slow to act, and slow to implement, and where they have proposed the spec, the browser vendors are still working out _how_ to implement in some cases.

    This _cannot_ be compared to the browser wars, as _that_ was a situation of browsers taking entirely different tacks, ignoring the W3C altogether, and implementing _primary_ features as they saw fit, with no regard to standardization.

    *This* is browser vendors using a standards provided path to implementing new/experimental features – *not* ignoring the W3C and everyone else.

    If _authors_ are using these features, without a thought to the proprietary nature of them, then that is the fault of the advocates who’ve evangelized using them, without fully explaining the cost/consequences, *not* the browser vendors, and not the W3C.

    This is not a situation of vendor prefixes being harmful. This is a situation of browser vendors rueing the primacy effect of first to market, first to implement, first at everyone’s fingertips.

    We shouldn’t be harping on a single browser vendors (or _any_), for implementing a feature, or users for using them — but we _should_ be ganging up on browser vendors who want to implement features of another browser vendor using that browser vendors prefix!

    Haven’t we learned from the Opera debacle where it identified itself as Microsoft’s Internet Explorer?

  9. @Ben Henick

    bq. “¦And even in the best case, there’s the question of what happens when a feature is finally promoted to Recommendation status. Eventually all of those vendor prefixes are deprecated and need to be removed. At best, that leads to seemingly endless chores; at worst, it results in sites that haul around all manner of legacy crap under the hood”¦

    In all seriousness, when was the last time you saw a feature go from proposed to recommendation status, and you had to update your codebase?

    In the time it takes most features to do this a site will likely be redesigned at least 3-5 times (only slight hyperbole). This was a similar conversation that came up around CSS hacks, and the reality of it was _never_ ever an issue. A site came up for redesign long before you had to worry about scraping legacy code out of the codebase. This is really a non-issue.

  10. > If you have to use [proprietary stuff] in your code,
    > add a comment about this
    checking a css file for comments manually can be quite tedious, as they’re often large. I redirect my page’s calls for css files to a script that parses two files; regular.css and proprietary.css (or more for convenience sake), the css contained in both gets spit out as one to avoid unnecessary http round-trips.

  11. > This is browser vendors using a standards provided path to
    > implementing new/experimental features — not ignoring the W3C
    > and everyone else.

    Except that’s exactly what Apple is doing in many cases. A bunch of -webkit properties have never been proposed as standards, and some of them Apple is flat-out refusing to submit for standardization even though the W3C has asked them to.

  12. Standards – an important source of information, because it summarizes the results of web development and practical experience.
    For the process of standardization is desirable to establish a working group with participation of the creators of web browsers and website developers. It is important to give the right to vote in the standardization process for web developers.

  13. Didn’t we already do this some time ago ?

    Or noone remembers the “Mobile IE incident”:http://blogs.msdn.com/b/iemobile/archive/2010/05.aspx ? Or some of “ripples”:http://cssglobe.com/post/9364/vendor-prefixes-and-web-standards in the aftermath ? The general CSS community in FreeNode #css IRC room has been warning people about this for years.

    And there is no way to fix the existing sites anymore. It is not a realistic solution. What we should do is *stop the damned hype*. Sites like SmashingMagazine, Tutsplus, ReadWriteWeb and Sitepoint should take the example from AListApart and make a first page article urging people to stop the abuse. Because, make no mistake : this is your fault.

  15. The biggest problem that exists today is that people in our industry actually believe these properties “push the web forward”, while more often than not they are just simple visual or functional frivolities.

    If your core content/services are strong enough none of this superfluous nonsense is actually needed. But more and more companies are finding themselves in competitive fields with very little core assets to distinguish themselves. So they go for image. Designers pick up on this, web developers end up with complex stuff they need to implement against tight deadlines. So yeah, 3d transform suddenly become very tempting to use, and make it look like they are pushing the web forward.

    In reality though, actual users of the web don’t give a damn. As long as you give them great/unique functionality and content, they’ll jump through just about any loop you hold in front of them. Not to say that design and usability are completely obsolete, but they should not be our core concern if we actually have something valuable to add through our website.

    What the web lacks is what I call “internet environmentalism”:http://www.onderhond.com/blog/onderhond/internet-environmentalism , a movement to counter the purely economical demands of companies, people that take a step back and are able to evaluate the things that really matter for the web. And let’s face it, most of the prefixed properties these days are definitely not part of that.

  16. Hello Everyone,
    I am here to just leave you a message that a brilliant team of web designer & developer has just launched the site http://www.29webs.com. Where you will find all premium and professional web templates for only $29. It has announced as the cheapest premium web templates ever. And any type of website development only $49 [templates $29 + development charge $20]. All the templates are very very exceptional and totally professional. Hope they will go so far.

    You can take a visit and look at the templates.

    Thanks

  17. A lot of critical discussion here but I think overall the post contains some really nice theory which does matter.. Propriety features should be kept apart from standards compliant features because it can add more confusion to an already fast moving industry.

    I will say though that actually implementing what is proposed is just a physical impossibility imho, though there are plenty of people who would agree this discussion alone shows that a lot of people do not, or half agree. To make this happen everyone would have to make it more clear when using propriety features and as such making sure that people who are learning from the information have a more full understanding·

  18. There seems to be several important aspects. Certain companies wanting platform ownership and thus $$$, mix this in with real good practice and then you can’t tell the difference. Is it for the good of the industry or just selling more stuff. But at the same time, we really want to push the creative boundaries. Its a difficult topic, I think each individual needs to decide for themselves, there is no black or white.

  19. Seriously, if you want a current, concrete example of why this is important, why we need to develop with standards first if we want browsers to become more standards friendly, read the other article this month on ALA. Developers building webkit specific mobile sites that exclude all other browsers (i.e., putting browser specific functionality above standards and inclusion, a mobile version of “Best viewed in Netscape 4.0”), and Mozilla, a browser vendor, responding by pouring tar and confusion over browser-specific prefixes and ua strings.

    It’s right there. Real life.

    As an aside to Neils, content is not the only thing companies are interested in serving their audiences through the web. Sometimes a visual/user experience that creates a specific brand perception is the primary goal of a site. The internet is big enough for all kinds.

  20. bq. If you have been in this field more than a few years, you surely remember that it wasn’t always like this

    bq. The proprietary features of today are no better than ActiveX and IE filters

    I have been developing web applications since Netscape Navigator 1.0 first came out, and -webkit- CSS extensions are _nothing_ like ActiveX. Microsoft’s proprietary additions were dumped into the main namespace and caused major compatibility nightmares, like two completely incompatible syntaxes for the same <object> tag. The way things are going now allows people to play with new features if they want or ignore if they want, and nothing breaks on older browsers either way.

    Since you’ve singled out Apple, let’s go over what they’ve been doing. Apple periodically has added a new visual feature to CSS, and namespaced that feature with the -webkit- prefix. Major examples I can think of are gradients, rounded box corners, box shadows, animated transitions, keyframed animations, 2D transforms, and 3D transforms.

    Some of those, like box shadow, were part of CSS3 first. But most were created by Apple to fill a gap, which they documented and submitted to the W3C for consideration in a future edition of CSS3.

    (As other people already mentioned, Mozilla does the same thing. Theirs don’t get as much press because most haven’t had the same cool-factor as Apple’s proposed extensions.)

    You mentioned -webkit-gradient, which was needlessly complex. That’s a great example, because after Apple came up with the idea Mozilla rethought it and released a simpler version with the -moz- prefix. The W3C came up with a proposed new syntax mostly based on Mozilla’s version, _and Apple then changed their own implementation to match_. That’s precisely how these things are supposed to work: one vendor comes up with an idea, another adds their two cents, the W3C proposes a final syntax, and everyone adopts the new syntax. Since these experimental versions are namespaced and can be stacked on top of simpler layout rules, anyone can experiment with them without fear of breaking the rest of the layout.

    You seem to be advocating for browser vendors to stop coming up with features themselves and instead focus on implementing whatever standards the W3C hands down from on high. That’s how XHTML 2.0 was developed and that turned out well didn’t it? HTML5, and CSS3, are constantly-changing documents driven by browser vendors themselves.

    The major alternative to using these extensions is to either stick to flat colors and rectangles, or to pre-render all non-flat non-rectangular elements in Photoshop (or GIMP) and turn the layout into a bunch of images.

  21. Dammit, alistapart’s comment system turns – webkit – (without the spaces) into -webkit- and there’s no way to preview that before you submit or to edit a comment after you’ve made it…

    So in my previous comment, none of those strikethroughs should be there. I’m talking about the CSS prefix tags.

    Ironic that a blog dedicated to CSS can’t format CSS prefixes properly. 🙂

  22. Please Richard Connamacher, read what bzbarsky and a few more people have written before you comment.

    There are quite a few properies that Apple has *not submitted at all* to the W3C. Properties covered by IPR that prevents other vendors from implementing them.

    That is monopolistic “embrace-extend-extinguish” policy and nothing else.

    And even when Apple do submit their inventions to the W3C, they are not documenting it properly or even actively working towards standardization.

    They are not paying anyone to work as a spec editor. Mozilla, Google, Opera and Microsoft do.

    They are not hiring open web evangelists to promote standards and X-browser development.

    So Apple clearly needs to be singled out. Hard facts can’t be ignored.

  24. I despair when I see posts like this, I really do.

    How on earth are the standards that drive the web supposed to grow and flourish without such things as vendor prefixes. Apart from a small handful I could mention, most that are in use at the moment render similar results and I’m sure that many of these will ultimately result in new Recommendations and common implementations further down the line.

    Maintenance is an every day part of the lifecycle of any web design, from perfectionist design tweaks to replacing outmoded markup with HTML5, or improving back-end code and services.

    Anyone who doesn’t like doing that kind of work or who doesn’t see the value in working with vendor prefixes is in the wrong job.

    At the end of the day, it’s down to the designer/developer to figure out the most practical way to implement a browser-safe design (if indeed the customer insists on the design being precisely the same on all browsers) – and to figure out if the longer-term maintenance of using prefixes can be accommodated.

  25. It might be strange to ask such a question to the author of *CSS3*test.com and many other awesome *CSS3* tools;), but still… Not so long time ago many Web evangelists “argued”:http://adactio.com/journal/1684/ against overusing the word “HTML5” as a marketing buzzword meaning “all these bright new things in the web front-end, including CSS3”. But doesn’t the word “CSS3” suffer the similar overusing problem?

    Perhaps “CSS3” needs even more clarification than “HTML5” did. At least, there is an actual W3C spec named “HTML5”, but “CSS3” is not the name of any actual spec. CSS has no versions, it consists of modules that are developed independently. Some level 3 modules are already Recommendations (and — as you stated in the article — the level 4 modules are already coming to extend them), while some (like CSS3 Tables) are just planned. But when we refer to some stuff as “CSS3”, we might accidentally make some less informed people think that “CSS3” is some kind of spec _version_. Haven’t you noticed many people asking “When _CSS3_ will be ready?” or complaining that “_CSS3_ is still a draft, _not a standard_” on the web developers’ forums?

    And this confusion might be doubled because of the lack of any tool to distinguish those parts of CSS3 that _are already the standard_ from those that are still at risk as something experimental. We have so called “CSS Snapshot”:http://www.w3.org/TR/CSS/ that, as I understand, should reflect the actual state of CSS development (which CSS features are definitely _non-experimental_ now), but it’s status is… “Group Note”, so it can’t be the normative reference. The “CSS Validator” also is not much helpful as it’s _level-based_ (?) and sees no difference between, e.g., the CSS3 Color (_Rec.!_) and the CSS Line Layout (_Draft_, which also has the “severe outadted” remark) by design. And in the last couple of years it has also changed it’s behavior so vendor-prefixed properties are just warnings, not errors any more…

    So if we can call “CSS3” the CSS3 Tables module, which even hasn’t been published yet, why can’t we call so such a well-supported (by more than one browser family!) property as “zoom”, someone might ask? If “the W3C itself doesn’t know exactly yet what will this ‘CSS3’ include”, why can’t we call so one of our useful features that might become standard “sometimes in the future” — some of the browser vendors might think? 🙂

    Here is my main question: does the actual maturity of the feature (is it still experimental or not) have more importance for those who will use it in practice, than the formal existence of the spec for it? In my opinion, yes, the expereimental status of the feature should be enough to prevent authors from using it in production (and from depending on it, of course), no matter if the feature is W3C-specified or not. But if my point is not a complete nonsense… should we have some more tools to tell the experimental and the “safe to use” features apart (better than caniuse.com)?

  26. Update to my comment above: it was supposed to have a title “So is calling W3C-specified features “CSS3″ absolutely safe for kittens?”, it was not cut in the preview, sorry for this technical misunderstanding 🙂

  27. I guess I’m confused about the process. So, I’ve always assumed the
    -moz, -webkit, and other prefixes were a good thing? Does the use of prefixes keep the standards from being implemented at a later time? I guess I don’t fully understand the argument against the use of prefixes? What is the driver in the argument? If we wait for the standards dictate everything we may never have that special thing or cool new feature? I don’t agree with big business and I feel as though this is along the same lines?

  28. @Richard Connamacher and others: If you think the article is against prefixes or vendors innovating, you apparently read it without paying the least bit of attention to most of it. Let me highlight a few parts:

    bq. Yes, sometimes browsers come up with good stuff that does get standardized eventually (XMLHttpRequest, Drag and Drop API, contentEditable, Web fonts, to mention a few). However, nothing prevents them from innovating and following the standards process. Nothing prevents them from coming up with something cool, proposing it to the appropriate W3C Working Group, and improving it through collective feedback before rushing to implement it. If Microsoft had done this for the Drag & Drop API, it wouldn’t be such a PITA to use.

    bq. Not every prefixed feature is proprietary. Some of them are just experimental implementations of features included in draft specifications.

    Also, I’m surprised at how many people seem to be aware of what the W3C really is and what the Working Groups consist of. There is usually 1-3 W3C staff members in every WG and that’s it. *Everyone else in them are from W3C member companies, and in CSS most are from browser vendors*. There is nothing that the W3C standards dictate “from on high”, it’s still the browsers innovating. The difference is that they’re doing it as a team with others, not on their own, which results to better features.

  29. Lars Gunther wrote:

    bq. Please Richard Connamacher, read what bzbarsky and a few more people have written before you comment.
    There are quite a few properies that Apple has not submitted at all to the W3C. Properties covered by IPR that prevents other vendors from implementing them.

    I did read bzbarsky, and he’s talking about a proprietary Apple ebook format that has nothing whatsoever to do with this article, the W3C, or web development in general. Apple’s decision to base an offline file format on an extended version of HTML doesn’t mean it is HTML.

    If Apple has promoted custom CSS extensions for actual web development and then claimed proprietary control over them and refused to submit them to standards bodies, please let me know.

  30. bq. @Richard Connamacher and others: If you think the article is against prefixes or vendors innovating, you apparently read it without paying the least bit of attention to most of it. Let me highlight a few parts:

    I did read that, and of the list you put forward how many were brought up as ideas without public implementations, put through a nice round table discussion among all browser venders and the W3C, before everyone then came together and implemented them in perfect unison? That’s just not how the process works.

    The problems you pointed out in that list (like drag and drop) list have already been resolved by using webkit, moz, o, and ms vendor prefixes in CSS, and similar prefixes in JavaScript and the DOM. Browsers can experiment without stepping on the W3C’s or each others’ toes. Microsoft has been very bad with that and Netscape was terrible back in the day, but even Microsoft has finally started doing the right thing with prefixes.

    And Apple has submitted their ideas to the W3C and worked to get support from other vendors. They just do so after releasing an experimental implementation first to show that it works and and works well. Which webkit CSS3 extension do you think didn’t follow that route?

  31. Richard, for example Apple promoted -webkit-text-size-adjust for actual web development, quite heavily in fact. And it’s refused to submit that property for standardization so far. They _might_ allow someone else to reverse engineer it. Or they might claim patent rights over it after someone puts in the work of reverse engineering and writing the spec, just like they did with the attempt to standardize touch events in the W3C.

    If you think Apple is playing sandards ball here, you _really_ need to open your eyes and look around.

  32. Richard,

    Apple has a ton of CSS extensions that it’s never submitted to standards bodies and that are in use on the web, especially on mobile devices. Its proprietary CSS mask stuff (instead of using the already-standard SVG masks), -webkit-font-size-adjust, -webkit-box-reflect, the list goes on and on. Some of these they have proposed an were rejected as far as I can tell (e.g. -webkit-box-reflect), while others they have just refused to propose to start with.

    Did you even try looking through a list of -webkit properties before making your comments?

  33. And didn’t even mention IBA. I was reading another comment thread at the same time where a poster was railing about about Apple’s epub-derived format and mixed it up with this one. My apologizes.

    I don’t know if they’re promoting webkit-text-size-adjust “heavily”, there hasn’t even been a post about it on the webkit blog and it’s not one that I normally see people use. (The only webkit blog post I found mentioning it is from someone who prevented it and other cruft from being added by contentEditable.) But they do describe it in their official documentation for iOS web development so that counts as some level of promotion. All the pages I can find actively promoting its use are on independent sites (including yes, an article on A List Apart about mobile web development). I can find very little about it in official channels outside of that developer document.

    Where’d you see that the W3C asked them to submit it for standardization or they flat-out refused?

  34. I remember coding specific HTML+CSS for Iexpoler and Netscape before 2004… It was a mess, most people who agree with this kind of crap practice are new comers that started playing cool designer in what? 2005-2006? When the was was over… I remember the ActiveX – Object – Embed stuff. Hacks for IE (Filter anyone?) and for others.

    Now try to do a better CSS, look at this line:

    background-image: linear-gradient(right , rgba(255,255,255,0.2) 49%, rgba(173,173,173,0) 0%);
    background-image: -o-linear-gradient(right , rgba(255,255,255,0.2) 49%, rgba(173,173,173,0) 0%);
    background-image: -moz-linear-gradient(right , rgba(173,173,173,0) 0%, rgba(255,255,255,0.2) 49%);
    background-image: -webkit-linear-gradient(right , rgba(255,255,255,0.2) 49%, rgba(173,173,173,0) 0%);
    background-image: -ms-linear-gradient(right , rgba(255,255,255,0.2) 49%, rgba(173,173,173,0) 0%);
    background-image: -webkit-gradient(
    linear,
    right top,
    left top,
    color-stop(0.49, rgba(255,255,255,0.2)),
    color-stop(0, rgba(173,173,173, 0))
    );

    WTF is wrong with the people who agree with this? Are they Apple fanboys or what? Now inst M$ the evil one…

  35. Richard,

    webkit-text-size-adjust is quite prominent in Apple’s iOS “how to write sites for Safari on iOS” documentation. See for example https://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html but there are plenty of other references to it there.

    Of course it’s not on the WebKit blog; there is no support for this property in WebKit proper. It’s a proprietary Apple extension; the only browser that supports it, to my knowledge, is Safari on iOS. There is no support in Safari on OS X, for example, nor in Chrome last I checked.

    As for the asked and refused part, there are several mentions in the CSS working group meeting minutes. That includes the minutes of the meeting where this whole prefix thing was brought up by Mozilla, Microsoft, and Opera. At the time the Apple representative made some noncommittal comments about how he’d see what he could to to convince the higher-ups at Apple to actually submit the property for standardization… and last I heard he’s failed thus far. See http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html for the actual minutes; search for “text-size-adjust” which is mentioned several times. Note the comments from “sylvaing” (the Microsoft representative) about previous requests that it be submitted and the what “smfr” (the Apple representative) has to say.

  37. Pingback: Lea Verou on Big Web Show - Zeldman on Web and Interaction Design

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career