The Crazy World of HTML5

[Tim W]

The manual I am using for learning HTML5 goes on and on about the mad,
mad browser compatibility issues and the necessity to write a piece of
markup several times over to make sure it is understood. For instance,
box shadow in the css should be:

-webkit-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
-moz-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
box-shadow: 2px 5px 0 0 rgba(72,72,72,1);

But the code is the same for all three! What for pity's sake, is the point?

Tim W

 

[dorayme]

The manual I am using for learning HTML5 goes on and on about the mad,
mad browser compatibility issues and the necessity to write a piece of
markup several times over to make sure it is understood. For instance,
box shadow in the css should be:

-webkit-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
-moz-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
box-shadow: 2px 5px 0 0 rgba(72,72,72,1);

But the code is the same for all three! What for pity's sake, is the point?

Because, so far, the different browsers have not got on board to the
HTML5 moving train but happen to have had their own ways to satisfy
old popular needs. As the train moves around the world a few times,
the browsers will become more consistent. Patience!

 

[mayeul.marguet]

Because, so far, the different browsers have not got on board to the
HTML5 moving train but happen to have had their own ways to satisfy
old popular needs. As the train moves around the world a few times,
the browsers will become more consistent. Patience!

Technically in this case and many cases, the point of prefixes is that
the agreed upon conventions are not finalized yet and might need to
change before finalization.
Therefore if someone were to develop for them now, the design might
break early as the conventions change and the browsers implement the new
ones.

The prefixes are supposed to:
- Show off the future features by making it possible to build prototypes
with them.
- Make developers aware of the situations and its risks.
- Lower the risks of breaking whatever was built. If there was a change,
browsers are free to accept multiple syntaxes in their prefixed properties.

Personnally I'd prefer some sort of versioned properties based on the
date of published drafts & candidates, but hey, got its problems too.

 

[Jukka K. Korpela]

The manual I am using for learning HTML5 goes on and on about the mad,
mad browser compatibility issues and the necessity to write a piece of
markup several times over to make sure it is understood. For instance,
box shadow in the css should be:

-webkit-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
-moz-box-shadow: 2px 5px 0 0 rgba(72,72,72,1);
box-shadow: 2px 5px 0 0 rgba(72,72,72,1);

That's not markup, and not HTML at all, but hey, everyone wants to make
money out of HTML5 and calls HTML5 anything that serves the purpose! I'm
not innocent either; I've authored a book on HTML5, and surely some
picky character (like me) could easily point out topics there that just
aren't HTML5, or HTML at all.

More seriously, the code above is CSS, in a loose sense: a property
proposed in CSS3, more specifically "CSS Backgrounds and Borders Module
Level 3", and some proprietary properties supposed to do the same thing.

But the code is the same for all three! What for pity's sake, is the point?

The point was, as Mayeul describes in his answer, to allow experimental
implementations in browsers, for features that have not been decided on
yet. If you use -moz-box-shadow, you can expect Mozilla browsers to
interpret in certain ways and other browsers to ignore it. Using
-webkit-box-shadow, you can expect some other browsers do something
similar, but not necessarily identical. And using box-shadow only, you
are effectively telling browsers to do the shadowing whenever they feel
confident to support the property as defined in a "standard".

But maybe it wasn't such a good idea after all. At least many people
think so. I just read a discussion forum posting that complains about
some Firefox 13 change that made a -moz-... property dysfunct. But it
was really the idea that such "vendor prefix" properties be dropped when
the property becomes mature. And Candidate Recommendation status, which
is what CSS Backgrounds and Borders Module Level 3 has now, is rather
mature. It basically means that fine-tuning and clarification process
will go on, but substantial changes are not expected and browser vendors
are encouraged to implement the new features.

And I checked that Firefox 13, which really installed herself without
letting me interfere much, does not recognize -moz-box-shadow any more,
but it recognizes the standard (for a suitable loose meaning for
"standard") property name box-shadow.

