[Webkit-unassigned] [Bug 47813] [HTML5] "form" attribute support for form control elements
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Nov 6 07:57:53 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=47813
Kent Tamura <tkent at chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #73059|review? |review-
Flag| |
--- Comment #6 from Kent Tamura <tkent at chromium.org> 2010-11-06 07:57:53 PST ---
(From update of attachment 73059)
View in context: https://bugs.webkit.org/attachment.cgi?id=73059&action=review
Yes, we need to update HTMLFormElement::m_associatedElements. However, HTMLFormElement::formElementIndex() doesn't work well with elements outside of the form. We need to update formElementIndex() implementation, and should add test cases for form.elements[] order.
We need to handle cases that
- A "form" attribute of a control is added or changed to another form, or removed.
- An "id" attribute of a form element is added, changed, or removed.
You had better to take a look at the specification again. It mentions many cases of changing form owner.
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
Also, we need to take care of multiple form elements with identical ID values. Document::getElementById() returns the first element in document-order in such case. So <foo form=id1> should be associated to the first form with id=id1 in document-order.
> WebCore/html/HTMLFormElement.cpp:150
> + for (Node* node = document()->traverseNextNode(); node; node = node->traverseNextNode()) {
This is not acceptable at all. This code will introduce significant performance regression for existing pages.
I recommend to store a list (hash?) of form controls with id attribute to Document, like existing Document::registerFormElementWithState() and unregisterFormElementWithState(), and search the list for controls pointing this form element.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list