Prev: FAQ Topic - What is JScript? (2010-03-20)
Next: For all those jQuery fanboys
From: David Mark on 20 Mar 2010 11:04
Eric Bednarz wrote:
> David Mark <dmark.cinsoft(a)gmail.com> writes:
>
>> Eric Bednarz wrote:
>
> [<input readonly>]
>
>>> There's a start tag, there's an explicit attribute value specified in
>>> that start tag, there's an empty string as a result of reading that
>>> attribute value. That doesn't seem to be exactly right to me.
>> The browser developers seemed to have a different take on it. And BTW,
>> what would this mean?
>>
>> <input readonly="">
>
> It would mean invalid markup.

I thought it might, which does tend to make the browser developers'
treatment of these attributes illogical. But I have to play the hand
I've been dealt.

>
>> I honestly don't know what browsers would do with that. Nothing
>> consistent I imagine.
>
> Why would that matter? It is expected behaviour that getters produce
> inconsistent results on wrong code; the above example is wrong per DTD
> (which doesn't necessarily matter), wrong per spec prose, and as far as
> I can see wrong per common sense.

It doesn't really matter.

>
> It is fairly trivial to have a getAttribute wrapper check if the
> provided attribute name is in a short list of 'boolean' attributes and
> return the uppercased (I presume an HTML DOM) name instead of trying to
> get the value. The error margin would be limited to invalid attribute
> value( literal)s.

The thing is that I only want to do a workaround in the least number of
cases and I want to be consistent with what browsers (other than IE)
have been doing for the last decade.

>
>>>> It's not:-
>>>>
>>>> <input readonly="readonly">
>>>>
>>>> ...though they mean the same thing, of course.
>>> Technically, the don't *mean* the same thing. They *are* the same thing.
>> Depends on how you look at it.
>
> Fair enough; I look at it the SGML way, because that is currently the
> only specified one, and that way it is about syntactic sugar.
>
> As an aside, there's a lot of syntactic sugar in SGML; e.g.
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
>
> and
>
> <!DOCTYPE HTML [
> <!ENTITY % extsub PUBLIC "-//W3C//DTD HTML 4.01//EN">
> %extsub;
> ]>
>
> are *exactly* the same thing (now try to explain that to doctype
> sniffing devices; you see, user-agent sniffing is not the only retarded
> strategy widely in use :-).

You lose me with the SGML stuff. I remember dealing with it at IBM in
the late 80's for documentation. Haven't thought about since.

>
>> Canonically, they are not the same thing
>> (e.g. if you are trying to reproduce the source exactly as written).
>
> I cannot imagine why and how you would try to do that. Staying with
> attributes for a moment, how would you get an attribute value literal
> from an attribute value (outerHTML or some wrapper method for it can get
> you a long way, but there are brick walls for that too)?
>

I don't get any values from outerHTML, that's for sure. What I had done
for years is to have two forks, one for broken MSHTML (detected with a
feature test) and one for the rest. The latter was simply a one-liner
and returned:-

<input disabled>

returns "" for disabled attribute

<input disabled="disabled">

returns "disabled"

<input>

returns null

The broken MSHTML fork had to pick one and I chose the first one (for no
specific reason that I can remember).

Then came IE8, which predictably switched to the second fork, but
unfortunately, they didn't conform with the historical "standard". So
to keep everything consistent, I added a feature test and caused
browsers that used the second fork to always return "", rather than the
name of the attribute.

<input disabled>

returns "" for disabled attribute

<input disabled="disabled">

returns "" for disabled attribute

<input>

returns null

I talk a little bit about this decision here:-

http://www.cinsoft.net/attributes.html
First  |  Prev  | 
Pages: 1 2
Prev: FAQ Topic - What is JScript? (2010-03-20)
Next: For all those jQuery fanboys