Blaming CSS WG is too easy, Brendan
By glazou on Friday 10 February 2012, 10:57 - Standards - Permalink
Brendan, I have the highest respect for you and you do know it. But I cannot let you affirm in public the current situation about prefixes was caused first by the CSS Working Group.
- the CSS Working Group gathers you guys, browsers vendors. The Working Group decides nothing "by itself", it's an empty shell where browser vendors discuss, sometimes fight, and reach consensus. If a consensus was reached about introducing vendor prefixes in the past, the MEMBERSHIP of the Group is fully responsible for it and that DOES include Mozilla, or more probably Netscape at that time but eh we were all there at that time.
- even the W3C Process is decided by the W3C Members. The CSS WG is totally out of scope here. It's like saying you blame an airport because you don't like showing an ID at the airport, the airport being bound by national and international regulations. Nothing it can do about it. Have someone at the W3C Advisory Board (you used to have Arun) or call for Process changes in a constructive way. But please, tell Mozilla reps to stop asking for Process changes in the CSS WG when the bits to change are NOT in our hands. That too sucks our time.
- the CSS Working group kept drafts under its wings too often not because of pains caused by the W3C Process but because of the perfectionism of the WG Members. And they include Mozilla. People who criticize W3C say it lacks pragmatism, but trust me on that please, I too often said "perfectionism on CSS 2.1 sucks our time for CSS 3". CSS 2.1 took too many years to emerge also because you browser vendors wanted the most perfect spec and could never end the loop.
- let's take CSS Variables, a top request by the whole CSS Community since 1997. Dave Hyatt and I had a complete, simple, nice, understandable, easily implementable proposal, Dave even implemented it in WebKit and shipped it. Finally removed it because other browser vendors ended up in endless discussions on the feature itself. The CSS WG is not guilty here. The browser vendors are. They argued and argued and argued ad nauseum, for something that could have hit browsers FOUR YEARS AGO and we still don't even have an alternative. Don't blame the CSS WG, blame your representatives to the CSS WG. Where is the lack of pragmatism and the lack of speed?
- when the whole mobile Web is full of a feature implemented by WebKit, documented by Apple in two lines only on their developer's web site, protected by IPRs owned by Apple, never submitted by any browser vendor to the Working Group, and when Microsoft, Mozilla and Opera want to implement that super feature because lack of it harms their market share, don't blame the CSS WG. Fight the legal issue about IPR, implement a counter-measure legally feasible we could rapidly standardize or get Apple to submit their feature to the WG. But you just cannot tell the WG is guilty in any way here.
- I have said dozens and dozens of times in the CSS WG that prefixes are a terrible burden on Web Authors' shoulders. It's only recently (relatively to the age of the WG) that we adopted a rule allowing us to get rid of prefixes when we think a feature is stable enough. But this rule comes, again, from CONSENSUS AMONG BROWSER VENDORS. The Working Group here is nothing more but a meeting room. Each time a new proposal to simplify (or get rid of) prefixes was submitted in the past, one browser vendor at least objected. So what should we do? Break consensus? On what basis? My chair's hat?!? Playing Heads or Tails? Even with the new rule, discussions about the stabilization of a given feature and removal of prefixes always lead to one browser vendor objecting to the proposal supported by the others. And it's not always the same browser vendor. How can you say here the WG is first guilty?
- as far as I know, the list of prefixed (and even sometimes unprefixed while they should be prefixed!) properties implemented by WebKit is the following one:
-epub-caption-side -epub-hyphens -epub-text-combine -epub-text-emphasis -epub-text-emphasis-color -epub-text-emphasis-style -epub-text-orientation -epub-text-transform -epub-word-break -epub-writing-mode -webkit-animation -webkit-animation-delay -webkit-animation-direction -webkit-animation-duration -webkit-animation-fill-mode -webkit-animation-iteration-count -webkit-animation-name -webkit-animation-play-state -webkit-animation-timing-function -webkit-appearance -webkit-aspect-ratio -webkit-backface-visibility -webkit-background-clip -webkit-background-composite -webkit-background-origin -webkit-background-size -webkit-border-after -webkit-border-after-color -webkit-border-after-style -webkit-border-after-width -webkit-border-before -webkit-border-before-color -webkit-border-before-style -webkit-border-before-width -webkit-border-bottom-left-radius -webkit-border-bottom-right-radius -webkit-border-end -webkit-border-end-color -webkit-border-end-style -webkit-border-end-width -webkit-border-fit -webkit-border-horizontal-spacing -webkit-border-image -webkit-border-radius -webkit-border-start -webkit-border-start-color -webkit-border-start-style -webkit-border-start-width -webkit-border-top-left-radius -webkit-border-top-right-radius -webkit-border-vertical-spacing -webkit-box-align -webkit-box-direction -webkit-box-flex -webkit-box-flex-group -webkit-box-lines -webkit-box-ordinal-group -webkit-box-orient -webkit-box-pack -webkit-box-reflect -webkit-box-shadow -webkit-box-sizing -webkit-color-correction -webkit-column-axis -webkit-column-break-after -webkit-column-break-before -webkit-column-break-inside -webkit-column-count -webkit-column-gap -webkit-column-rule -webkit-column-rule-color -webkit-column-rule-style -webkit-column-rule-width -webkit-column-span -webkit-column-width -webkit-columns -webkit-dashboard-region -webkit-filter -webkit-flex-align -webkit-flex-direction -webkit-flex-flow -webkit-flex-item-align -webkit-flex-order -webkit-flex-pack -webkit-flex-wrap -webkit-flow-from -webkit-flow-into -webkit-font-feature-settings -webkit-font-kerning -webkit-font-size-delta -webkit-font-smoothing -webkit-font-variant-ligatures -webkit-grid-columns -webkit-grid-rows -webkit-highlight -webkit-hyphenate-character -webkit-hyphenate-limit-after -webkit-hyphenate-limit-before -webkit-hyphenate-limit-lines -webkit-line-box-contain -webkit-line-break -webkit-line-clamp -webkit-line-grid -webkit-line-grid-snap -webkit-locale -webkit-logical-height -webkit-logical-width -webkit-margin-after -webkit-margin-after-collapse -webkit-margin-before -webkit-margin-before-collapse -webkit-margin-bottom-collapse -webkit-margin-collapse -webkit-margin-end -webkit-margin-start -webkit-margin-top-collapse -webkit-marquee -webkit-marquee-direction -webkit-marquee-increment -webkit-marquee-repetition -webkit-marquee-speed -webkit-marquee-style -webkit-mask -webkit-mask-attachment -webkit-mask-box-image -webkit-mask-box-image-outset -webkit-mask-box-image-repeat -webkit-mask-box-image-slice -webkit-mask-box-image-source -webkit-mask-box-image-width -webkit-mask-clip -webkit-mask-composite -webkit-mask-image -webkit-mask-origin -webkit-mask-position -webkit-mask-position-x -webkit-mask-position-y -webkit-mask-repeat -webkit-mask-repeat-x -webkit-mask-repeat-y -webkit-mask-size -webkit-match-nearest-mail-blockquote-color -webkit-max-logical-height -webkit-max-logical-width -webkit-min-logical-height -webkit-min-logical-width -webkit-nbsp-mode -webkit-opacity -webkit-padding-after -webkit-padding-before -webkit-padding-end -webkit-padding-start -webkit-perspective -webkit-perspective-origin -webkit-perspective-origin-x -webkit-perspective-origin-y -webkit-print-color-adjust -webkit-region-break-after -webkit-region-break-before -webkit-region-break-inside -webkit-region-overflow -webkit-rtl-ordering -webkit-svg-shadow -webkit-tap-highlight-color -webkit-text-decorations-in-effect -webkit-text-emphasis-position -webkit-text-fill-color -webkit-text-security -webkit-text-size-adjust -webkit-text-stroke -webkit-text-stroke-color -webkit-text-stroke-width -webkit-touch-callout -webkit-transform -webkit-transform-origin -webkit-transform-origin-x -webkit-transform-origin-y -webkit-transform-origin-z -webkit-transform-style -webkit-transition -webkit-transition-delay -webkit-transition-duration -webkit-transition-property -webkit-transition-timing-function -webkit-user-drag -webkit-user-modify -webkit-user-select -webkit-wrap -webkit-wrap-flow -webkit-wrap-margin -webkit-wrap-padding -webkit-wrap-shape-inside -webkit-wrap-shape-outside -webkit-wrap-through background-position-x background-position-y border-image-outset border-image-repeat border-image-slice border-image-source border-image-width overflow-x overflow-y text-overflow word-wrap zoom
many of them being "documented" by Apple. Some are well known, come from a CSS WG spec/draft/document, and have their counterparts in Gecko, Presto and Trident. Some are totally unknown to us and were never submitted for standardization. So again, don't blame the CSS WG for prefixed properties that NEVER reached us. They are going to hit the market and spread because of a company, not because of a standards body. For the ones you implement and people don't use, well, Apple has nice editing tools, nice IDEs. I told you a loooong time ago that a browser is only the top of the ecosystem's iceberg and that editing is still a major part of it.
- we already have an existing case with extremely ugly de facto standardization coming from WebKit mobile market dominance, and that's the infamous meta viewport tag. I heard myself some Apple engineers acknowledge it was a rather big mistake. We have CSS equivalents for this on our radar, submitted by Opera. We could have moved towards a de jure solution faster here but apparently there is little interest shown by browser vendors if you except of course Opera. Blame again the CSS WG for that? Not you, Brendan, please. You know too well standardization for that.
- all of that said, please tell me how you are going to get rid of the
-webkit-*
prefix (or even implement the prefixed version in Moz) for-webkit-text-size-adjust
given the IPRs?
It is too easy to always beat the CSS WG or the W3C. If you recall correctly, I have been one of the first ones to shout at the W3C in the XHTML2 fiasco. It was so early that Netscape still existed. I am still the first one to say it when they mess things up. But here, that's just unfair. I only agree that the CSS Working Group could have done better but hey, the Working Group members - hear YOU BROWSER VENDORS - decided there. So putting that organization at the top of your recriminations just carries a false message and hides an inconvenient truth.
Mozilla and Opera gave hand to Apple to create the WHAT-WG. You guys can speak together, for instance when your high-level representatives had a private secret meeting at Apple while the CSS WG was by pure coincidence in the meeting room on the other side of the corridor, was it november 2010. Meet again and let Apple know it must submit to the corresponding WGs technical proposals for the features that hit the Web and spread too wide to remain proprietary. Apple too must preserve the Open Web. So it says for HTML and APIs, so why not for CSS?