- From: <bugzilla@jessica.w3.org>
- Date: Mon, 20 Oct 2014 21:37:30 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27114 --- Comment #2 from Domenic Denicola <domenic@domenicdenicola.com> --- For the record: http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDOMTokenList.cpp https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blink/bindings/core/v8/V8DOMTokenList.cpp https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/DOMTokenList.cpp WebKit and Blink haven't diverged much (some Oilpan stuff in Blink mostly) and they seem to be purely string-manipulation based, if I am understanding them correctly. Gecko only seems to use their mElement pointer toward the end of the functions, so I think it could be factored out into a separate wrapper class (or similar code-reuse strategy) so that the generic DOMTokenList doesn't have an element dependency while still providing a convenient constructor for the cases where you want that to automatically happen. That said even after looking at the code I didn't quite understand > it also relies on the attribute itself treating the attribute as a list of whitespace-separated tokens, so generalizing it to arbitrary attributes without loss of performance would probably require a separate implementation for those arbitrary attributes. It seems from the code that it's fairly generic and will just split on whitespace for whatever attribute you give it. So I think if you threw it at an arbitrary attribute it would just end up doing what you expect? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 20 October 2014 21:37:31 UTC