RE: Unprefixing CSS properties

Tired of fighting Outlook formatting today.  Responses numbered…


(1)    Point noted.  I was being too broad in my language.  I was using the terms on a per-module basis implicitly rather than explicitly.

(2)    No.  I think it’s bad if they ship an un-prefixed one that is incompatible with the specification; or un-prefixes it in their implementation before the spec is ready (ready currently meaning CR + test suite).

(3)    Incomplete, I don’t have a strong feel for.  Incorrect/incompatible, yes I’d think that’s bad.  I’d need an example to give a more useful answer.

(4)    Again incompleteness in a “which properties” sense is very different form incompleteness in implementation of a single property.  IMO, un-prefixing the former is acceptable (Shiny not implemented, but Frosty fully implemented) but the latter (we implemented half of Sparkly) is unacceptable.

(5)    Well then we have a language barrier.  I have no other way of interpreting the “We had a meeting” paragraph that I quoted in my previous reply.

(6)    Perhaps you know a Robert that might want to sign up for some editorial work.  ;)

(7)    Great, maybe start a fresh thread (losing the baggage of this discussion) with a title such as “[css3+] Unprefixing policy proposal: pre-CR criteria”.

-Brian

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Wednesday, November 16, 2011 12:43 PM
To: Brian Manthos
Cc: Øyvind Stenhaug; www-style
Subject: Re: Unprefixing CSS properties

On Thu, Nov 17, 2011 at 9:27 AM, Brian Manthos <brianman@microsoft.com<mailto:brianman@microsoft.com>> wrote:
> "CSS3 browser" and "CSS4 browser" are meaningless terms.
No, they are not.  If that were the case, there is no point in having “Level 4” vs. “Level 3” modules.

(1) Is a browser that implements some but not all of CSS 2.1, some but not all CSS3 modules, and some but not all CSS4 modules, a "CSS3 browser" or a "CSS4 browser"?
No, I’m not saying that.  I’m saying that having multiple incompatible un-prefixed implementations of Level N of CSS for a given property is bad, in multiple ways.

(2) Do you think it's bad if a browser ships support for some of the new values defined in CSS3 Images, and not others?

(3) Do you think it's bad for a browser to ship unprefixed support for some, but not all, of the calc() property (for example)?

(4) In practice, what is the difference between "some browsers implement only the image values defined in CSS 2.1, but other browsers support the all CSS3 image values" vs "some browsers implement only the image values in CSS 2.1, but other browsers support a subset of the CSS3 image values"?
My interpretation of the latest flavor (in this thread) is "can we just violate the rules because we think these properties are really super cool and stuff?"

(5) That is not the correct interpretation. I also think gradients are super cool but the spec is still not stable enough for me to recommend unprefixing.
Options:
(A) Work to get the modules containing them to CR
(B) Propose a change to the W3C as a whole, or CSSWG as a part, that defines when it is ok to un-prefix outside of CR holistically, not just for the ones you've cherry-picked
(C) Lobby to get your cherry-picked properties to be treated as *special*

I'm arguing against (C).  (A) and (B) are fine; go nuts.

(6) To make option A happen quickly, in many cases we need to replace current spec editors with other editors who will can guarantee rapid progress. Unfortunately we don't have a supply of such editors.

(7) This thread implements option B.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]

Received on Wednesday, 16 November 2011 20:54:43 UTC