Re: [WICG/webcomponents] case-sensitive access to HTML attributes (as they were written) would be useful for framework authors (Issue #1076)

> So any time we access in JS it clones them?

AIUI no. My undersranding: when you access in JS it points to the same memory (strings themselves are immutable in JS, but if you call an operation, e.g. toLowerCase() you'll get a different immutable value back, which can be assigned to your identifier).

> Anytime before we access them we also make a string in JS to match against?

During parse time the string is lowercased and compared to an interned string. The old contents are effectively thrown away, and this is the issue - we'd need to start keeping around both.

> What if it interns the pre-normalized name instead, if not both?

That's sort of not possibe. Engines do compile time interning. But not every attribute is an interned attribute name (e.g. `data-` attributes aren't, and you can always make up an attribute name the browser doesn't know about), so string interning isn't _mandatory_, it just makes things way faster.

---

Something I'm not sure about though. Given this:

```html
<div foo="bar" fOo="baz" fOO="bing" FoO="qux" foO="quux">
```

What would be the answers to these questions:

 - What is the content attribute set to? HTML spec says right now is should be `bar`.
 - Should the browser throw away all of the subequent attributes?
 - What are you expecting to get back? If you call `getAttributeNode('foo').originalName` do you expect `'foo`' or `'foO'`, or something different?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1076#issuecomment-2409198308
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1076/2409198308@github.com>