Re: [whatwg] DOMTokenList: mutation clarification
On Mon, Aug 10, 2009 at 1:09 AM, Ian Hicksoni...@hixie.ch wrote: I've reworded it to imply only one mutation event fires. Thanks. 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? I think that the spec now implies that you set the attribute to the empty string. Do you agree? I don't think it changes the interpretation of this border case and I still think the spec implies that no attribute is added. Maybe the ambiguity is about the definition of mutation in the when the object mutates this empty string sentence. If we have an element with no class attribute and call .remove(foo), we start the remove() algorithm with the empty string and it doesn't modify that string. So I would say that there wasn't a mutation and that no attribute should be added. One way to clarify that no attribute should be added might be (the change is between the parentheses): When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string (that is, the algorithm changes the underlying string to a non-empty string), the user agent must add the corresponding content attribute, with its value set to the value it would have been set to after mutating the empty string. I also assume an otherwise, do nothing at the end of that sentence. Do you think somebody could interpret this as an otherwise add an attribute set to the empty string? Sylvain
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
On Tue, Jul 28, 2009 at 5:52 AM, Jonas Sickingjo...@sicking.cc wrote: By the way, preserving duplicates shouldn't be much code complexity if I'm not mistaken. I take it you mean *removing* duplicates here, right? Oops, yes. The only required code change would be to use a hashset when parsing the attribute in order to only insert unique tokens in the token vector. Then DOMTokenList.length would return the token vector length and .item() get the token by index. I don't think anything actually depends on keeping duplicate tokens in the token vector. Then there would be a small perf hit when parsing attributes with more than one token. It's certainly doable to do this at the time when the token-list is parsed. However given how extremely rare duplicated classnames are (I can't recall ever seeing it in a real page), I think any code spent on dealing with it is a waste. Agreed. The remove() algorithm is about 50 lines with whitespace and comments. After all, that's not a big cost and I guess that preserving whitespace may be closer to what DOMTokenList API consumers would expect. The code would be 7 lines if we didn't need to preserve whitespace: nsAttrValue newAttr(aAttr); newAttr-ResetMiscAtomOrString(); nsCOMPtrnsIAtom atom = do_GetAtom(aToken); while (newAttr-GetAtomArrayValue().RemoveElement(atom)); nsAutoString newValue; newAttr.ToString(newValue); mElement-SetAttr(...); If you spent a few more lines of code you could even avoid serializing the token-list and call SetAttrAndNotify instead of SetAttr. That's an interesting comparison. Less code and much more readable than my remove() implementation I have to say. Sylvain
Re: [whatwg] DOMTokenList is unordered but yet requires sorting
On Tue, Jul 28, 2009 at 2:17 AM, Ian Hicksoni...@hixie.ch wrote: On Sun, 12 Jul 2009, Jonas Sicking wrote: Oh, I have forseen that. Is it really necessary to remove duplicates ? I imagine DOMTokenList to be similar to what can be achieved with a String.split(), but then it would be just more duplicate functionality. If we don't remove duplicates, then things like the .toggle() method could have some quite weird effects. Such as? Such as .length changing by more than 1 after a call to .toggle(). I guess that couldn't have happened, because .length counted only the unique tokens. I definitely think it'd be worth avoiding the code complexity and perf hit of having the implementation remove duplicates if they appear in the class attribute given how extremely rare duplicates are. Fair enough. I've made DOMTokenList not remove duplicates. ok, I realize now that this is about the duplicates in .length and item(). By the way, preserving duplicates shouldn't be much code complexity if I'm not mistaken. The only required code change would be to use a hashset when parsing the attribute in order to only insert unique tokens in the token vector. Then DOMTokenList.length would return the token vector length and .item() get the token by index. I don't think anything actually depends on keeping duplicate tokens in the token vector. Then there would be a small perf hit when parsing attributes with more than one token. To summarize: pros: simpler spec algorithms, simpler implementation cons: less whitespace preservation, small perf hit during tokenization I don't know if I'm missing something. Does this sound reasonable? It ends up being not much simpler since you still have to deal with direct changes to the underlying string, as far as I can tell. I don't think changing the underlying string is related to that algorithm (from an implementation point of view). On setting, the tokens would be deleted and the attribute parsed again. On Mon, 13 Jul 2009, Jonas Sicking wrote: I do agree that the spec seems to go extraordinary far to not touch whitespace. Normalizing whitespace when parsing is a bad idea, but once the user modifies the DOMTokenList, I don't see a lot of value in maintaining whitespace exactly as it was. Ian: What is the reason for the fairly complicated code to deal with removals? At least in Gecko it would be much simpler to just regenerate the string completely. That way generating the string-value could just be dropped on modifications, and regenerated lazily when requested. In general, I try to be as conservative as possible in making changes to the DOM. Are the algorithms really as complicated as you're making out? They seem pretty trivial to me. The remove() algorithm is about 50 lines with whitespace and comments. After all, that's not a big cost and I guess that preserving whitespace may be closer to what DOMTokenList API consumers would expect. Sylvain
Re: [whatwg] Definitions of DOMTokenList algorithms and element.classList
On Wed, Jul 22, 2009 at 6:07 PM, Anne van Kesterenann...@opera.com wrote: On Mon, 13 Jul 2009 05:16:19 +0200, Ian Hickson i...@hixie.ch wrote: I've clarified that DOMTokenList is always case-sensitive. We don't want to be adding more quirk-mode behaviours. Using quirks mode is not conforming (i.e. it's not a supported behaviour). Implementation-wise that does not seem nice if you want to use the same optimized object when dealing with style sheets or getElementsByClassName(). Actually for the Mozilla implementation, it's simpler to have it case sensitive (that's not a big difference though). I don't know if that could be more of an issue in other implementations. Sylvain
[whatwg] DOMTokenList and whitespace
Hi, 1) What's the reason for preserving whitespace when a DOMTokenList method is changing the attribute? 2) If preserving whitespace is not important, what about normalizing whitespace during mutation? By normalizing whitespace, I mean splitting tokens (keeping unique ones), doing the DOMTokenList add/remove/toggle operation, and joining tokens together separated by a whitespace. I've already implemented the current spec algorithm in Mozilla [1], but normalizing whitespace should simplify things a bit. It would be interesting to have other implementor's opinion on this. (Note: this was previously raised in [2], but it should have been a new thread.) Sylvain [1] https://bugzilla.mozilla.org/show_bug.cgi?id=501257 [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021018.html
[whatwg] DOMTokenList: mutation clarification
Hi, 1) in http://www.whatwg.org/specs/web-apps/current-work/#common-dom-interfaces When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string, the user agent must first add the corresponding content attribute, and then mutate that attribute instead Does it mean it should fire two DOMAttrModified events, one with the empty string addition, and the other with the attribute mutation? I think it should simply fire only one mutation event in that case as in all other cases (should be simpler and more efficient, although that case shouldn't happen very often). I don't see a good reason to fire one with the empty string. 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? Sylvain [1] http://simon.html5.org/test/html/dom/reflecting/DOMTokenList/getting/009.htm
Re: [whatwg] DOMTokenList feedback
On 7/6/2009 9:08 AM, Kristof Zelechovski wrote: Regarding DOMTokenList, why not: contains(): true add,remove,toggle(): no effect? That could be an option. There is already a INVALID_CHARACTER_ERR exception thrown if the token contains spaces. So I think it would be consistent to throw an exception if the token is empty, following the rule invalid tokens raise exception (and considering empty tokens as invalid). Are there situations that would require an exception to be thrown, or else the page would go out in a blast? Hard to say, but calling these functions with empty tokens certainly means there is a bug somewhere and throwing an exception in that case could help authors identify the issue when it happens. Sylvain
[whatwg] DOMTokenList feedback
Hi, I'm looking at the Gecko implementation of element.classList. I had a few comments about the spec. 1) http://html5.org/tools/web-apps-tracker?from=3253to=3254 missed something. There is still a mention of alphabetical sort order in the beginning of section 2.8.3: element = tokenlist . item(index) tokenlist[index] Returns the token with index index. The tokens are sorted alphabetically. 2) contains/add/remove/toggle should mention what happens if an empty string token is passed in the token argument. Looking at the DOM Core exceptions, throwing a SYNTAX_ERROR seems to be the best match in this case (if we consider an empty string as invalid): SYNTAX_ERR, introduced in DOM Level 2. If an invalid or illegal string is specified. 3) case sensitivity. Would be nice to address [1]. Note that the definition of uniqueness for .length and .item() will also need to be revisited if we want to handle classes in a case-insensitive way in quirks mode. Sylvain [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020425.html
[whatwg] Cross browser automated tests
Hi, I'm working on an experimental project to build a set of cross browser automated tests. The idea would be to have a repository of browser independent automated tests. Existing test suites could be imported into it. These tests could be run automatically on today's available browsers with the results published. Spec writers or web developers could check what feature is implemented on what browser and browser vendor could use that for their internal regression tests. Would WHATWG be interested in such a project? As a starting point, the testing environment and API would need to be defined. I'm thinking of the following requirements: * Possible for browser vendors to integrate these tests in their testing frameworks * Minimal modifications necessary for migrating existing non automated test cases like the ones on http://www.hixie.ch/tests or http://tc.labs.opera.com/. They should still report PASS/FAIL messages when run in a browser like they do now, which is convenient for testing test cases individually. To meet these goals, such an API should be as unobtrusive as possible: * One .js file to include * A set of functions that can be called for performing the checks and life cycle functions (end of tests, ...) Once this is defined, existing non automated test cases could be modified and imported in the repository. That could be lot of work if I'm looking at all the tests linked from http://wiki.whatwg.org/wiki/Test_cases, but I think there would be lots of benefit. The other big part of the work is to develop the framework for running these tests automatically and reporting the results. I've already done some experiments by running automated tests from Mozilla and WebKit. The results are visible on http://www.browsertests.org/. I started a thread on Mozilla [1] and WebKit lists [2]. There were some interesting discussions with Jeff Walden on the Mozilla list already. Sylvain [1] http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/b2a959c7547b9877 [2] https://lists.webkit.org/pipermail/webkit-dev/2008-May/003943.html
