Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Ojan Vafai]

I've emailed John Resig and a contact at MSDN for their respective test
suites. I haven't heard back from them. I'll ping.

The change is backwards compatible. As far as I know, no other vendors have
modified :not, but I haven't checked. The spec just got this wording last
week.

Ojan

On Thu, Mar 31, 2011 at 4:25 AM, David Hyatt  wrote:

> Yeah, I'd prefer not to prefix :not.  (Haha.)
>
> In fact :not used to actually support more complex selectors, and I had to
> dumb it down to pass stupid CSS 2.1 tests that deliberately checked for the
> lack of complexity... so all we'd be doing is going back to our old
> behavior.  We should probably make sure those tests are not in the current
> version of the suite though.
>
> dave
> (hy...@apple.com)
>
> On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote:
>
> If the change is backwards compatible (i.e. if you don't break the behavior
> described in Selectors 3), then I don't think it needs to be prefixed.
>
> What have other vendors done?
>
> Simon
>
> On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote:
>
> What's the right thing to do for something that is in a CR spec, but the
> draft spec for the next version has it behave differently? Specifically, in
> Selectors 3, :not only accepts a single simple selector. In Selectors 4, it
> accepts a comma separated list of compound selectors (a superset of the
> Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994.
>
> I see three options:
> 1. Wait until Selectors 4 hits CR before changing :not.
> 2. Implement :-webkit-not to match Selectors 4 and leave :not matching
> Selectors 3.
> 3. Make :not match Selectors 4.
>
> My preference in this instance is option 3.
>
> Ojan
>
> On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt  wrote:
>
>> As was mentioned already, we've been trying to follow the general
>> guideline of dropping the prefix when a draft hits CR and keeping it
>> otherwise.  An exception to this rule is if our syntax has not yet been
>> updated to match the CR syntax, in which case we  keep the prefix.
>>
>> dave
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[David Hyatt]

Yeah, I'd prefer not to prefix :not.  (Haha.) 

In fact :not used to actually support more complex selectors, and I had to dumb 
it down to pass stupid CSS 2.1 tests that deliberately checked for the lack of 
complexity... so all we'd be doing is going back to our old behavior.  We 
should probably make sure those tests are not in the current version of the 
suite though.

dave
(hy...@apple.com)

On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote:

> If the change is backwards compatible (i.e. if you don't break the behavior 
> described in Selectors 3), then I don't think it needs to be prefixed.
> 
> What have other vendors done?
> 
> Simon
> 
> On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote:
> 
>> What's the right thing to do for something that is in a CR spec, but the 
>> draft spec for the next version has it behave differently? Specifically, in 
>> Selectors 3, :not only accepts a single simple selector. In Selectors 4, it 
>> accepts a comma separated list of compound selectors (a superset of the 
>> Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994.
>> 
>> I see three options:
>> 1. Wait until Selectors 4 hits CR before changing :not.
>> 2. Implement :-webkit-not to match Selectors 4 and leave :not matching 
>> Selectors 3.
>> 3. Make :not match Selectors 4.
>> 
>> My preference in this instance is option 3. 
>> 
>> Ojan
>> 
>> On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt  wrote:
>> As was mentioned already, we've been trying to follow the general guideline 
>> of dropping the prefix when a draft hits CR and keeping it otherwise.  An 
>> exception to this rule is if our syntax has not yet been updated to match 
>> the CR syntax, in which case we  keep the prefix.
>> 
>> dave
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Simon Fraser]

If the change is backwards compatible (i.e. if you don't break the behavior 
described in Selectors 3), then I don't think it needs to be prefixed.

What have other vendors done?

Simon

On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote:

> What's the right thing to do for something that is in a CR spec, but the 
> draft spec for the next version has it behave differently? Specifically, in 
> Selectors 3, :not only accepts a single simple selector. In Selectors 4, it 
> accepts a comma separated list of compound selectors (a superset of the 
> Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994.
> 
> I see three options:
> 1. Wait until Selectors 4 hits CR before changing :not.
> 2. Implement :-webkit-not to match Selectors 4 and leave :not matching 
> Selectors 3.
> 3. Make :not match Selectors 4.
> 
> My preference in this instance is option 3. 
> 
> Ojan
> 
> On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt  wrote:
> As was mentioned already, we've been trying to follow the general guideline 
> of dropping the prefix when a draft hits CR and keeping it otherwise.  An 
> exception to this rule is if our syntax has not yet been updated to match the 
> CR syntax, in which case we  keep the prefix.
> 
> dave
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Ojan Vafai]

What's the right thing to do for something that is in a CR spec, but the
draft spec for the next version has it behave differently? Specifically, in
Selectors 3, :not only accepts a single simple selector. In Selectors 4, it
accepts a comma separated list of compound selectors (a superset of the
Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994.

I see three options:
1. Wait until Selectors 4 hits CR before changing :not.
2. Implement :-webkit-not to match Selectors 4 and leave :not matching
Selectors 3.
3. Make :not match Selectors 4.

My preference in this instance is option 3.

Ojan

On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt  wrote:

> As was mentioned already, we've been trying to follow the general guideline
> of dropping the prefix when a draft hits CR and keeping it otherwise.  An
> exception to this rule is if our syntax has not yet been updated to match
> the CR syntax, in which case we  keep the prefix.
>
> dave
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[David Hyatt]

As was mentioned already, we've been trying to follow the general guideline of 
dropping the prefix when a draft hits CR and keeping it otherwise.  An 
exception to this rule is if our syntax has not yet been updated to match the 
CR syntax, in which case we  keep the prefix.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Eric Seidel]

Sounds good to me.  Both patches have been updated to use -webkit.
Thank you for the explanation.

On Mon, Mar 28, 2011 at 9:21 PM, Darin Adler  wrote:
> On Mar 27, 2011, at 10:37 AM, Dan Bernstein wrote:
>
> I think Eric is not asking about the unicode-bidi property, but rather about
> the isolate value, which is not in CSS 2.1. I don’t know that there’s a
> guideline, but there is precedent for prefixing values (for example,
> display: box and display: inline-box), so I would recommend prefixing the
> new unicode-bidi value as well.
>
> The reason for prefixing is to be able to preserve compatibility if the
> meaning of “isolate” changes during the rest of the standardization process,
> but content relies on what we implement in WebKit.
> We should add a prefix.
> It will help us if the final “isolate” turns out to have a different meaning
> that it has in the current draft. Using the prefix gives us more options if
> that happens. We could keep our current meaning under the name
> “-webkit-isolate” if necessary. If things go well then “-webkit-isolate”
> will just be a synonym for “isolate”.
>     -- Darin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Darin Adler]

