[Bug 17176] Element attributes should not be required to be stored in an ordered list, .innerHTML remains unspecified

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17176

Aryeh Gregor <ayg@aryeh.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ayg@aryeh.name

--- Comment #4 from Aryeh Gregor <ayg@aryeh.name> 2012-05-28 09:22:49 UTC ---
And for web compat, the order of the attributes created by the HTML parser
needs to be the same as the order in the markup, right?  We can't say they're
put in, e.g., alphabetical order -- that would surely break the web.

(In reply to comment #0)
> Minimal Test Case:
> HTML: 
> <div id="real"><a id="foo" class="blah" href="#">link</a></div>
> <div id="temp"></div>
> 
> JS:
> function f() {
> var anchorElement = document.getElementById('foo');
> anchorElement.id = 'foochanged';
> return document.getElementById('real').innerHTML;
> }

DOM4 says this leaves the id attribute in the same position as it was.

> function g() {
> var anchorElement = document.getElementById('foo');
> anchorElement.removeAttribute('id');
> anchorElement.setAttribute('id', 'foochanged');
> return document.getElementById('real').innerHTML;
> }

DOM4 says this moves the id attribute to the end of the attribute list.

> var tempDiv = document.getElementById('temp');
> var expectedHTML = '<a id="foochanged" class="blah" href="#">link</a>';
> tempDiv.innerHTML = expectedHTML;
> 
> Case1:
> assertEquals(tempDiv.innerHTML, f()); 
> 
> Case 2:
> assertEquals(tempDiv.innerHTML, g()); 

The behavior of these two asserts is only undefined because the HTML parser's
behavior is undefined.  If the parser orders the attribute list in the same
order as the markup, and the serializer serializes them in DOM order, case 1
must pass and case 2 must fail.  This is probably how it should be.

> These tests work fine when run using a server side JS container that spoofs
> browser manipulation of the DOM in a deterministic manner but they fail when
> run on real browsers using Webdriver tests because FF and Chrome render
> .innerHTML with the attributes in different orders and they are in conformance
> with the spec when doing so.

What are cases where they serialize the attributes in different orders?  That's
the bug -- it should always be the same.

> The use of the DOM API to validate the HTML
> structure is extremely cumbersome because that would imply writing hundreds of
> brittle asserts (one for each element, attribute, text node etc.) which would
> make the tests really opaque to someone reading them.

Actually, you could just write an assertHtmlEquals() function that wraps all
the checks.  I've done this for standards tests (at least Range/Selection).

> Apologies for the length of the bug report. Also, this is my first time at
> filing bugs with the W3C so if I can do something better for the next time,
> please do let me know.

Generally it's better to keep it as concise as possible, and emphasize concrete
pieces of HTML/JS, how the spec says they behave, how browsers treat them, and
how you want them to behave, and why you want them to behave that way.  Longer
and more detailed is better than leaving out details, though, so this bug
report is very good for a first one.  Thanks!  :)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 28 May 2012 09:22:59 UTC