

The future of CSS vendor prefixes - idan
http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html

======
saurik
The people at the W3 who believe CSS-property vendor-prefixes are a good idea
and the people at the IETF who believe HTTP-header X-prefixes are a bad idea
should get together and have a good long discussion about this, as they
honestly seem to be two attempts to solve the same underlying problem in
extremely similar ways that cause nearly identical issues when these
identifiers are on a track to being included in a subsequent standard.

Deprecating Use of the "X-" Prefix in Application Protocols (IETF Draft) \--
<https://news.ycombinator.com/item?id=3539663>

(edit, from W3 discussion:) "dbaron: Email headers with X-. Supposed to be
experimental. But the world still works."

~~~
saurik
I'd love some explanation as to why someone downvoted this comment.

Not only is the X- prefix draft topical on Hacker News (as it was less than a
week ago that it first got posted here, despite having been published in
2011), but it is from another standards body that is addressing the same
underlying issue as this link to the W3.

As an example of how the content has severe overlap:

IETF: "Creators of new parameters to be used in the context of application
protocols: 1. SHOULD assume that all parameters they create might become
standardized, public, commonly deployed, or used across multiple
implementations."

W3: "Steve: Suggest that group establish a goal that members who introduce
experimental properties submit a description to the WG"

IETF: "Although in theory the "X-" convention was a good way to avoid
collisions (and attendant interoperability problems) between standard
parameters and non-standard parameters, in practice the benefits have been
outweighed by the costs associated with the leakage of non-standard parameters
into the standards space."

W3: "tantek: Once it's on the open Web, it's not proprietary...it can be
considered experimental, but claiming it is proprietary-only is inaccurate ...
plinss: Thing we need to spend some energy minimizing the escape of prefixes
into the wild"

IETF: "The primary problem with the "X-" convention is that non-standard
parameters have a tendency to leak into the protected space of standard
parameters (whether de jure or de facto), thus introducing the need for
migration from the "X-" name to the standard name."

W3: "tantek: One possible proposal is to only parse other vendors' prefixes in
conjunction with parsing unprefixed. e.g. with -webkit-transform. We wouldn't
parse that until we also parse transform. Thereby giving authors option to
just use unprefixed, hopefully biasing new authors to using that instead."

IETF: "Furthermore, often standardization of a non-standard parameter or
protocol element leads to subtly different behavior (e.g., the standard
version might have different security properties as a result of security
review provided during the standardization process). If implementers treat the
old, non-standard parameter and the new, standard parameter as equivalent,
interoperability and security problems can ensue."

W3: "macpherson: If we change the spec after implementation, you'll need to
return the value in the old form as a prefix. ... szilles: What do you do if
the values changed between property versions? alexmog: We'll adjust the output
to match the syntax of the given version. Rossen: I don't think that's right.
Today we only have aliases."

IETF: "We have already seen this phenomenon at work with regard to FTP in the
quote from [RFC1123] in the previous section. The HTTP community had the same
experience with the "x-gzip" and "x-compressed" media types, as noted in
[RFC2068]:"

W3: "glazou: [clarifies his understanding, and asks about prefixed values as
well] ... florian: Now, for prefixed values. I say just return the one you
got. plinss: Agreed. TabAtkins: Agreed."

------
sp332
HTML humor:

    
    
      <br type=lunch>
    

haha :) Anyway here's my question:

 _tantek: I think if you're working on open standards, you should propose your
features before you implement them and discuss that here.

smfr: We can't do that.

sylvaing: We can't do that either.

tantek: We're going to push you to do that sooner and sooner.

jdaggett: If you're proposing something that's going to be put on a Web page,
how is that proprietary?_

I'm with tantek & jdaggett. Why can't browser vendors propose a standard
before implementing it?

~~~
untog
_Why can't browser vendors propose a standard before implementing it?_

Because W3 takes forever to discuss, let alone approve it. HTML5 isn't going
to be ratified until 2014, for example.

~~~
starwed
They didn't say 'complete the standardization process before implementing'.

I think the idea is to _start_ the process, so that you don't just show up at
the door with a fully working implementation leaving others to play catch-up.

------
Zirro
It's IE's situation in: <http://webaim.org/blog/user-agent-string-history> all
over again. I would not like that mess to repeat with CSS.

------
Wilduck
I found the analogy to quirks mode really interesting, especially the lines:

    
    
       plinss: You said this is a short-terms solution. Quirks mode was supposed to be a short-term solution.
       tantek: No it wasn't.
       plinss: Yes it was.
       plinss: I implemented it before you did.

------
Zikes
They kinda called out Lea Verou in there, however she is trying to solve the
problem in her own way: <http://leaverou.github.com/prefixfree/>

------
daleharvey
oh god, vendors implementing each other vendor prefixes sounds insane.

I dont think -draft1-border-radius is the same problem as -webkit-border-
radius, I am pretty sure its how I would like these things to be developed, it
allows the vendors to work together on the same specification, with
opportunity for others to diverge, but web developers only need to know the
particular draft, not each various browsers implementation.

I also think that by the time vendors are implementing other vendors prefixes,
they should just be pushing to drop the prefix, that is the point

~~~
Wilduck
> I also think that by the time vendors are implementing other vendors
> prefixes, they should just be pushing to drop the prefix, that is the point

I think tantek advocates this approach, but in a different order. First make
sure you can support the feature without a prefix, and then support both.

    
    
       tantek: One possible proposal is to only parse other vendors' prefixes in
               conjunction with parsing unprefixed.
       tantek: e.g. with -webkit-transform. We wouldn't parse that until we also
               parse transform

~~~
Someone
I think the ' _fun_ ' starts when the vendor syntaxes and/or semantics are
slightly different and/or have different bugs. For example, the syntax
gradients in WebKit at one time were different from those in the HTML spec.

------
mildweed
So what can we do as web authors? I use standardized CSS generators that hit
all appropriate prefixes. ex: <http://css3generator.com/>

What else?

~~~
butterfi
We can also demand vendor free CSS from our contractors and developers. I've
had to ask several contractors, usually younger developers, to please not use
prefixes. They comply, but clearly think I'm too old school because CSS 3 is
what all the cool kids are doing.

~~~
akavlie
To be clear... are you saying you ask contractors to not use features like CSS
rounded corners, gradients, and box shadows?

------
Achshar
I would really appreciate if any one can summarize that :)

~~~
sp332
Just read the lines that say RESOLVED: on them.

