Make strings non-nullable and be more explicit about number types

[alice]

Re-opening this - frustratingly there is no "undo" for a merge, just a git revert.

See #118 for earlier discussion.

@cookiecrook @minorninth let's discuss more here.

[alice]

Copying @cookiecrook's comment over:

---

@alice wrote:

@cookiecrook PTAL?

I don't understand why this is being worked on in the AOM incubator instead of in an ARIA issue? I made all the ARIA DOMStrings nullable b/c they reflect both the values of defined attributes and nullable undefined attributes. Doubles and longs cannot be nullable, which is why those were DOMStrings.

Most of the other changes are because of the findings mentioned in another comment on ARIA #691, so I'd really prefer to address these concerns on the ARIA repo.

Perhaps the AOM incubation file should include it by reference instead and limit the new IDL scope to something like:

ShadowRoot includes AriaAttributes;

As well as any object reference extensions we'd need. E.g.

interface mixin AriaElementReferences {
    // ariaLabelledByElements, etc.
}

[alice]

I don't understand why this is being worked on in the AOM incubator instead of in an ARIA issue?

Simply that we can keep the discussion smaller here and come to a consensus before we take it to the ARIA group - if you'd prefer to go directly to the ARIA discussion, though, I'm happy to do that instead.

(...) Doubles and longs cannot be nullable, which is why those were DOMStrings.

I based this change off Dominic's comment:

From: https://w3c.github.io/aria/#state_property_processing

Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. This is equivalent to their absence. User agents SHOULD treat state and property attributes with a value of "" the same as they treat an absent attribute.

It sounds like we don't need these to be nullable DOMStrings, then, for that reason.

It sounds like you disagree with this logic?

Perhaps the AOM incubation file should include it by reference instead and limit the new IDL scope to something like (...)

I think most of these things will end up having a permanent "home" somewhere else, so I think it's reasonable to group them together here for readability while we work on the details. What do you think?