My (hopefully final) thoughts on the whole vendor prefix thing. sigh
5 plus ones
Shared publicly•View activity
- Alex, you've got some good thoughts buried under piles of straw men and misplaced CSS rants.
Just to pick one thing, on the problem of devices that don't make it easy to install another browser (short of jailbreak / dev switch), I made it quite clear that was perhaps one of the biggest threats to the open web at the W3C Developers conference this past November in Redmond.
Go watch the video  of the browser panel at the end or search for "Chromebook" on this liveblog of the conference:
I mentioned Windows 8 / Metro as well. Anyway, that's just one example, not sure it's worth anyone's time to pick apart the other baseless assertions, "logical fallacies and downright poor reasoning" in your post itself. I'll see if I can follow-up on the bits that make sense instead.
 http://cdn-smooth.ms-studiosmedia.com/events/W3C/Day2/Browsers_and_Standards.mp4Feb 15, 2012
- "Straw man"...you (and) keep using that word....
First, Chromebooks all have a developer mode that allows you to install whatever you please...including B2G. Can't wait to see that:
But, again, this is misdirection. I questioned your reasoning, I questioned your data, and I questioned your motives. Nobody has responded substantively about why the context I've attempted to put your assertions in is invalid. I can imagine several such responses, but you aren't making them (yet?). I look forward to those.Feb 16, 2012
- > "Straw man".
Yes. You claimed/asserted I/we were not paying attention to the broader threats of devices without browser choice. That was a Straw Man. I gave you citations that refuted it. Your post is littered with such straw men
> "you (and +Brendan Eich) keep using that word...."
Use your favorite search engine to look it up in Wikipedia - it describes what you're doing, e.g. the above usage.
> "First, Chromebooks all have a developer mode"
See above: "(short of jailbreak / ***dev switch***)" [****emphasis added****]
If you're not going to bother reading details in such a short comment, why should I bother writing anything longer refuting the rest of your "logical fallacies and downright poor reasoning"? You've demonstrated in a few short comments that it's not worth the time because you're either not reading, not listening, or not paying attention.Feb 16, 2012
- I think you're confused. You may have imagined that particular straw man, but I didn't argue it. I instead argued that what you cited as "warning sign" may have had vastly different causes than you were arguing were currently holding Mobile Firefox back.
I.e., that the most effective things you could do to combat what you see as monoculture (nevermind Opera Mini, I guess) might not have anything at all to do with user agents and prefixes. That's where the title of the post comes from.Feb 16, 2012
- I'm still reading all the details, but I'm happy to see this conversation.Feb 17, 2012
- Alex, let's focus on just one thing. You think we should work on distribution or "conversion" first, and only later, if data "proves" we need to, worry about attrition due to lack of WebKit UA or -webkit CSS property emulation.
Guess what: we are already working on mobile distribution, and before we can close any deals, early in the negotiations, if we even get this far, the potential partners say "why doesn't your browser render our site -- or gmail -- correctly?"
Often the answer depends on user-agent sniffing, but it also may depend on lack of -webkit CSS support, especially for significant effects, not just borders and margins. The issue is far from a minor degradation of presentation, but even visual glitches can kill a deal early in negotiations.
(Those who have missed it, please see the bug linked from https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility where we're gathering data.)
We then have to consider hacking on our UA string just as all browsers have done since "Mozilla/1.0" -- remember "(like Gecko)" in Safari's?
If that doesn't help the content to be rendered competitively, we may then have to turn to CSS properties. Who knows, there may be DOM emulations to consider too (just as we pioneered in 2004 for undetected document.all usage).
Again, this is just to get to first base with potential distribution or conversion partners. I know, we should just have $1B or so lying around to spend on ads and bundling deals -- but we don't. Does this mean we're unfit to field a mobile browser?
Anyway, we are living this right now, it's not something we somehow missed, or dishonestly tried to conceal. Assuming we're stupid or dishonest is no way to address us, if you're really interested in talking.
But you seemed genuinely (I'm not calling you dishonest) to miss that we can't even demo well to potential distribution partners if we're getting the HTML4, XHTML, or WAP version of a site for want of WebKit emulation. We can't focus on conversion or distribution without emulation to avoid instant attrition. Egg before Chick says we need some amount of emulation, which we are still trying to determine.
What's especially galling about your post is the big "be WebKit" digression. Being WebKit, or being like WebKit, but (really what you mean) possessing billions of dollars and even a whole smartphone-producing business unit, should not be required to field a mobile-web browser. But Google and Apple both have all that money and hardware, and more. And both companies ship browsers supporting -webkit.
So given your own admonition for us to focus on distribution or conversion, why won't you -- now that you have signficiant share -- remove -webkit prefix support right away (not later, when things are standardized), and walk in our shoes, or let's say the shoes you propose we should wear by focusing on distribution and not -webkit emulation?
You won't do it without standardization and more time to evangelize or pay content maintainers to drop their prefix uses. So why shouldn't we do exactly the same and emulate -webkit for now?
/beFeb 17, 2012
- Hi Brendan,
Taking one of your last points first, I'm advocating for exactly the removal of standardized -webkit prefixed properties from Chrome right now. That doesn't change anything for Android Browser or Safari, but it's a start, and I absolutely think it's up to us (the Chrome team) to do the right thing with regards to our prefix obligations here, including not shipping prefixed features for which we won't plump for standards or which are not in some way on a standards track. I don't have concrete news to share on this front yet, but the Chrome team is not afraid of charting it's own course. I'm hopeful.
But to call out something you said: you're asking for us to remove all webkit prefixes ahead of standardization....which defeats the entire point of keeping the prefix system functional. If you'd instead suggested that we should use real vendor prefixes (goog and apple vs. webkit), that might have been constructive...and I might even have agreed.
Back to your first point about distribution, lets say you do indeed need to spoof UAs, there's a strong argument that it's probably not going to get you what you want. See Michael Mullany's description of what Sencha has been backed into doing by the the constraints of the mobile environment: http://infrequently.org/2012/02/misdirection/#comment-239566
Implementing webkit prefixes isn't likely to change their nuanced perspective on the Gecko runtime. Similarly sophisticated sites should be reasonably assumed to be making analogous decisions about compatibility.
Lets assume for a minute that your point about distribution predicates is dead on: does it imply that you should be squatting prefixes or spoofing UAs for all sites? There's a recent history of browsers doing something more evolved: http://support.microsoft.com/kb/960321
Correct me if I'm wrong, but it appears that Mozilla's position is that the only way forward is un-mitigated prefix squatting, nevermind the potential harm to the potential for progress in CSS. Did I miss some nuance in the proposed prefix implementation?
I didn't miss the potential for harm. Instead, I suggested that if it's that bad, it might be more productive to make an enormous stink about prefixes (as this debate, thankfully, has) and consider ways of addressing the harm that don't cause more -- to the extent that such a thing is possible. That extent is a question for data to answer, and I've questioned what some of your data has shown. Working to get developers to change their behavior before committing yourselves fully to a path which is set to both drive prefixed features into the substrate of the web even further is what I'm advocating, all the while pointing out how we got here (Fennec and B2G late to the party, pain for Gecko embedders, etc.) so that we don't miss-ascribe outcomes to effects. Similarly, I didn't outline only one path (carrier distribution) to user acquisiton. It would have been foolish to do so; as the desktop FF and Chrome experiences without OS distribution and in the face of incompatibilities like ActiveX demonstrate.
RegardsFeb 21, 2012
- Alex, I will try to reply in a positive way and avoid bitchy, tl;dr point-counterpoint style.
First, thanks for advocating that Chrome drop prefix support as soon as the unprefixed standards are mature enough. Appreciated.
Google, not you, would help by doing the same in the stock browser, since that has the biggest share by far among Google browsers on mobile devices. That would move content authors more than anything Mozilla (or Opera, I suspect) could afford to do via paid and community evangelism.
However, you misunderstood my turnabout-is-fair-play argument. I'm not seriously advocating that you drop prefix support in advance of standardization. I wrote that as a hypothetical, to get you to walk in our shoes. How would web sites (including Google's) look on Android stock browser or Chrome on ICS without -webkit support? Not good. See what I mean?
You write about "Mozilla's position" but Mozilla, Opera, and Microsoft made their pitch jointly. Also, we are still evaluating data and taking properties one-by-one and in related groups. It's possible that we will end up at "zero" as the count of -webkit prefixed properties to emulate. I hope so. But it is not likely at this point, IMHO.
If the only effect of our troika's broadside is to get the CSS WG to standardize unprefixed forms of the webkit-prefixed de-facto standards, great. That group needed a kick in the pants (or two). On this point, you and I agree.
Mozilla had to come back from ~95% IE share on desktop, with ActiveX (bad) and .innerHTML/XHR (good) among the de-facto standards to consider emulating. I believe we made the right calls. In particular rejecting ActiveX and restarting NPAPI standardization via firstname.lastname@example.org was good for Firefox and good for the Web.
"Squatting" on vendor prefixes that have become de-facto standards is nothing like taking on ActiveX reverse-engineering work and (more important than the cost of that work) thereby tying the Web to unspecified Windows COM APIs and implementations. Almost all of the -webkit innovations are fine cross-browser potential CSS standards, not OS-specific piles of mystery meat.
Corruption is a problem for all of us -- including W3C, the whole CSS WG, Apple, Google, and Mozilla. Apple has not provided specs, says it can never retire prefixes, and continues to assert patents. Google did free-ride on -webkit but let's say that's in the past for Chrome (not Android stock browser). The CSS WG including Mozilla reps turned a blind eye to the emerging -webkit de-facto standards, or viewed them as mere input to much later (still in the future in some cases) de-jure standards.
In short, mistakes were made such that many -webkit style properties have become as much de-facto standards as .innerHTML was ten years ago. My view is "what's in a name?". The meaning and value to developers matters much more than the notation.
Therefore in order to level the playing field, I'm more than willing to consider "prefix-squatting". I hope we don't have to, but this is not thoughtcrime in my view.
On this we may have to agree to disagree.
/beFeb 21, 2012