Re: Unprefixing CSS properties

On 19 November 2011 20:05, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> The issue is not syntax changing; it's behavior changing without syntax
> changing.

Fair enough, this could happen, but the impact is likely to be
vanishingly small. Any significant change to feature behaviour will
almost certainly result in syntax changes. Any change that retains
syntax compatibility is likely to be around edge cases and affect
almost no deployed code.

Take border-radius for example, the tricky part of achieving
interoperability is determining what happens in cases with very large
values, interactions with other corners, transitions, etc. But the
actual deployed _use_ of border-radius is 99.9% cases like...

#myBox {
   border-radius: 8px;
}

...just bog-standard rounded corners that don't exercise any of these
strange cases.

In any case, all this is really just a distraction from the main
point. What's needed isn't different or clearer guidance for prefixes,
it's something better to replace them.

>> (Or rather, it doesn't "break", it simply reverts to the fallback
>> behaviour that I will provide for older browsers that never supported
>> these new features.)
>
> For behavior changes without syntax changes, this will be quite different
> depending on whether you include the unprefixed version.
>
> Furthermore, if you don't list an unprefixed version you might actually
> think about this fallback behavior business.  Right now a lot of authors
> don't.

If you don't believe authors think about fallback, when the most
popular desktop browser version supports almost none of these
experimental features, you're crazy. Including the unprefixed property
has no impact on this.

>> Don't keep
>> trying to solve unsolvable problems or save authors from ourselves.
>
> I'll settle for saving users from authors.  ;)

Great, because the status quo is hurting both. I look forward to your
contributions on a replacement for prefixes.

Thanks,

Jon

Received on Monday, 21 November 2011 13:46:51 UTC