[whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

Simon Pieters simonp at opera.com
Wed Mar 6 10:06:55 PST 2013


On Wed, 06 Mar 2013 18:55:27 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 6 Mar 2013, Simon Pieters wrote:
>> On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen <hsivonen at iki.fi>  
>> wrote:
>>
>> > Would it be terrible to make attempts to mutate the 'is' attribute
>> > throw thereby teaching authors who actually try to mutate it that it's
>> > not mutable?
>>
>> We already have several attributes that are immutable but don't throw or
>> anything when they're changed.
>>
>> e.g. <script src>, <html manifest>.
>>
>> In the case of manifest, we omitted the IDL attribute to signal that it
>> shouldn't be changed.
>>
>> As another example, <input type> was immutable in old IE and that made
>> people think of it as immutable.
>
> I think the content attributes should always be mutable, for consistency
> and to avoid unexpected crashes in code that just tries to set every
> attribute indiscriminately. (Much like how the DOM tree needs to be a  
> real
> tree, not a graph, so that code can walk it without fear of loops.)
>
> It's ok to have attributes that set some other variable that is itself
> immutable, though.

I'm trying to say that we can do this with is="".

> For example, <html manifest> sets the page's manifest
> URL, but you can't change the manifest URL, even though you _can_ change
> the element's attribute after the fact.
>
> In a sort of similar way, <script src> is mutable, it's just that it's
> only read at one point in the script processing model and it's the value
> at that point that matters.

-- 
Simon Pieters
Opera Software



More information about the whatwg mailing list