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 ArticleRichard 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.