The morale? If you wish to use new properties, use the "standard" names
_and_ use tools like CSSPrefixer http://cssprefixer.appspot.com to
generate the additional vendor-prefixed rules for you.

Or, alternatively, use just the "standard" names and allow for some more
months or years for delivery of browser support.

 

[dorayme]

Technically in this case and many cases, the point of prefixes is that
the agreed upon conventions are not finalized yet and might need to
change before finalization.

Yes, good point. As are your below.

 

[Tim W]

Yes, good point. As are your below.

If say the Mozilla Empire decided they wanted an improved syntax for box
shadows what possible benefit could there be in having already written
out the code three times over with the old syntax?

Tim W

 

[Neil Gould]

If say the Mozilla Empire decided they wanted an improved syntax for
box shadows what possible benefit could there be in having already
written out the code three times over with the old syntax?

I suspect that the purpose of having multiple versions of the specifications
for the box-shadow is to accommodate changes in one browser; in your
example, if Mozilla changed the behavior of their browser it might still be
possible to make a page appear similarly by changing the -moz-box-shadow
specification and leaving the others intact. This is the same quandry as
CSS2, really.

 

[Gus Richter]

That's not markup, and not HTML at all, but hey, everyone wants to make
money out of HTML5 and calls HTML5 anything that serves the purpose! I'm
not innocent either; I've authored a book on HTML5, and surely some
picky character (like me) could easily point out topics there that just
aren't HTML5, or HTML at all.

More seriously, the code above is CSS, in a loose sense: a property
proposed in CSS3, more specifically "CSS Backgrounds and Borders Module
Level 3", and some proprietary properties supposed to do the same thing.


The point was, as Mayeul describes in his answer, to allow experimental
implementations in browsers, for features that have not been decided on
yet. If you use -moz-box-shadow, you can expect Mozilla browsers to
interpret in certain ways and other browsers to ignore it. Using
-webkit-box-shadow, you can expect some other browsers do something
similar, but not necessarily identical. And using box-shadow only, you
are effectively telling browsers to do the shadowing whenever they feel
confident to support the property as defined in a "standard".

But maybe it wasn't such a good idea after all. At least many people
think so. I just read a discussion forum posting that complains about
some Firefox 13 change that made a -moz-... property dysfunct. But it
was really the idea that such "vendor prefix" properties be dropped when
the property becomes mature. And Candidate Recommendation status, which
is what CSS Backgrounds and Borders Module Level 3 has now, is rather
mature. It basically means that fine-tuning and clarification process
will go on, but substantial changes are not expected and browser vendors
are encouraged to implement the new features.

And I checked that Firefox 13, which really installed herself without
letting me interfere much, does not recognize -moz-box-shadow any more,
but it recognizes the standard (for a suitable loose meaning for
"standard") property name box-shadow.

The morale? If you wish to use new properties, use the "standard" names
_and_ use tools like CSSPrefixer http://cssprefixer.appspot.com to
generate the additional vendor-prefixed rules for you.

Or, alternatively, use just the "standard" names and allow for some more
months or years for delivery of browser support.

<http://hsivonen.iki.fi/vendor-prefixes/>

 

[Gus Richter]

<http://hsivonen.iki.fi/vendor-prefixes/>

I would just like to point out that one should also read all the links
which are comments/opinions in order to get well rounded on the subject.

I would also like to make a few other comments:

1. The idea is for the Vendors to use their prefix until their support
of the property is fully supported and/or the property is at CR by W3C
or obviously to be very near CR.
2. I believe that the idea 'is/should be' that once the Vendor supports
the property w/o the prefix, then the prefixed property support by the
Vendor should no longer be supported by the Vendor.
3. I'm not really sure if all the Vendors do drop support for the
prefixed version once they support the un-prefixed version.
4. Some, if not all, Vendors submit demo examples with only their prefix
properties. These make competing Vendors appear to not be supporting
that property, although they may also have their prefixed property
support available.
5. Some authors also use 'only' that one particular Vendor's prefix
property in their authored pages, w/o the other Vendor(s) prefixed
version, nor with the un-prefixed version.
6. Once the (some?) Vendor(s) supports the un-prefixed version, they may
continue to support their prefixed version in order to support the then
otherwise broken pages created by themselves and those created by authors.
7. This has led some Vendors to talk about and already supporting
competitive Vendors' prefixed versions. This (3. - 7.) IMHO is leading
to further confusion and problems.

