Re: Re-registration of text/html

On Wed, Feb 24, 2010 at 7:23 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.  You got the "should" part correct in
your email.  The part you got wrong was "parser" as opposed to "user
agent", and you seemed to have an incorrect assumption about what
"ignore" meant in that context (it 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).

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

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

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

~TJ

Received on Thursday, 25 February 2010 05:38:39 UTC