Prev: FAQ Topic - What is JScript? (2010-03-20)
Next: For all those jQuery fanboys
From: David Mark on 19 Mar 2010 21:49
Eric Bednarz wrote:
> Using the DOM module at
>
> <http://www.cinsoft.net/mylib-builder.asp>
>
> and given
>
> <input readonly>
>
> as the first element of type INPUT in a HTML context,
>
> API.getAttribute(
> document.getElementsByTagName('INPUT')[0],
> 'readonly'
> )


Sorry for the late response. Just happened to stumble over this.

>
> returns an empty string in Firefox 3.5, Opera 10.10, Safari 4, Google
> Chrome 4 beta (all on OS X) and Internet Explorer < 8.

That's exactly right (and all but IE are doing that on their own as the
wrapper at that time did virtually nothing in the quasi-standards fork).

It's not:-

<input readonly="readonly">

....though they mean the same thing, of course.

And I have since forced IE8 standards mode to do the same thing to give
a consistent interface (an inconsistent interface would clearly be
poison for such attributes--see YUI, jQuery, etc.)

What would you have it do? I know the specs say something different,
but none of the browsers over the years have implemented attributes per
the specs (and in places the specs make no sense anyway). As an example
nonsense, they say to return an empty string for _any_ attribute that is
absent. I am certainly glad the browser developers came up with a
better plan than that (e.g. returning null for that case). :)

At the end of the day, what matters for wrappers is a consistent
interface. They are, after all, wrappers. There is no pretense that
they are to behave identically to the host methods (unless you consider
such monstrosities as Base2).

http://www.cinsoft.net/attributes.html

....which has since been pasted over the old My Library attribute methods.

>
> Amazingly IE 8 seems to be the only browser to get the getAttribute
> method of the Element interface right (in this respect), and that
> even without using any wrapper methods. Bummer :-)

But in getting it right (technically right per the specs), in practical
terms they got it wrong as over a decade of history contradicts them, so
they have created problems for no reason. Furthermore, they return null
for virtually all of the other attributes when missing, which history
(and common sense) says is right, but the specs say is wrong. I would
have certainly preferred they return null for missing attributes,
period. but it doesn't really matter as the wrapper smooths that out
per _my_ specs (it's not a browser host method, so mine are the only
specs that matter). ;)
From: Eric Bednarz on 19 Mar 2010 22:11
David Mark <dmark.cinsoft(a)gmail.com> writes:

> Eric Bednarz wrote:

>> <input readonly>

>> API.getAttribute(
>> document.getElementsByTagName('INPUT')[0],
>> 'readonly'
>> )
>
> Sorry for the late response. Just happened to stumble over this.

I wondered why you didn't jump on it ;-)

>> returns an empty string in Firefox 3.5, Opera 10.10, Safari 4, Google
>> Chrome 4 beta (all on OS X) and Internet Explorer < 8.
>
> That's exactly right

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.

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

> What would you have it do?

Return the specified attribute value?
From: David Mark on 19 Mar 2010 22:13
Eric Bednarz wrote:
> David Mark <dmark.cinsoft(a)gmail.com> writes:
>
>> Eric Bednarz wrote:
>
>>> <input readonly>
>
>>> API.getAttribute(
>>> document.getElementsByTagName('INPUT')[0],
>>> 'readonly'
>>> )
>> Sorry for the late response. Just happened to stumble over this.
>
> I wondered why you didn't jump on it ;-)
>
>>> returns an empty string in Firefox 3.5, Opera 10.10, Safari 4, Google
>>> Chrome 4 beta (all on OS X) and Internet Explorer < 8.
>> That's exactly right
>
> 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="">

I honestly don't know what browsers would do with that. Nothing
consistent I imagine.

>
>> 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. Canonically, they are not the same thing
(e.g. if you are trying to reproduce the source exactly as written).

>
>> What would you have it do?
>
> Return the specified attribute value?

That's fine, but it's my wrapper. :) I preferred the ad hoc standard,
as well as the ability to discriminate between the two cases.
From: David Mark on 20 Mar 2010 00:26
David Mark wrote:
> Eric Bednarz wrote:
>> Using the DOM module at
>>
>> <http://www.cinsoft.net/mylib-builder.asp>
>>
>> and given
>>
>> <input readonly>
>>
>> as the first element of type INPUT in a HTML context,
>>
>> API.getAttribute(
>> document.getElementsByTagName('INPUT')[0],
>> 'readonly'
>> )
>
>
> Sorry for the late response. Just happened to stumble over this.
>
>> returns an empty string in Firefox 3.5, Opera 10.10, Safari 4, Google
>> Chrome 4 beta (all on OS X) and Internet Explorer < 8.
>
> That's exactly right (and all but IE are doing that on their own as the
> wrapper at that time did virtually nothing in the quasi-standards fork).
>
> It's not:-
>
> <input readonly="readonly">
>
> ...though they mean the same thing, of course.
>
> And I have since forced IE8 standards mode to do the same thing to give
> a consistent interface (an inconsistent interface would clearly be
> poison for such attributes--see YUI, jQuery, etc.)
>
> What would you have it do? I know the specs say something different,
> but none of the browsers over the years have implemented attributes per
> the specs (and in places the specs make no sense anyway). As an example
> nonsense, they say to return an empty string for _any_ attribute that is
> absent. I am certainly glad the browser developers came up with a
> better plan than that (e.g. returning null for that case). :)
>
> At the end of the day, what matters for wrappers is a consistent
> interface. They are, after all, wrappers. There is no pretense that
> they are to behave identically to the host methods (unless you consider
> such monstrosities as Base2).
>
> http://www.cinsoft.net/attributes.html
>
> ...which has since been pasted over the old My Library attribute methods.
>

I should head off any misguided finger pointing from the "you aren't
perfect either" crowd. :) You know the "argument". If a person says
stealing is wrong and then turns out to have once robbed a bank, then it
means that stealing must be right. :)

IE's odd divergence from reality with respect to the "boolean"
attributes was definitely unforeseen (though certainly could have been
had I read the specs carefully), yet it had virtually no effect on My
Library (unless you were using the getAttribute method "raw", which is
virtually never needed). Internally, hasAttribute guarded against
faults in the few places that use getAttribute (e.g. query, import, get
HTML).

The one (standard) fork that was replaced in getAttribute used to be a
single line. Something like:-

return el.getAttribute(name);

It's since been bulked up to maybe a dozen lines, mainly to deal with a
few odd cases of browsers following the specs for some attributes (e.g.
returning an empty string in lieu of null).

So I wasn't perfect on this one method. But that doesn't validate dreck
like YUI, which will return an empty string for any missing attribute,
colliding with the cases where an empty string means the attribute is
there (e.g. "booleans" in virtually every browser published this
century), not to mention when the attribute actually has an empty value.
They might have gotten away with that if they had a competent
hasAttribute wrapper; but alas, they did not last I checked (not even
close). And don't get me started on jQuery, which bungles attributes in
so many ways that it would take a pad of graph paper and color pencils
to map out all of the variations per browser, jQuery version, phase of
the moon, etc. ;)
From: Eric Bednarz on 20 Mar 2010 09:04
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 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 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.

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

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

 |  Next  |  Last
Pages: 1 2
Prev: FAQ Topic - What is JScript? (2010-03-20)
Next: For all those jQuery fanboys