Re: Purpose of ring 0 and vendor prefixes (was: Re: Ringmark is now open source)

On Tue, 24 Apr 2012 02:37:23 +0200, Tobie Langel <tobie@fb.com> wrote:

> On 4/17/12 11:04 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>
>> Tobie Langel wrote:
>>> I aware of and concerned about the current prefix issues and regret the
>>> situation as much as anyone else here.
>>
>> Note that test suites can, to some extent, affect browser priorities.
>> Not using Ringmark to affect the prefixing situation to the liking of
>> this group would mean missing opportunity to make things better.
>>
>> (I think the prefixing concept is flawed so I wish scoring on
>> http://html5test.com/ and http://css3test.com/ didn't give a full
>> green pass for prefixed implementations in order to make browsers that
>> ship unprefixed score higher in order to incent browsers to unprefix
>> or to ship without prefix from the start.)
>
> I'm worried this could be a heated debate and I'd rather punt for now.

It could, although we could all try to be less heated. But I am really  
concerned about punting (much as I would also prefer to punt since it  
simplifies my life :) ).

The issues are serious for vendors, to the point of determining whether we  
support this initiative (which we did because we think it could be a  
vehicle for real improvement) or working against it, which we will have to  
do if it is creating more problems than it is solving and we are unable to  
handle the difficult questions within coremob. It would be pretty sad if  
we got to that stage, given all the good work we have to build on here.

>>> I'm suggesting that we treat prefixes on a case per case basis  
>>> depending on which category they fall into, as not all prefixes are
>>> created equal.
>>
>> The axis of prefix inequality you mention isn't the only axis of
>> prefix inequality. Ringmark treats -webkit-, -moz-, -ms- and -o- as
>> equally satisfying the passing conditions, but in the real world out
>> there implementing -webkit- is more compatible with mobile-oriented
>> existing content than -moz-, -ms- or -o-.
>
> Good point, I was looking at it from a developer's perspective, but from  
> a vendor's, the story is obviously different.

Yes.

>>> 2) After a while the spec and implementations mature and stabilize. The
>>> syntax is pretty much frozen, spec work is moving forward and is now
>>> clearly on standards track. Features is commonly used in production,
>>> despite still being prefixed. Now this is were things should move fast
>>> and haven't so far. A lot of the features devs rely on to build apps
>>> today are in that stage of the lifecycle.
>>
>> I think the existence of this stage of life cycle is a obvious bug. If
>> a feature works well enough to be commonly used in production, it in
>> practice isn't an experimental feature and shouldn't be prefixed. I
>> think it would make sense for Ringmark to set up incentives that steer
>> towards the elimination of this bug.
>
> Others will disagree. Let's not have this conversation for now. :)

Actually, please let's have this conversation. It's pretty fundamental to  
the way this group fulfills its mission.

>>> 4) Shortly thereafter implementors remove support for the prefixed
>>> version (this is not respected in practice).
>>
>> Actually, Mozilla and Opera have removed support for prefixed versions
>> of CSS properties. It would be very unfortunate if removing support
>> for -moz- or -o-prefixed features made browsers score lower on
>> Ringmark and, therefore, Ringmark would end up disincenting Mozilla an
>> Opera from removing -moz- or -o-prefixed features.
>
> Yeah, that would be absurd. Thankfully, it's not the case (and if it is,
> this should be fixed).

Accepting -webkit- prefixed versions motivates webkit not to remove  
prefixes. Because it encourages developers to believe they can use the  
prefixed version. (If we make a statement about how they must do that  
because at a given time it was true, then we are discouraging them from  
doing the extra useless work of adding the unprefixed version unless we  
explicitly provide motivation for that).

If developers come to rely on -webkit- prefixes, as to some extent they  
have done in some mobile markets, webkit is unable to remove them without  
breaking a lot of apps for users. So other browsers have to decide whether  
they want to be "correct" but irrelevant, or to do the only rational thing  
and implement -webkit- prefixes for certain features so that users' apps  
actually work. It is not a hard decision - this is what browsers have done  
for a couple of decades, and is why there are so many obscure things that  
look like bugs baked into the standards.

If the rhetoric about "what counts is what the browser vendors say" were  
true, this wouldn't happen. But nor would this group have a reason to  
exist. What developers use, and what influential guides like we hope to  
produce here tell them to use, are actually very important to the future  
of the web. Which makes it easy to do "evil" by failing to do the exta  
work of doing good.

