Re: Re-registration of text/html

Tab Atkins Jr., Wed, 24 Feb 2010 23:37:50 -0600:
> On Wed, Feb 24, 2010 at 7:23 PM, Leif Halvard Silli
>> Tab Atkins Jr., Wed, 24 Feb 2010 17:00:56 -0600:
>>> On Wed, Feb 24, 2010 at 8:45 AM, Leif Halvard Silli:
>>>> The problem that I see is that HTML5 defines a parser and that the
>>>> current version of the HTML5 spec draft says that the HTML5 parser
>>>> should ignore the @profile attribute.
>>> 
>>> Not quite.  [...]
>> 
>> Right, it says: ]] User agents SHOULD ignore … [[
> 
> That's not at all what I meant.[…]appeared that you thought it meant
> that @profile would be skipped over entirely and wouldn't appear in
> the DOM, when it really just means that no special behavior will be
> attached to it).

I have used Live DOM Viewer enough to know that it doesn't disappear 
from the DOM. I did not anticipate that you thought otherwise. I meant 
"ignore" in the sense "not use it for anything". I pointed out that the 
spec says "should" in order to express that I perhaps took the "ignore" 
too far. (But I now see that you thought that I took it even further 
...) 
 
>>>> There quite a few similar issues. E.g. HTML4 supports image maps were
>>>> one uses <a> instead of <area> - HTML5 does not have this feature
>>>> (currently) - and I heard from Boris and Anne that they would be so
>>>> happy to remove that feature from their respective browsers. @summary,
>>>> @longdesc etc belongs to the same set of issues.
>>>> 
>>>> So the concrete problem is the parser - that HTML5 blesses removal of
>>>> features that are important to handle HTML4 documents.
>>> 
>>> The whole reason we remove  these sorts of things is because they
>>> *aren't* important for HTML4 documents.
>> 
>> But we do not define HTML4. We define HTML5. ;-) And thus: not
>> everything that (according to a counting of its use) "aren't important
>> for HTML4 documents", have been removed in HTML5.
>> 
>> In a situation where the mantra is that elements are better than
>> attributes, then it seems meaningless to remove the possibility to use
>> <a> instead of <area>.
> 
> I don't understand what you are talking about here, or how it relates
> to what you originally said or I responded with.

Well, may be, if you read the conversion without the anticipation that 
I thought profile would disappear from the DOM, that you would come to 
another conclusion.

@coords of course doesn't disappear from the DOM, when it is used 
inside <A>. But if Opera and Firefox remove the code that actually do 
something with @coords, when used inside <a>, then it is of little use 
that it doesn't disappear.

>>>  When something is undesirable
>>> and only an insignificant number of pages use it, it's fairly safe to
>>> remove.  If a significant number of pages depended on it, it would be
>>> useless to remove it from the spec, as browsers would still have to
>>> implement it to handle existing content.
>> 
>> This way "we" also remove things, de facto, from HTML4. When will HTML5
>> become a standard? No one knows. In the mean time, what should one do?
>> No one will strive to implement HTML4 better this way.
> 
> No one *is* striving to implement HTML4 better, except insofar as they
> have bugs filed against them that they want to fix for web compat.
> They can typically resolve those bugs by following HTML5, though, and
> when HTML5 doesn't yet address an issue they bring it up so that the
> change can be added.

I think we must at least classify Internet Explorer 8 as an attempt to 
implement HTML4 much better. 

>>>>> Do you believe in ever obsoleting specs? Does your concern about
>>>>> HTML4 extend to HTML 2.0? If not, why not?
>>>> 
>>>> Except for the very doctypes themselves of those specs, are there
>>>> things in HTML32 and HTML2 that did not make it to HTML4?
>>> 
>>> Yes.  For example, just looking at the list of specified elements, you
>>> can see that <xmp> and <listing> were present in HTML2 but not in
>>> HTML4.01.  There are several more elements that still officially exist
>>> but have no effect, such as <nextid>, such that if any documents *did*
>>> depend on their functionality, they would be broken by a UA
>>> implementing the spec.
>> 
>> OK. Hopefully HTML4 replace their functionality with better things.
>> That is not the case w.r.t. <area>.
> 
> What functionality is lost?  Is this useful functionality?  If it
> serves a valuable use-case, then it shouldn't be dropped.  Can you
> express such a use-case?

(Will answer in separate thread.)
-- 
leif halvard silli

Received on Thursday, 25 February 2010 07:15:33 UTC