5

This answer really made me wonder.

I've written CSS before and (usually) I don't really bother to support browsers other than recent firefox and chrome, but in researching I've noticed that, for the exact same CSS property, there are usually at least three different forms which behave identically, and can have the same values, but which all simply have different prefixes for the specific library that implements them.

Here, for example:

-webkit-touch-callout: none;
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;

With the sole exception of the first one, these only differ by prefix. Why don't maintainers simply change the lexer rule which matches the string "-moz-user-select" to also match "user-select"? Sure, there's the possibility that the author of the original CSS wanted different behavior for Firefox v. other browsers, so "user-select" won't be the same as "-moz-user-select", but the risk of that weird corner case is far outweighed by the advantage, and there are other, arguably better ways to accomplish the browser-specific goal.

If this is already occurring, why do people still use all of these? If they stopped:

  • there would be fewer bits clogging the metaphorical pipes of the internet (network latency would go way down, plus individual pages would load faster), and
  • people using ancient browsers would be given the impetus they need to update (which they should do for security reasons, anyway)

TL;DR

What would the disadvantage be of everyone using the same naming convention? Why haven't things normalized by now?

Improve this question
7
  • There are no attributes in CSS. (There are attribute selectors, but that’s a different issue.) What you are trying to ask is just “why are there vendor-prefixed versions for CSS properties?” This is a broad question and partly a matter of opinions. In particular, user-select was once part of a working draft, now withdrawn, so what you are seeing is just browser-specific properties with no definitions beyond those that each vendor might provide (in some format, usually in informal and inexact language).
    – Jukka K. Korpela
    Jul 28, 2014 at 19:04
  • @JukkaK.Korpela Thanks. I did mean property. I knew there was something off in there... Fixed it, anyway.
    – Parthian Shot
    Jul 28, 2014 at 19:08
  • If you are worrying about bandwidth, then consider that text uses a lot less bandwidth compared with video, audio or pictures. Also with compression, as there is a lot of similarity in all 6 cases it will use even less, so make sure your server supports compression (and caching).
    – ctrl-alt-delor
    Jul 28, 2014 at 19:16
  • @richard Good points. Although one of the issues is that, if a website whose traffic routes through the same node as mine doesn't use compression and tries for cross-browser compatibility by offloading to a comparatively enormous library that touts itself as abstracting away browser-specific issues, traffic to their site strangles traffic to mine.
    – Parthian Shot
    Jul 28, 2014 at 19:25
  • 1
    Some browser makers are moving away from prefixes. chromium.org/blink#vendor-prefixes
    – Cyanfish
    Jul 28, 2014 at 19:36

1 Answer 1

Reset to default
12

Most of these are due to vendor prefixes.

A new standard that has not been finalized may get implemented in a browser, but since it has not been finalized, the browser vendor (creator) will not want to use the "official" correct attribute, but they still want to support the feature.

So they add a prefix - -webkit-*, -moz-*, -khtml- and -ms-* are specific to the different browsers/rendering engines.

And as a developer, while browsers gain support but don't yet use the "official" name, you may want to support the feature - so you add the vendor prefixes and the official one for future proofing.

Sometimes a feature changes name during the standardization process, so you end up with a vendor prefix using a different name, or having two different names for the same feature (normally in different browser versions of the same rendering engine).

Why haven't things normalized by now?

New standards are being worked on and getting finalized all the time. Different vendors have different priorities on which vendors they want to support. So - a moving target + different priorities, gives you... vendor prefixes and no single standard name at one point in time.

Improve this answer
16
  • 1
    I suppose the question that leaves me with then is "why is there pressure on the library authors to prematurely release features which haven't been standardized yet, thereby cluttering the namespace?"
    – Parthian Shot
    Jul 28, 2014 at 19:11
  • @ParthianShot - what library authors? Browser creators want to support the latest and greatest (thought their definitions of greatest vary).
    – Oded
    Jul 28, 2014 at 19:13
  • 1
    They use there own name, because the standard is not finalised, the standard can change. By using the standards name incorrectly or before finalisation, they will be out of compliance.
    – ctrl-alt-delor
    Jul 28, 2014 at 19:22
  • 2
    @ParthianShot It's not a good marketing strategy. It is probably the main reason for MS losing ground in browser share, a minor reason for MS losing ground in other markets, and the primary reason web developers hate MS. It is probably a factor behind Ballmer's resignation. As a strategy, it only works for as long as you maintain a strong competitive edge over every other company. The moment that edge drops, it works heavily against you. It's also (arguably) unethical and stupid.
    – Trixie Wolf
    Jul 28, 2014 at 19:55
  • 1
    @ParthianShot Yeah, this comic exists for a reason...
    – Izkata
    Jul 29, 2014 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.