-1

According to one of the answer for "Why do browsers create vendor prefixes for CSS properties?", one of the reason why vendor prefix is needed is to avoid breaking page even if the final specification of a property is different from the implementation(interpretation) of a vendor.

I read a book which says it is generally a good practice to put property without vendor prefix after vendor prefixed property declarations, as shown below:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    -o-hyphens: auto;
    hyphens: auto;
}

Let's say that finalized specification of hyphens is different from the interpretation of vendors. If somebody developed a webpage which depends on some vendor prefixed implementations, won't the page's design break because, as I have assumed, "hyphens" specification is different from the vendors'? If the interpretations are the same as the finalized specification, I think the code above is fine. Why is the code above generally a good practice?

Community
  • 1
  • 1
hitochan
  • 1,028
  • 18
  • 34

2 Answers2

2

The code snippet you provided is considered a good practice because it is (hopefully) forward and backward compatible...

Basically with a non-standard implementation each browser may implement the property a little differently hence the prefixes. If all goes well, eventually the different browsers will standardize the property and will (hopefully) render it the same way.

The prefixed versions will work for the time being and (hopefully) by the time the browsers standardize the property and remove the prefix the non-prefixed version will work.

I know the seeing "hopefully" above isn't that encouraging, if you want your CSS to be bullet proof, don't use the new properties until they're standardized or design your stuff to degrade gracefully.

Some css3 properties, like border-radius, are somewhat standardized and will render properly without the prefix, but not every internet user keeps their browser up to date, so it may be a good idea to continue to use the prefix for a while.

On the other hand there are some properties that Firefox will render without a prefix that Chrome will not, like animation and @keyframes. In this case using the prefixed version followed by the non-prefixed version makes perfect sense.

.myClass {
  position: relative;
  -webkit-animation: myAnimation 3s; /* Chrome will use this */
  animation: myAnimation 3s; /*Firefox will ignore the -webkit- property and use this */
}
@-webkit-keyframes myAnimation { /* Chrome will use this */
  from {
    background: red;
    top: 10px;
  }
  to {
    background: blue;
    top: 100px;
  }
}
@keyframes myAnimation { /*Firefox will ignore the -webkit- property and use this */
  from {
    background: red;
    top: 10px;
  }
  to {
    background: blue;
    top: 100px;
  }
}
<div class="myClass">Hello World</div>

Try the above snippet in both Firefox and Chrome to see what I'm talking about.

apaul
  • 16,092
  • 8
  • 47
  • 82
  • Thank you for answering. I am actually really confused now because, in my opinion, i think it is possible to use non-prefixed version even if a property has not been standardized yet. Why not just use non-prefixed version even if it is not standardized? – hitochan Feb 05 '15 at 04:27
  • Each browser uses an engine for rendering( WebKit for safari and chrome, and so on), right? So even if there is no vendor prefixed properties which haven't been standardized yet, doesn't each browser know how to render the property? – hitochan Feb 05 '15 at 07:15
  • Thank you very much for your detailed answer. I was wondering why chrome didn't choose to implement `@keyframes` and `animation` instead of the prefixed ones because it will save a lot of codes. – hitochan Feb 05 '15 at 16:10
  • 2
    @hitochan All the browsers that supported these properties did so with a prefix in the beginning, it wasn't until a good while later that Firefox removed the prefix... The prefix allows developers to use them while the individual browsers are still working on the final implementation. – apaul Feb 05 '15 at 16:14
  • 1
    @hitochan For instance just recently Chrome dropped the prefix for css3 transforms, but Firefox had dropped it a long time before them and the code I wrote back then still works because I included both the prefixed version and the non-prefixed version. – apaul Feb 05 '15 at 16:17
  • 1
    I really appreciate your patience with bunch of elementary questions. I think now I have finally cleared my doubts. – hitochan Feb 05 '15 at 16:33
0

The code above is good practice because of CSS's overidding feature.

In this way you give the browser the possibility to check if it has a specific vendor-prefix (modern browsers generally don't need it but it's good when supporting older versions) and at last you have a general (catch-all) property;

if the browser doesn't recognize any of the property types it will just ingnore it...

maioman
  • 18,154
  • 4
  • 36
  • 42
  • What if a web page looks fine only with vendor prefixed version, not with general property? i think because of the overriding feature, the page will not show correctly. – hitochan Feb 04 '15 at 10:48
  • i mean, what will happen if it recognize both properties. And the two implementations are different. – hitochan Feb 04 '15 at 11:22