Some clarifications
By glazou on Thursday 9 February 2012, 19:38 - Standards - Permalink
My recent article triggered a massive response on twitter and in the Web Authors' community, and that's exactly what I think was needed. Let me clarify a few things:
- Some say it won't be enough. That's entirely possible. Read it again: that's entirely possible. But at least I tried. And I did it because someone had to do it. I am accepting the fact some browser vendors could call me a painful asshole if it could help the Open Web. I'm not here to secure the market share of browser vendors. But I do care for the Architecture of the Web, its maintainability over time and even more for its coherence. I find non-WebKit-based browsers adopting -webkit-* properties a nightmare, and I will fight that as much as I can. Only then, if everything else fails, I'll accept to consider the last resort and terrible solution proposed by Microsoft, Mozilla and Opera.
- I think Microsoft, Mozilla and Opera have, like Microsoft did in the past, underestimated the negative PR impact or decided to live with it. That's where you can help. Show them they can't live with it. Force them to find another solution.
- Yes, I know that browser vendors have tried evangelizing web sites. Well... Opera has a large evangelization team dedicated to mobile. Mozilla has only a little one and not sure it's dedicated to mobile in any way. I have no idea for MS but they certainly have one. Now, all that evangelization happened far from public's eye. My goal with my article was to put it back under public scrutiny and request public's help to reach a stronger impact. That's why I wrote that your voice does matter. And it really does.
- Some say it's because of W3C's Process that slows things down. No it's not. When a browser vendor has Intellectual Property Rights on a feature, when that browser vendor does not submit a technical proposal for that feature to W3C and when that feature hits the whole Web, there's nothing the W3C - or even other browser vendors - can do without facing legal action on one hand, potential incompatibilities with the protected feature on the other. Blame that browser vendor, not W3C or its Process.
- Some say forget about the problem and use frameworks on the server-side. Oh come on. That's curing a severe wound with a plaster and Tylenol... And that's not always possible.
Comments
Perhaps non-Webkit mobile browsers should detect when -webkit- prefixes are used in the absence of other vendor prefixes, and present a slightly annoying option asking whether the user wants the browser to cheat and support the webkit version (perhaps with a dire warning about unexpected consequences.) It's even ok if there's an option to always do this; the nuisance factor for the first hit could get enough users to complain.
Still, if a given site really is being accessed by an overwhelming percentage of webkit users, then perhaps the owner won't care. So in addition, automatically request /compatibility.txt (similar to /robots.txt) that can give directives on whether to support the webkit prefixes. If the site owner adds the other vendors' prefixes, those hits go away.
Implement this in the desktop versions of the browsers too.
@Steve Fink: that won't be enough for Web Agencies, that test prefixed properties per corresponding browser. It is clearly a maintainability issue.
How can you say that the W3C is not slowing things down? Obviously, Apple's "creative" way of adding new features to WebKit is not ideal, but this whole prefix mess is only caused by W3C's slowness. Or do you consider it fast that the first CSS3 modules were proposed in 1999 and 13 years later only three have become Recommendations? 13 years is far tool long on the web and that is why browser developers cannot wait and thus have to use the prefixed version. If W3C moved at a somewhat less glacial pace, all this would have been avoided. 3 years should be plenty of time for any proposed feature to make it to a Recommendation.
I'm not saying that the W3C is the only cause of the current prefix hell - but they sure aren't helping matters either.
> Show them they can't live with it.
I didn't read your article as being against the browser vendors, but rather as an call to action to give them another way out. I would think that they would rather not support -webkit-* if they didn't have to.
But if vendor prefixes was really only for testing, then they should be disabled by default in release browsers possibly with a small white-list of domains for the vendors own domains for show-cases. Developers could then test them in test releases or by flipping a hidden pref to test it on their own creations. Then they not-yet-ready features wouldn't even need prefixes.
But as soon as the vendor prefixed feature is out there in released browsers enabled by default, then it is sadly part of the web and no better than bgsound or marquee.
Daniel, I realize that you're viewing this as a personal failure (with your co-chair hat on), but "force them to find another solution" and trying to create negative PR out of thin air to make this happen seems excessive. If you do succeed in making this not happen (which I seriously doubt), the conclusion I will reach is that Opera, Microsoft, and Mozilla would have done better to just get together and decide on this silently instead of bringing it up in the working group.
Note that I put your chances of succeeding by getting sites to fix themselves at precisely 0, so "success" will simply be due to creating huge amounts of negative PR....
Overall this reflects IT currently being in a kind of paroxystic "the shoemaker has always the worst shoes" syndrome regarding its necessary IDs.
Hierarchical "keywords kind" name spaces do not scale, this is a myth, plus "hierarchical" keywords type name spaces aren't hierarchical at all in fact, the "README" symbol is the same whatever directory it appears in, /lib/doc/mysoftware is more an s-expression on a flat "lib" "doc" "mysoftware" symbol space than a "hierarchic" thing.
What is needed is to have both "number kind IDs" and "keywords kind IDs".
"number kind IDs" at execution, and allowing things like :
Ok we have this new property or feature, let's make it global with this name in W3C namespace keeping the "number kind ID" given by whoever created it.
More on this :
http://groups.google.com/group/comp...
or :
http://iiscn.wordpress.com/about/
Time to realize that "openess" means or should mean primarily sharing a "source" of IDs usable in any context in a bottom up vision, and that the text book picture "hierarchical vision with root at the top and as many branches down" is totally misleading.
Imho, the solution is quite simple for CSS : always add all prefixes for non-standard property and the future property without prefix, so you will be sure it will be displayed in any case.
By the way, I don't understand why Mozilla wants to do this, their mission/motto is to promote open web, and it seems that it is in contradiction.
The risk, that people seem to fail to understand, is that a few years from now, we may/will end up seeing -webkit-* in half the CSS properties used. Vendors will implement standard properties but people (designers, developers) will have written webkit-only instructions as it will work as a no-brainer (remember divitis in HTML?).
And that will be extremely contrary to what the philosophy of vendor prefixes is —even if it's very useful in itself as a safe way to test implementations, with the assumed idea that a prefixed property is not here to stay: it will be either superseded by a standard property or dropped altogether. People must be reminded of that, too.
I signed the WASP petition https://www.change.org/petitions/mi... and fully support your call to action.
I DO NOT WANT A -webkit-* PREFIXED CSS WORLD.
Stephane Deschamps
Founder, Paris-Web
Accessibility and interoperability evangelist, Orange Group, writing on my own behalf.
"my recent article"
really?
how about a link to that?!?!
Seriously, this is bullshit. Blaming webkit for innovating and implementing CSS3 like no other vendor is stupid. If other vendors would work this hard implementing these features also, there would be no need to use Vendor prefixes. Also saying W3C is not slow is simply retarded. Today standards should be implemented asap, not years, not even weeks in matter of days, because that's how it's evolving. And if Webkit brings a lot to the table, let it have the best market share, because it deserves it.
All your problems for a pure Web (standardized and compatible between vendors) reminds me problems of pure Java.
Some parts of Java have multiple big vendors (mostly coming from Oracle, IBM, Red Hat, VMWare, etc.) maintaining a correct compatibility, because others vendors are more or less gone (e.g. Microsoft with all C# world, Google AppEngine or Android, Apple WebObjects).
This Microsoft/Google/Apple tactic of embrace & extend [1] is mostly an antitrust problem, but lack of legal efficiency affect badly compatibility in technology (no legal sanction before multiple years).
After some years and some failed technology from a big vendor, developers are becoming slower, more cautious and more standard-aware against promises from vendors. But new developers don't are cautious.
I think a good solution would be a public question to antitrust authorities from big countries against the three big companies (Microsoft, Google, Apple) forking standards by using their name in uneducated public (companies selling to professional - more educated ? - markets like Oracle and IBM seems slightly more standard-aware in these markets). It is possible in US that a class action against vendors would be the good solution for ensuring a compatible world for public, given nobody seems to be really efficient on vendor lock-in by these technologies (embrace&extend a standard, data in cloud).
[1]: http://en.wikipedia.org/wiki/Embrac...
PS: Following discuss at W3C CSS Meetup at La Cantine. Here is a link on CSS used in JavaFX:
http://docs.oracle.com/javafx/2.0/a...
and one example:
http://fxexperience.com/2011/12/sty...
Given this is CSS for styling a Java application (created from Java and possibly a specific XML for layout named FXML) and there is no problem, like in Web, of HTML being sometimes at UI level, sometimes at semantic level. CSS is only for styling, FXML or Java for layout, no semantic level: there is no CSS properties for layout, media query, etc. (it is the job of Java possibly helped for initializing instances from the FXML file).
Some prefixed properties (background, borders, margins, paddings) are mostly identical to W3C CSS.
There is few additions, like -fx-shape with an SVG path, like in these examples:
http://pleasingsoftware.blogspot.co...
When I read your piece yesterday, I agreed 100%. But reading the updates I've felt doubts creeping in. I'd be grateful if you could address them (I still feel uncomfortable with the webkit-* prefixing, but I can't really see a compelling rationale...so call this Devil's Advocacy).
From your post:
"...this can lead to one thing only and we're dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard."
What's wrong with that? I'd imagine the vast majority of standards started as single implementations.
"It will turn a market share into a de facto standard,"
Again, what's the problem? A standard is a standard, if everyone agrees on it (and that's what the talk of adoption sounds like). Can't de facto standards become de jour? Isn't a market share a positive thing, compared to creating a standard which no-one actually supports?
"...a single implementation into a world-wide monopoly."
How so? If it's adopted as a standard by the majority of vendors, where's the monopoly?
"Again. It will kill our standardization process."
There I don't really have enough information to judge. It certainly seems an unconventional short-circuit of process. But the end is the same, isn't it? Agreement by the vendors on a standard, rather than a proliferation of alternatives.
The adoption of webkit-foo as the name for something rather than just foo sounds like it could upset non-webkit folks...but you seem to be saying the opposite.
The one problem I can see is that it confuses the naming of future vendor-specific extensions. Untidy, but not the end of the world.
I really can't see what it actually breaks to use the string "webkit-foo" rather than "foo" as the standard?
Sorry, I really should proofread first. "de jour" -> "de jure" (although there are definitely a few standards of the former kind around :)
The ? at the end was unintentional too, but does kinda express my position.
Please bear with me as I explain my background. It is important for the thoughts I have at the end.
I am an educator. I teach web development for a living and has done so for more than a decade. As a consultant for Skolverket, Sweden's national agency of education I have in fact succeded in making standards, accessibility and best practices mandatory requirements for all teaching in the country at the secondary level (approx. senior high school in the USA/A-levels in UK).
I am participating in the Web Standards Project Education Task Force, am co-author of InterACT with web standards and have written material for the InterACT curriculum project. I also participated in OWEA and now the Web Education Task Force at the W3C.
I thoroughly believe in education!
Nevertheless I do not see how education alone can solve the problem at hand. Too much misinformation, too much marketing, too much Apple- and Google-centric journalism. Education can only alleviate the problem, never solve it.
There is in fact a solution available. One that would do more good than anything else.
Webkit must drop support of prefixed properties when there has been a standards compliant solution implemented, after a reasonable grace period. Say 6 months.
And yes, that will break sites, which is the exact point of this solution!!!
This is the only way to create the necessary urgency that will reach into web development sweat shops in India and China, as well as into the corporate management level in the larger companies.
There are educated web developers that simply do not have the time or the mandate to fix problems like these, because upper management do not care. They think about their own producy here and now, not what's good for the web as a whole 10 or 15 years into the future.
This is primarily not about *blame*, but applying pressure where it is most useful.
Let's create and uproar in the web development world strong enough to create bad will for Apple, forcing upper management to do the right thing!
Apple (and to a lesser extent Google) are sitting on the solution. Not Microsoft, not Mozilla, not Opera.
If they are getting away with acting badly it is because we are letting them, letting our love for the products they make get in the way of the higher goals, letting them behave in ways that perhaps was OK when the iPhone was launched and Webkit had 0 % market share on mobile, but not changing their way according to the present situation.
Apple initially supported SOPA and PIPA - which speaks volumes about the default mind set within the company - but back peddled. So even if they have claimed that they will never remove the support for prefixes, let's create enough pressure on Apple that they will *benefit* from back peddling again!
Right now the pressure is applied to Mozilla, Opera and Microsoft to do the right thing, even if it will hurt their market share - and by extension their ability to fight for a free and open web in the long run. We are asking those companies to sacrifice themselves for the common good and for higher ideals.
But Apple is either loved too much for anyone to act against them - or seen as a lost cause, an unfixable problem, the IT equivalent of North Korea.
As long as the web development community is stuck in that love/hate relationship with Apple, we can never act sensibly.
Microsoft, Mozilla and Opera actually have two similar options at their hands:
1. Support select WD features with a ‘-webkit-’ prefix.
2. Support select WD featured without a prefix.
Both options only apply to features that they already support using custom prefixes. Both violate the current agreements on vendor prefixes, but option 2 is hardly discussed at all.
Choosing 2, they could improve their karma by pushing relevant specs to CR level ASAP.
Choosing 1, they’ll all be reborn as blowflies.
Has anyone disclosed data on how many (important) sites provide desired features …
a) with ‘-webkit-’ prefix only,
b) with ‘-webkit-’ prefix and without prefix,
c) with multiple prefixes,
d) with multiple prefixes and without prefix,
e) with some prefix that is not ‘-webkit-’,
f) with some prefix that is not ‘-webkit-’ and without prefix,
g) without prefix only?
In November 2011 you proposed this pragmatic solution on this very blog: “if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.”
That would mean Opera could show green text for ‘foo’ in all example rulesets that follow:
Only one wins
01. foo {color: green;}
02. foo {color: -o-green;}
03. foo {color: -webkit-green;}
Last one wins
04. foo {color: -o-red; color: green;}
05. foo {color: red; color: -o-green;}
Last one wins, or foreign one loses
06. foo {color: -webkit-red; color: green;}
Foreign one loses
07. foo {color: green; color: -webkit-red;}
08. foo {color: -o-green; color: -webkit-red;}
but these would be red:
09. foo {color: red; color: -webkit-green;}
10. foo {color: -o-red; color: -webkit-green;}
Is EPUB 3.0 a vendor? Quoting:
“The EPUB 3 CSS Profile employs the usage of the -epub- prefix for a number of CSS3 property names, as detailed below.”
See: http://idpf.org/epub/30/spec/epub30...
They say they are open to recommend removing the prefix in the future. Which essentially mean that they treat -epub- as an EPUB internal -beta- prefix … (Well, if they end up not removing it, then they have created their own “namespace”.)