"X-" deprecated for HTTP headers • Hacker News Board

Re: "X-" deprecated for HTTP headers

#31

Post by tszming » Tue, Jun 26, 2012, 1:59 PM UTC

regularfry wrote: post #15

lloeki wrote: post #12

Earlier quoted context omitted.

Not. How would you handle the case of pre-standard implementations? Like: -webkit-gradient( , [, ]?, [, ]? [, ]*) vs: -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? [, ]+); which eventually became: linear-gradient( [ [ | to ,]? [, ]+ ) In CSS, the vendor prefixes are exactly what we need. They help bootstrapping, discussing, and proofing standards by having pre-standard implementations in the wild. CS…

You can have pre-standard implementations without vendor prefixes. Here's an argument against them: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html And here's some further discussion: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html Personally I think vendor prefixes are an awful hack. We've already got browser-conditional comments in HTML, why not use them? Hell, browser-sp…

>> We've already got browser-conditional comments in HTML

You mean the `conditional statements` introduced and only used by IE?

http://en.wikipedia.org/wiki/Conditional_comment

Re: "X-" deprecated for HTTP headers

#32

Post by [deleted] » Tue, Jun 26, 2012, 2:25 PM UTC

krakensden wrote: post #11

raldi wrote: post #9

Earlier quoted context omitted.

Could you explain the reference in your first paragraph?

Open tuxgames.com with the Chrome Inspector or Firebug on, and look at the reply headers. They have an unusual one: X-Subliminal:You want to buy as many games as you can afford

[deleted]

Re: "X-" deprecated for HTTP headers

#33

Post by mildweed » Tue, Jun 26, 2012, 3:02 PM UTC

So, now we in the community need a clearinghouse to declare new HTTP headers. Let me be the first: Comment.

Re: "X-" deprecated for HTTP headers

#34

Post by bzbarsky » Tue, Jun 26, 2012, 3:40 PM UTC

lloeki wrote: post #12

natrius wrote: post #6

Next stop: CSS vendor prefixes.

Not. How would you handle the case of pre-standard implementations? Like: -webkit-gradient( , [, ]?, [, ]? [, ]*) vs: -moz-linear-gradient([ [ [top | bottom] || [left | right] ],]? [, ]+); which eventually became: linear-gradient( [ [ | to ,]? [, ]+ ) In CSS, the vendor prefixes are exactly what we need. They help bootstrapping, discussing, and proofing standards by having pre-standard implementations in the wild. CS…

In this particular case, handling the pre-standard implementations would have been trivial because they all have different syntax. So you'd just write them all in there, and the ones that don't apply in the UA in question would just fail to parse and get dropped.

Re: "X-" deprecated for HTTP headers

#35

Post by regularfry » Tue, Jun 26, 2012, 4:07 PM UTC

tszming wrote: post #31

regularfry wrote: post #15

Earlier quoted context omitted.

You can have pre-standard implementations without vendor prefixes. Here's an argument against them: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html And here's some further discussion: http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html Personally I think vendor prefixes are an awful hack. We've already got browser-conditional comments in HTML, why not use them? Hell, browser-sp…

>> We've already got browser-conditional comments in HTML You mean the `conditional statements` introduced and only used by IE? http://en.wikipedia.org/wiki/Conditional_comment

Yep. It's a better plan than vendor prefixes.

Edited to clarify: I mean that browser-conditional comments should be implemented across browsers, not that we should rely on features already implemented.