The future of CSS vendor prefixes | Hacker News Reader

The future of CSS vendor prefixes

lists.w3.org

42 pointsidan18 comments

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."

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."

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?

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.

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.

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.

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.

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/

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

> 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

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.

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

What else?

Don't use vendor prefixes.

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.

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

Use http://html5please.com to see what's "dangerous" and don't even think about coding CSS by hand (ie use Stylus, SASS, or Less to serve all vendor-specific flags).

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

Just read the lines that say RESOLVED: on them.

Reply on news.ycombinator.com