On Mar 27, 2011, at 10:37 AM, Dan Bernstein wrote:

> I think Eric is not asking about the unicode-bidi property, but rather about 
> the isolate value, which is not in CSS 2.1. I don’t know that there’s a 
> guideline, but there is precedent for prefixing values (for example, display: 
> box and display: inline-box), so I would recommend prefixing the new 
> unicode-bidi value as well.

The reason for prefixing is to be able to preserve compatibility if the meaning 
of “isolate” changes during the rest of the standardization process, but 
content relies on what we implement in WebKit.

We should add a prefix.

It will help us if the final “isolate” turns out to have a different meaning 
that it has in the current draft. Using the prefix gives us more options if 
that happens. We could keep our current meaning under the name 
“-webkit-isolate” if necessary. If things go well then “-webkit-isolate” will 
just be a synonym for “isolate”.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Dan Bernstein]

On Mar 27, 2011, at 9:27 AM, Simon Fraser wrote:

> On Mar 27, 2011, at 9:07 AM, Eric Seidel wrote:
> 
>> Do we have any guidelines as to when we use -webkit- for new properties vs 
>> not?
>> 
>> For example, when implementing CSS3 properties (like we are this week
>> for the BiDi sprint):
>> https://bugs.webkit.org/show_bug.cgi?id=57181
>> https://bugs.webkit.org/show_bug.cgi?id=50951
>> 
>> It's unclear to me whether -webkit- is required (or even desired) in
>> these cases.
> 
> Since unicode-bidi is part of CSS 2.1 
> ,
> then it shouldn't need to be prefixed, as long as the implementation is 
> consistent with the 2.1 text.

I think Eric is not asking about the unicode-bidi property, but rather about 
the isolate value, which is not in CSS 2.1. I don’t know that there’s a 
guideline, but there is precedent for prefixing values (for example, display: 
box and display: inline-box), so I would recommend prefixing the new 
unicode-bidi value as well.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Simon Fraser]

On Mar 27, 2011, at 9:07 AM, Eric Seidel wrote:

> Do we have any guidelines as to when we use -webkit- for new properties vs 
> not?
> 
> For example, when implementing CSS3 properties (like we are this week
> for the BiDi sprint):
> https://bugs.webkit.org/show_bug.cgi?id=57181
> https://bugs.webkit.org/show_bug.cgi?id=50951
> 
> It's unclear to me whether -webkit- is required (or even desired) in
> these cases.

Since unicode-bidi is part of CSS 2.1 
,
then it shouldn't need to be prefixed, as long as the implementation is 
consistent with the 2.1 text.
You should also check that the relevant tests in the CSS 2.1 test suite pass.

Simon

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Peter Beverloo]

On Sun, Mar 27, 2011 at 18:07, Eric Seidel  wrote:
> Do we have any guidelines as to when we use -webkit- for new properties vs 
> not?
>
> For example, when implementing CSS3 properties (like we are this week
> for the BiDi sprint):
> https://bugs.webkit.org/show_bug.cgi?id=57181
> https://bugs.webkit.org/show_bug.cgi?id=50951
>
> It's unclear to me whether -webkit- is required (or even desired) in
> these cases.
>
> It would be useful to have more general guidance (in a public place) as well.
>
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>

There was some discussion about this a while ago on www-style[1],
based on which Tantek Çelik sketched the following proposal:
http://wiki.csswg.org/spec/vendor-prefixes

The proposal concludes that the right time would be after the spec
reaches Candidate Recommendation-status, albeit with certain
exceptions.

While this doesn't necessarily apply to WebKit, it should be kept in mind.

Regards,
Peter

[1] http://lists.w3.org/Archives/Public/www-style/2011Mar/0007.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Use of -webkit- prefix on CSS Values and Properties

[Eric Seidel]

Do we have any guidelines as to when we use -webkit- for new properties vs not?

For example, when implementing CSS3 properties (like we are this week
for the BiDi sprint):
https://bugs.webkit.org/show_bug.cgi?id=57181
https://bugs.webkit.org/show_bug.cgi?id=50951

It's unclear to me whether -webkit- is required (or even desired) in
these cases.

It would be useful to have more general guidance (in a public place) as well.

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev