Re: What is a "state"?

On 13 Jun 2007, at 21:28, Ian Hickson wrote:

>>
>> Yes, I think I can agree with that. But if you have specified a  
>> missing
>> value state, unsetting the attribute amounts to telling it to be in a
>> that state.
>
> When you haven't set the attribute, you haven't told it to be in a  
> state.
> You haven't said anything!

I assume that "you" refers to an application and that you're not  
refering to an initial stat", but to the general situation in which  
an attribute is not set.

It is true that applications don't tell attributes to be in specific  
states. States only exist in the specification. That's where we  
"tell" about states. Applications "tell" concrete attributes to be  
set to concrete values, or to not exist at all. They don't deal with  
states at all. Furthermore we cannot deprive attributes of being in  
states. An attribute cannot not be in a state. As long as it is  
known, it will allways be in some state, even if it doesn't  
physically exist and even if we haven't given that state a particular  
name and significance.

>> Likewise, if you have specified an illegal value state, setting the
>> attribute to a value that is a member of the corresponding illegal  
>> value
>> set, amounts to telling it to be in that state.
>
> No, it amounts to setting it to a state that doesn't exist (e.g.  
> one from
> a future version).
>
> If the attribute takes values "on" and "off" and you set it to  
> "blue" you
> haven't told it to be off. It _defaults_ to off, but only because it
> doesn't know what else to do with "blue".

Had "state" been a computed value, I would have agreed with you. But  
it isn't. It's an abstraction. In this example, saying that the  
attribute "is off" or "is in its off state" is just a shorthand for  
saying its "either set to 'off' or an illegal value". Applications  
have to check against the actual value. They cannot retrieve the  
state anywhere. The attribute doesn't "know" anything about the  
association between values and states, nothing needs to be done, no  
default is set, its value remains set to "blue".

The problem is that the spec switches between conceptualizing "state"  
as an abstraction and as a computed value. Your wording illustrates  
the confusion this leads to. With the content attribute  
"contenteditable" this is particularly confusing since there actually  
is a computed value - the DOM attribute "contentEditable" - whose  
values are not identical to the names of its (the content  
attribute's) states.

>> If you haven't specified a missing value state, however, unsetting  
>> the
>> attribute will lead to a situation where the state is undefined.  
>> That's
>> when you (hypothetically) would bring in a default state.
>
> ...at which point, by your argument, you would have specified a  
> missing
> value state, and it would no longer be a default.

No, it would be a default name that should be assigned to the missing  
value situation if no name was explicitly given in the definition of  
the attribute. This would only be a convenience definition.

--
Henrik D

Received on Thursday, 14 June 2007 10:41:08 UTC