This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
""" The [TreatNullAs] extended attribute must not be specified on an operation argument, attribute or operation return value whose type is not DOMString. """ This means it can't be specified on "DOMString?" (cf. [TreatUndefinedAs] which allows that). But it might be useful to allow it for "DOMString?" too. The effect should be that it doesn't change how getting works, but for setting it converts null to the empty string. Specifically, this would be useful for textContent and nodeValue in DOM Core: """ The textContent attribute must, on setting, if the new value is null, act as if it was the empty string instead, and then do as described below, depending on the context object: """ http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-textcontent That behaves like [TreatNullAs=EmptyString], but it can sometimes return null, so it has to be DOMString? and not DOMString. nodeValue is the same. Admittedly this would be a little weird, since then you'd have to specify the effect in prose if you wanted null to be treated like "null" but not if you wanted it treated like "". But timeless thought this was weird when he was reviewing the spec, so if this isn't allowed, there should at least be some note explaining why not.
I think it would be a bit weird for [TreatNullAs] to apply only to the setter when used on a nullable type. Or at least a little unobvious, so I'm inclined not to allow it. In response to timeless' comment, I added a note point out that it isn't allowed on "DOMString?", but just now I have extended that to say why ("since null is a valid value of that type"). Let me know if this is acceptable so that I can record this in the Disposition of Comments. Thanks.
I'm fine with the resolution.