This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html Multipage: http://www.whatwg.org/C#the-form-element Complete: http://www.whatwg.org/c#the-form-element Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: The order of the supported property names of a form is not clear Posted from: 98.110.194.206 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20130521 Firefox/24.0
The spec says: > in tree order, with id attributes preceding name attributes preceding entries > from the past names map, with multiple entries in the past names map for the > same element being ordered chronologically by when they were added to the map I _think_ what it means is that the set of elements involved (listed elements, <img> descendants, and values, not keys, from the past names map) should be sorted by tree order, and that then for each element you put in its id, if any, then its name, if any, then any past names map keys that had the element as a value, in chronological order. But I'm not 100% sure about that, and I think it would be good to make it clearer what the order is. It might involve more than a single sentence to do that, but I think it would be worth the clarity.
That's what I intended, yes. What other interpretation is there? The current text (changed for another bug) is: "The values must be listed in tree order, with id attributes preceding name attributes preceding entries from the past names map when the same element has more than one, and with multiple entries in the past names map for the same element being ordered chronologically by when they were added to the map, and in all cases ignoring later duplicates." Is that still ambiguous?
I think the problem I'm having is that the values themselves do not have tree order. Elements have tree order. And a single value in the list can correspond to multiple elements, while a single element can correspond to multiple values. The latter case is handled ok, but the former case is a bit confusing. It might be worth spelling out more clearly how to come up with this liss, since at least one implementor trying to implement this section has already gotten it wrong.
Alright. Maximum verbosity: ON! :-) This is mostly new text, so hopefully it's still accurate. Please don't hesitate to file new bugs if you see a problem with it. Hopefully, it's at least unambiguous and precise now.
Checked in as WHATWG revision r7986. Check-in comment: Be even more explicit about the supported property names of a <form>. http://html5.org/tools/web-apps-tracker?from=7985&to=7986
Thank you.