Re: wading into the Prefix morass...

On 23/02/2012 4:36 AM, David Singer wrote:
>
> On Feb 21, 2012, at 18:38 , Alan Gresley wrote:
>
>> On 22/02/2012 4:25 AM, David Singer wrote:
>>> And a whole bunch of pages that used to work, stop working.
>>
>> No, the pages will still work. Some pages (which should become
>> smaller over time) may not show box-shadow or border-radius.
>>
>> Pages that use just box-shadow and border-radius without vendor
>> prefixes will work just fine.
>
> Alan, you're missing the point.  The feature that the author wanted
> (e.g. box-shadow), which is all we're discussing:
> * was originally
> documented as available only prefixed, so they write their pages
> using only the prefix;  it is as much an error to write unprefixed
> pages as unprefixed implementations

True but this seems to be the sequence of events.

1. Some authors begins to use only the prefixed version of particular 
property (or value) for the UA that they are testing (WebKit since 2008).

3. Vendor supports un-prefixed version of particular property (or value).

2. Vendor sees that there is legacy content in the wild using only 
prefixed versions of particular properties (or values) and realized that 
they can not just used the now standardized versions since this may 
cause some CSS effects to not show (I am talking about box-shadow and 
border-radius in this instant).

> * at some point, a decision is
> made to document the stable unprefixed version, and allows its use *
> you propose that the browser vendors then, at their next update, dump
> support for the prefixed version.

I would like it if the vendors set a timetable (suitable for respective 
release cycle). To my memory, Safari 2 supported prefixed versions of 
box-shadow and border-radius.

I would hope that Safari 6 drops such support. I would hope that Chrome 
18 (or 19) drops such support and I hope that Firefox 12 drops such 
support (Yes, Gecko also does it).

> All the existing uses of that feature (which is all we're discussing)
> then break, until the authors do an update.  Not acceptable.

Sometimes things must happen for progress.

>>> What's the corresponding benefit?
>>
>> To allow for CSS standardization to become better. To allow the web
>> implementation community and testing community to move beyond what
>> I see as a critical point in it's evolution.
>
>
> Its evolution will be fine, if we manage the transition from vendor
> prefix, to shared prefix, to unprefixed, correctly.  It won't be if
> we dump pages that used to work, abruptly.

I agree. I should note that WebKit supports an integer as a value for 
perspective.

   perspective: 500;

Where the CSS3 specifications indicate that perspective can only have 
values of 'none | <length>'.

   perspective: 500px;

Will WebKit always support 'perspective: <integer>' or is there a 
timetable to only support 'perspective: <length>' eventually?

Should I file a bug for both Safari and Chrome?



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Sunday, 26 February 2012 03:58:08 UTC