Re: [dom] Attributes do not need a name slot for web compat (#110)

@foolip So first of all, it's worth separating what's stored and what's compared.  That is, it's quite possible to implement the spec algorithm, and efficiently in the common case, even if you just store prefix and localname separately and don't store what the spec calls "name".

Now in terms of what Gecko actually implements, each attribute has an `AttrName` which is either a string or a struct.  The string is used for the case when the attribute has no prefix and is in the null namespace.  The struct is used for the other cases (i.e. when there is a prefix and/or a namespace).  The struct stores the prefix, localName, namespace, and a "qualified name" which is basically used to optimize access to things that need a qualified name.  The structs are shared across things with the same (prefix, localName, namespace) triple, so in practice the space used by the "qualified name" is negligible, especially given how rare attributes that need the struct are to start with.

The "get an attribute by name" steps in Gecko ASCII-lowercase the name, then return the first attribute for which either the AttrName is a string matching the given one or the AttrName is a struct for which the qualified name matches the given string.

Note that the latter compare could be done even if you don't store the full "name" string, by e.g. checking that the given string starts with the prefix, ends with the localName, has only one more char, and that char is ':'.  This can be done without allocations and string copies, if that's what's worrying you.

But yes, conceptually I don't think attributes need a "name" slot, since it can be recreated from the prefix and localName.  I can't speak to how convenient or not it would be to specify things that way.

I _do_ think specifying the two-pass thing you propose is not a good idea, especially since there is no particular implementation need for it afaict.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/110#issuecomment-158839681