The Crazy World of HTML5

Discussion in 'HTML' started by Tim W, Jun 7, 2012.

  1. Tim W

    Tim W Guest

    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
    Tim W, Jun 7, 2012
    #1
    1. Advertising

  2. Tim W

    dorayme Guest

    In article <jqpp3f$ri4$>,
    Tim W <> wrote:

    > 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!

    --
    dorayme
    dorayme, Jun 7, 2012
    #2
    1. Advertising

  3. On 07/06/2012 11:08, dorayme wrote:
    > In article<jqpp3f$ri4$>,
    > Tim W<> wrote:
    >
    >> 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!


    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.

    --
    Mayeul
    mayeul.marguet, Jun 7, 2012
    #3
  4. 2012-06-07 11:34, Tim W wrote:

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

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Jun 7, 2012
    #4
  5. Tim W

    dorayme Guest

    In article <4fd0787b$0$6142$>,
    "mayeul.marguet" <> wrote:

    > On 07/06/2012 11:08, dorayme wrote:
    > > In article<jqpp3f$ri4$>,
    > > Tim W<> wrote:
    > >
    > >> 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!

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

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


    --
    dorayme
    dorayme, Jun 8, 2012
    #5
  6. Tim W

    Tim W Guest

    On 08/06/2012 07:36, dorayme wrote:
    > In article<4fd0787b$0$6142$>,
    > "mayeul.marguet"<> wrote:
    >
    >> On 07/06/2012 11:08, dorayme wrote:
    >>> In article<jqpp3f$ri4$>,
    >>> Tim W<> wrote:
    >>>
    >>>> 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!

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

    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
    Tim W, Jun 8, 2012
    #6
  7. Tim W

    Neil Gould Guest

    Tim W wrote:
    > On 08/06/2012 07:36, dorayme wrote:
    >> In article<4fd0787b$0$6142$>,
    >> "mayeul.marguet"<> wrote:
    >>
    >>> On 07/06/2012 11:08, dorayme wrote:
    >>>> In article<jqpp3f$ri4$>,
    >>>> Tim W<> wrote:
    >>>>
    >>>>> 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!
    >>> 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.
    >>
    >>> 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.
    >>>

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

    --
    best regards,

    Neil
    Neil Gould, Jun 8, 2012
    #7
  8. Tim W

    Gus Richter Guest

    On 6/7/2012 6:21 AM, Jukka K. Korpela wrote:
    > 2012-06-07 11:34, Tim W wrote:
    >
    >> 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.



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

    --
    Gus
    Gus Richter, Jun 9, 2012
    #8
  9. Tim W

    Gus Richter Guest

    On 6/8/2012 7:51 PM, Gus Richter wrote:
    >
    > <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
    Gus Richter, Jun 9, 2012
    #9
  10. Tim W

    Gus Richter Guest

    On 6/8/2012 10:50 PM, Gus Richter wrote:
    > On 6/8/2012 7:51 PM, Gus Richter wrote:
    >>
    >> <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.



    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
    Gus Richter, Jun 9, 2012
    #10
  11. Tim W

    Gus Richter Guest

    On 6/9/2012 6:15 AM, Gus Richter wrote:
    > On 6/8/2012 10:50 PM, Gus Richter wrote:
    >> On 6/8/2012 7:51 PM, Gus Richter wrote:
    >>>
    >>> <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.

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

    --
    Gus
    Too much stuff in the wrong newsgroup - sorry.
    Gus Richter, Jun 10, 2012
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vijay
    Replies:
    8
    Views:
    705
  2. Robert Jones

    html5 vs xhtml2

    Robert Jones, Dec 2, 2007, in forum: HTML
    Replies:
    16
    Views:
    834
    Bergamot
    Dec 14, 2007
  3. n0ctis

    HTML5 vs. XHTML

    n0ctis, Aug 15, 2008, in forum: HTML
    Replies:
    4
    Views:
    1,295
    SpaceGirl
    Aug 18, 2008
  4. Hans-Peter Diettrich
    Replies:
    2
    Views:
    434
    Hans-Peter Diettrich
    Aug 22, 2008
  5. Larry
    Replies:
    27
    Views:
    424
    Michele Dondi
    Jan 25, 2005
Loading...

Share This Page