W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] Handling <title> inside <body>

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 11 Nov 2008 20:35:11 -0800
Message-ID: <c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com>
On Mon, Nov 10, 2008 at 7:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:


>
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>>
>> From an implementors point of view, it's good to have clearly defined
>> boundaries between modules. An implementation would typically have one
>> module that tokenises and parses html and one module that renders the
>> resulting dom to the screen. If all the unexpected input is dealt with
>> in the parsing module, then you can make some assumptions in the
>> rendering module which can greatly simplify the implementation. Having
>> to deal with an arbitrary amount of illegal input in either module is,
>> IMHO, not the ideal design.
>
> Unfortunately, we have little choice in the matter. Scripting and XML both
> allow you to unambiguously create highly non-conforming DOMs, e.g. with
> <title> elements as the root element and <html> elements as children of
> <input> elements. The renderer has to deal with all such DOMs.
>

What does XML has to do with any of this?

A script that adds an HTML element to a INPUT element should cause an
hierarchy exception to be raised.

You have a choice:

1)  leave DOM 1 alone; let the implementation throw an hierarchy exception.
2)  make a standardized behavior for this case.

| Since user agents may vary in how they handle error conditions,
authors and users
| must not rely on specific error recovery behavior.

http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs

Garrett

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Tuesday, 11 November 2008 20:35:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC