On Jan 28, 10:20 am, Dave Methvin <dave.meth...@gmail.com> wrote:
> There are the "static" properties and attributes that were defined in
> the HTML itself, and then the "dynamic" ones that reflect the current
> state of the element, including things like attached event handlers.
> Unfortunately, the W3C doesn't make it totally clear what is supposed
> to be copied on a clone.
Yes, it does. It says:
"Cloning an Element copies all attributes and their values..."
In other words, it copies the HTML attributes, not the DOM
properties. The trouble is that the difference between HTML
attributes and DOM properties may not be obvious. In some cases, the
HTML attribute and DOM property of the same name do not map to each
other (e.g. the HTML option element's selected attribute maps to the
DOM defaultSelected property, the DOM option element's selected
property has no HTML equivalent).
As noted above, listeners added using addEventListener and attachEvent
are dropped when cloning since they are added as DOM properties, but
inline listeners (i.e. those that stem from HTML attribute values) are
not.
When text is entered into a text input, it changes the value attribute
since the displayed text is specified as being the same as the value,
hence it is cloned. Same for radio buttons and check boxes - the
display is linked to the HTML checked attribute.
For option elements (since they are cloned too when deep cloning a
select), selecting an option doesn't change the HTML selected
attribute, its equivalent is the DOM defaultSelected property. The
option element's DOM selected property has no equivalent HTML
attribute, so its value isn't cloned. If the HTML selected attribute
is set, it is cloned and that option will be selected in the cloned
select (note that if no option has the selected attribute set, the UA
will pick one to select, usually the first one).
Another confusing case is the textarea element - its HTML value is set
to the value of the text node inside the text area element. New text
is held in the DOM value property, so when it is cloned, the original
HTML value is given to the element, not the new DOM value of user
entered text. This seems inconsistent with the behaviour of text
inputs, where the displayed text is linked to the value attribute, but
I think it stems from the fact that the textarea has an implied HTML
value attribute based on the *initial* text in the textarea, not an
explicit value attribute like inputs do.
I think the HTML 5 spec tries to deal with this, but it takes quite a
bit of reading to understand it.
<URL: http://dev.w3.org/html5/spec/Overview.html#concept-textarea-raw-value
>
> It varies depending on the browser.
Which ones?
> There is a bug report filed against it in the tracker with the hope
> that jQuery might try to normalize it across all browsers, but it's
> not a jQuery bug.
There may be an issue with "normalising" behaviour that is contrary to
the specification. It may be just as confusing if some DOM properties
are mapped to HTML attributes, but others aren't (e.g. inaccessible
properties like listeners, or readonly properties like form).
--
Rob
