The Crazy World of HTML5
 

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

Re: The Crazy World of HTML5
 

In article <jqpp3f$ri4$1@dont-email.me>,
Tim W <tim.wnosp@mtavirgin.net> 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

Re: The Crazy World of HTML5
 

On 07/06/2012 11:08, dorayme wrote:
> In article<jqpp3f$ri4$1@dont-email.me>,
> Tim W<tim.wnosp@mtavirgin.net> 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

Re: The Crazy World of HTML5
 

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/

Re: The Crazy World of HTML5
 

In article <4fd0787b$0$6142$426a74cc@news.free.fr>,
"mayeul.marguet" <mayeul.marguet@free.fr> wrote:

> On 07/06/2012 11:08, dorayme wrote:
> > In article<jqpp3f$ri4$1@dont-email.me>,
> > Tim W<tim.wnosp@mtavirgin.net> 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

Re: The Crazy World of HTML5
 

On 08/06/2012 07:36, dorayme wrote:
> In article<4fd0787b$0$6142$426a74cc@news.free.fr>,
> "mayeul.marguet"<mayeul.marguet@free.fr> wrote:
>
>> On 07/06/2012 11:08, dorayme wrote:
>>> In article<jqpp3f$ri4$1@dont-email.me>,
>>> Tim W<tim.wnosp@mtavirgin.net> 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

Re: The Crazy World of HTML5
 

Tim W wrote:
> On 08/06/2012 07:36, dorayme wrote:
>> In article<4fd0787b$0$6142$426a74cc@news.free.fr>,
>> "mayeul.marguet"<mayeul.marguet@free.fr> wrote:
>>
>>> On 07/06/2012 11:08, dorayme wrote:
>>>> In article<jqpp3f$ri4$1@dont-email.me>,
>>>> Tim W<tim.wnosp@mtavirgin.net> 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

Re: The Crazy World of HTML5
 

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

Re: The Crazy World of HTML5
 

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

Re: The Crazy World of HTML5
 

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