>>> Coremob level 0 should be able to include specs currently at stage 2
>>> (how exactly we define stage 2 can be further refined) and add a
>>> non-normative disclaimer for developers that they might need to
>>> prefix the property.
>>
>> So what's the purpose of ring 0? What does passing ring 0 mean?

I think one of the key bits of shared understanding that we are missing is  
what kind of developer, and what kind of app, this work is directed at.  
There is a huge difference between the "long tail app" cranked out on a  
once-off contract, and something actively maintained by a skilled team who  
keep up to date with the latest trends. But that should be a separate  
thread.

>> If passing ring 0 means that the browser is compatible with app
>> written for "Android 2.2 Froyo and iOS5 default browsers", ring 0
>> should be testing transforms, transitions and animations only with the
>> -webkit- prefix, since supporting transforms, transitions and
>> animations with -moz-, -ms- or -o- prefix (or with a yet-unknown
>> prefix!) doesn't imply compatibility with apps written for "Android
>> 2.2 Froyo and iOS5 default browsers".
>
> Thanks for bringing in a vendor's perspective here, that helps me think
> this through.
>
> A browser passing ring 0 should mean that it is compatible with apps
> written for Coremob level 0.
>
> Writing an app for Coremob level 0 implies coding to the standards
> specified in the Coremob spec.

Let's carve these two points in stone. I think they are fundamentals...

> while being aware that a small subset of them aren't yet implemented
> unprefixed in existing browsers.

What happens in a few months? Some app developer picks up coremob 0 and  
decides to follow it carefully, because it is "done" while we are still  
discussing coremob 1. Various browsers have meanwhile added support for  
e.g. unprefixed transforms and animations. Will we have updated the spec?  
Will we be giving good advice to the developer, or will we actually be  
pushing her towards a dead-end path that looked promising until we  
realised from deployment experience that we would have to follow a  
slightly different direction?

> I think it is important for the spec to mention clearly (but non
> normatively) which standard features are potentially only available
> prefixed on existing devices as it will considerably lighten developer
> burden.

I would avoid doing that. I think we should include things we think are  
reliable enough for developers to build apps on them, and let people like  
caniuse.com do the hard ongoing work of tracking what exists when.  
Changing coremob 0 every time a new browser revision appears would be a  
major distraction.

> I don't think it is the role of the CG to push non-WebKit browsers to
> implement WebKit prefixes. Quite the contrary. One of the goals of  
> Coremob should be to incentivize developers to not write WebKit-only
> code.

I suspect (and hope) we can lock that statement in as an agreed principle  
too...

> I think this is best done by acknowledging the prefix issue, scoping
> it to a known set of features, making sure developers targeting these
> also provide unprefixed versions, and ideally, prefixed versions for
> all concerned browsers and not just WebKit-based ones.

>> If passing ring 0 means that the browser has equivalent but
>> potentially syntactically incompatible capability as "Android 2.2
>> Froyo and iOS5 default browsers", at minimum it should be made
>> abundantly clear to anyone running the test suite that ring 0 isn't
>> testing for interop in the sense that the same code "Same Markup if
>> you speak MS marketese" works and is instead testing more abstract
>> capability. Abstract capability is a slippery slope, though, since one
>> might argue that totally different gradient syntaxes are of equal
>> abstract capability or that SQL database and IndexedDB are of equal
>> abstract capability.
>
> There's a distinction to be made between features that only differs by a
> vendor prefix and those that differ by syntax.

Maybe. But from a "does it work" perspective, the prefix is as much a  
syntax difference as a different name for a parameter or property. I don't  
think the distinction helps us in practice.

>> OTOH, if ring 0 is about abstract capability rather that complete
>> compatibility all the way to the exact syntax, why not redefine it so
>> that passing ring 0 means supporting the abstract capabilities of the
>> intersection of the "Android 2.2 Froyo and iOS5 default browsers"
>> feature sets but with standard syntax?
>
> That's pretty much been the goal all along, modulo acknowledging (in some
> form or other) that some of the features, although implemented as per
> specs, might only be available prefixed in some deployed browsers. Happy
> to see we're converging. :) I'll edit the Wiki accordingly.

cheers

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 24 April 2012 11:07:33 UTC