> 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.
Copy & paste the code below to embed this comment.
bzbarsky
> 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.
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.
Copy & paste the code below to embed this comment.
teresko
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.
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.
Copy & paste the code below to embed this comment.
29webs
Hello Everyone,
I am here to just leave you a message that a brilliant team of web designer & developer has just launched the site 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.
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·
Copy & paste the code below to embed this comment.
kaichancoder
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.
Copy & paste the code below to embed this comment.
Rob W.
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.
Copy & paste the code below to embed this comment.
Richard Connamacher
If you have been in this field more than a few years, you surely remember that it wasn’t always like this
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 webkitCSS 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.
Copy & paste the code below to embed this comment.
Richard Connamacher
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. :)
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.
Copy & paste the code below to embed this comment.
Igguana
I have written reflection about this article in the European Commission’s forum E-practice. Please feel free to copy and paste it here if you need, and I apologize for my potential mistakes as I’m not a native English speaker.
http://www.epractice.eu/en/blog/5336231
Copy & paste the code below to embed this comment.
pixelutely
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.
Copy & paste the code below to embed this comment.
SelenIT
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)?
Copy & paste the code below to embed this comment.
SelenIT
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 :)
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?
@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:
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.
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.
Copy & paste the code below to embed this comment.
Richard Connamacher
Lars Gunther wrote:
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.
Copy & paste the code below to embed this comment.
Richard Connamacher
@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?
Copy & paste the code below to embed this comment.
bzbarsky
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.
Copy & paste the code below to embed this comment.
bzbarsky
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?
Copy & paste the code below to embed this comment.
Richard Connamacher
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?
Copy & paste the code below to embed this comment.
Pepe-el-toro
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.
Copy & paste the code below to embed this comment.
bzbarsky
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 Reader Comments
Back to the ArticleMykola
> 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.
bzbarsky
> 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.
CheapWebDesignSEO
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.
teresko
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.
yuhong
“The proprietary features of today are no better than ActiveX and IE filters.”
You mean “not much better”?
Niels Matthijs
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.
29webs
Hello Everyone,
I am here to just leave you a message that a brilliant team of web designer & developer has just launched the site 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
dforge
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·
kaichancoder
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.
Rob W.
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.
Richard Connamacher
I have been developing web applications since Netscape Navigator 1.0 first came out, and
webkitCSS 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
webkitprefix. 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 -mozprefix. 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.
Richard Connamacher
Dammit, alistapart’s comment system turns – webkit – (without the spaces) into
webkitand 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. :)
Lars Gunther
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.
Igguana
I have written reflection about this article in the European Commission’s forum E-practice. Please feel free to copy and paste it here if you need, and I apologize for my potential mistakes as I’m not a native English speaker.
http://www.epractice.eu/en/blog/5336231
pixelutely
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.
SelenIT
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)?
SelenIT
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 :)
columbus ohio web designer
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?
Lea Verou
@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:
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.
Richard Connamacher
Lars Gunther wrote:
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.
Richard Connamacher
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?
bzbarsky
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.
bzbarsky
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?
Richard Connamacher
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?
Pepe-el-toro
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…
bzbarsky
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.
Calatorul Moldovean
Very interesting and informative! Great article.