[whatwg] SPOOFED: Re: SPOOFED: Re: ---

[Eduard Pascual]

On Wed, Nov 5, 2008 at 8:47 PM, Philipp Serafin <phil127 at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 4:00 PM, Leons Petrazickis
> <leons.petrazickis at gmail.com> wrote:
>> It matters in the sense that web browsers would have to implement both
>> approaches for backwards compatibility.
>>
>
> This depends what you mean when talking about "implementing" a tag.
> Browsers already load all tags and attributes they encounter into the
> page DOM today , regardless if they "know" them or not. This is also
> the behavior that HTML5 demands, if I'm not mistaken.
I have just put a sample file together, and checked it on what I have available:
On Dreamweaver (CS3) and FF3, it is rendered perfectly.
On IE7 and Microsoft's Visual Web Developer 2008 Express SP1, it
ungracefully degrades, as I expected: they ignore the entire
<reference> tag, so neither the default styles defined for the tag nor
the specific classes are displayed. I also included title attributes,
for fancy tooltip effects, and they show perfectly on FF; IE of course
doesn't show them because they are part of the ignored <reference>
tag.
And, of course, both authoring tools make a mention of <reference> not
being valid... but that was something that could be expected :P

I tried to test this on IE8beta2, but the instalation is failing ¬¬'.
Would MS be so kind to do something that doesn't break? Thanks.
Sarcasms aside, if somebody wants to give this sample a try on other
browsers, I've put it online at
http://herenvardo.googlepages.com/test.html. Note that I have
deliberatelly abused of styling to make the result stand out (ie: to
easily see whether it works or not). Use your browser's "View source"
features to get an idea of what to expect.

>>Standards that have tried to make changes like that -- XHTML2 comes to
>>mind -- have not been as successful as HTML4 [...]
>
> We can't really make any statements about how successful XHTML2 would
> be on the public web. It's not yet a recommendation (though this would
> probably not change much) and no browser implemented it, so there was
> never opportunity to find out.
And even so it's being used sporadically :P
In addition, this case can't be compared with XHTML2: it'd give the
authors a choice, since <abbr> and similar elements would still be
supported, for backwards compatibility.

> But anyway, this discussion is moot, since many of those tags can't be
> changed due to backwards compatibility.
Actually, it isn't: <abbr> doesn't need to be kept more than <big> of
<font> do for the compatibility issue. The spec needs to define how to
handle all of those anyway; but it isn't really tied on what does it
define as "conformant" and "non-conformant".

Now, going back to Pentasis's actual concern: authoring content in a
way that makes sense. Just go ahead: it seems that browsers that deal
with "unknown" elements in an HTML5-conformant way will handle it
properly, as long as you provide some rendering info in your
style-sheets. You don't really need this spec to "define" that
element, as long as it works on browsers; and the spec will still
require browsers to process it in a reasonable way (ie: include in the
DOM, apply relevant styles, and hopefully even apply global attribs
like @class or @title). So, essentially, including an element like
<reference> or not is, from the browser's viewpoint, irrelevant: their
required behavior will be exactly the same either way. On the author's
side, it will only be relevant for authors that care about conformity
and need the element, in which case it will be good to have it
available. Of course, it requires a bit of extra work by the WG, to
describe it in the spec (what would it be, one paragraph?). Validators
may face some extra work, but I don't think anyone with a bit of
sanity left would hardcode each element in the validators, but instead
use some DTD-like description of the syntax and/or content model, so
it isn't really that much work. And finally, on the assistive
technologies' and search engines' side, this kind of elements would
allow to describe the contents of webpages far better, which would be
a clear benefit.

So, in summary, there are some benefits for including this kind of
elements; and there is any relevant backward (just a bit of extra,
trivial work for spec and validator writters). Some benefits, and no
*real* issues, the only plausible reason to not include this would be
a desire to hurt the web (which, BTW, some XHTML2 evangelists out
there think is the only goal of the WG). Can somebody put forward any
technical argument against this idea? If somebody does, I'd be glad to
discuss them seriously; but please think if what you're going to say
at least makes sense: don't come up with the "implementation issue"
(the inclusion of this kind of elements wouldn't require from
implementations anything that the spec doesn't already require) or the
"backwards compatibility thing" (the inclusion of new element never
affects how other elements should be treated); I've better things to
spend my time on than needlessly looping and replying to the same void
fallacies once and again.