On May 8, 12:52 am, Andrew Dupont <[EMAIL PROTECTED]> wrote:
> Element#readAttribute is meant to work the way the native
> Element#getAttribute _ought_ to.

The term "native" does not help me here: when you say "ought to", are
you referring to the DOM 2 Core specification or the actual behaviour
in various implementations?


> The DOM spec says getAttribute should
> always return the string value of the attribute.

Which infers (to me) that getAttribute('disabled') should return
"true" if the disabled attribute is present in the markup and "null"
if it isn't.  If it has been set by script, it should return "true" or
"false".

When setting the value in the markup, there are differences in
browsers.  Firefox seems to think HTML should be treated as XML -
getAttribute returns 'disabled' only if the attribute is set using
disabled="disabled", but results in the bizare situation where setting
disabled="enabled" (or "false" any value you like) disables the
control but getAttribute returns the literal value (i.e. "enabled" or
"false" or whatever).


> IE(<= 7) incorrectly
> maps HTML attributes to DOM properties, such that
> node.getAttribute('disabled') === node.disabled.

It is incorrect in that getAttribute returns a boolean instead of a
string, however that is no worse that Firefox, which returns the null
object (converts to an empty string) even if the attribute is
present.  The HTML specification doesn't provide a value for the
disabled attribute, it just says what the behaviour is if it is
present.  The DOM HTML specification says that the value should be
true or false.


> In other words: if you want the boolean, you've already got the JS
> property.

Which was my point.  Reading the property directly is at least
consistent in a wide variety of browsers, does not require any
additional code and can be used directly in conditional statements:

  if (el.disabled) {...}

seems much clearer to me (and much less prone to error) than:

  if (el.readAttribute('disabled') === 'disabled') {...}


> Element#readAttribute aims for the consistent behavior
> across browsers that getAttribute lacks.

Some may infer that consistency means returning values like "enabled",
"unchecked" and so on.

Have you considered including the selected attribute in the list of
those supported by readAttribute?.


--
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to rubyonrails-spinoffs@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to