I believe that a system of having all Vendors build into their browsers
a timed support for their prefixed versions, let's say for a year,
whereafter their browser will no longer support it. If necessary, they
could reenter another 1-year time bomb for that prefixed property if
they are not ready for the un-prefixed version support. Once they
support the un-prefixed version support, the prefixed support will cease
after a certain time. This will make all authors (vendor and general web
page authors) take care to include un-prefixed versions after the
prefixed one.

Of course, it still will leave the problem during the prefixed period(s)
where other Vendors' prefixed versions are not included in the authored
web pages. One way to resolve this issue would be to get rid of the
present Vendor prefix system and use a generic -x- prefix for all Vendors.

Just some thoughts.

 

[Gus Richter]

I would just like to point out that one should also read all the links
which are comments/opinions in order to get well rounded on the subject.

I would also like to make a few other comments:

1. The idea is for the Vendors to use their prefix until their support
of the property is fully supported and/or the property is at CR by W3C
or obviously to be very near CR.
2. I believe that the idea 'is/should be' that once the Vendor supports
the property w/o the prefix, then the prefixed property support by the
Vendor should no longer be supported by the Vendor.
3. I'm not really sure if all the Vendors do drop support for the
prefixed version once they support the un-prefixed version.
4. Some, if not all, Vendors submit demo examples with only their prefix
properties. These make competing Vendors appear to not be supporting
that property, although they may also have their prefixed property
support available.
5. Some authors also use 'only' that one particular Vendor's prefix
property in their authored pages, w/o the other Vendor(s) prefixed
version, nor with the un-prefixed version.
6. Once the (some?) Vendor(s) supports the un-prefixed version, they may
continue to support their prefixed version in order to support the then
otherwise broken pages created by themselves and those created by authors.
7. This has led some Vendors to talk about and already supporting
competitive Vendors' prefixed versions. This (3. - 7.) IMHO is leading
to further confusion and problems.

I believe that a system of having all Vendors build into their browsers
a timed support for their prefixed versions, let's say for a year,
whereafter their browser will no longer support it. If necessary, they
could reenter another 1-year time bomb for that prefixed property if
they are not ready for the un-prefixed version support. Once they
support the un-prefixed version support, the prefixed support will cease
after a certain time. This will make all authors (vendor and general web
page authors) take care to include un-prefixed versions after the
prefixed one.

Of course, it still will leave the problem during the prefixed period(s)
where other Vendors' prefixed versions are not included in the authored
web pages. One way to resolve this issue would be to get rid of the
present Vendor prefix system and use a generic -x- prefix for all Vendors.

Just some thoughts.

Pertaining to the same general thought & problem, I find this quote by
glazou on Wednesday 6 June 2012, 18:40

<http://www.glazman.org/weblog/dotclear/index.php?category/CssAndStyle>

 

[Gus Richter]

Pertaining to the same general thought & problem, I find this quote by
glazou on Wednesday 6 June 2012, 18:40

<http://www.glazman.org/weblog/dotclear/index.php?category/CssAndStyle>

Pre FF 8 the properties mentioned below had support for -moz- versions
only. FF 8 provided unprefixed support for these two properties. Now, 5
versions later, FF 13 has the prefixed version support removed:

Firefox 13 for developers: Support for -moz-border-radius* and
-moz-box-shadow has been removed. Authors should use unprefixed
border-radius or box-shadow instead. See bug 693510
<https://bugzilla.mozilla.org/show_bug.cgi?id=693510>

IF prefixed versions are used by authors, although they should not be
used in production, they should, at least, also use the unprefixed version.