Re: The perils of prefixing... or rather trying to unprefix

|  How would this proposal have addressed the problem observed here?  I'm
|  genuinely curious.

Firstly, your property has the unprefixed name from start, so people can 
stop worrying about prefixes in their stylesheet and javascript. No code 
will ever break because the property "switch to unprefixed" because such 
things never happen in first instance.

Here's how the story of transform would have been with "vendor bangs" 
instead of prefixes:

    1] experimental stage:
        - webkit only recognize a 'transform' declaration as valid if it has 
the "target(webkit-1)" and is a valid "webkit-1-syntax" of transforms.
        - from the code, the developer has to do ".style.transform='.... 
target(webkit)'"

    2] experimental stage (II):
        - moziall only recognize a 'transform' declaration as valid if it 
has the "!target(moz-1)" and is a valid "moz-1-syntax" of transforms.
        - from the code, the developer has to do ".style.transform='.... 
!target(webkit)'" for webkit and the same for firefox (using if?)
        - if the syntax happens to be compatible and that the results are 
identical on most entries, the author could even use '!target(webkit-1, 
moz-1)' in one declaration

    3] standardization start (III):
        - browsers vendors create a new proposal that is sligthly different 
from both webkit and gecko.
        - wekbit introduce webkit-2 as a new target and could either
            - choose to use the same algorithm for both (2 superset of 1)
            - continue to use his old algorithm for declarations targeting 
webkit-1 (compat issues)
            - ignore webkit-1 declarations (no compat issues because fewly 
used)
        - same happen for mozilla

    4] standardization end (IV):
        - final spec is written and browsers want to "unprefix": from now, 
they'll just ignore any "target" declaration (so Opera would ignore 
target(webkit-2)) and use their final algorithm when the value is valid 
under the new syntax.
        - browsers could decide to keep some special behavior for compat 
reasons for specific targets (like iOS apps relying on wekbit-1) but output 
a warning in the console.
        - browsers could also "mark invalid" certain targets if they know 
for sure they cause compat issues (for example: when the angle of gradients 
did change of direction but the syntax stayed the same).

The important point is that (1) there's no one-declaration-per-prefix so if 
you know your declaration works in multiple browsers you can target them all 
at once (2) browser vendors can iterate their experimental implementations 
because they have a way to detect for which 'implementation' the declaration 
has been written (no compat issue) and (3) there's no need to have 
mozTransform and webkitTransform, you can just use transform all the time 
and rely on the "@supports" JS equivalent to know which targets a browser 
support. This is much better than just making the assumption webkitTransfrom 
implementation will stay the same all the time.

After that, the process of getting rid of experimental implementation will 
probably stay as bad as it's now. But at least, other browsers could 
possibly ignore the "target" token when the spec is finalized and run 
"previously-proprietary" code.

I hope you get the idea.

Received on Tuesday, 6 November 2012 22:00:29 UTC