Default Values

In the current draft of our Explainer document, Section 3.2 Values appears
(to me) to have a redundant entry. It currently states:

The value may be one of the following types:
true/false Value representing either true or false, with a default "false"
value. true/false/undefined Value representing true or false, with a
default "undefined" value indicating the state or property is not relevant.

Question: do we really need to make this distinction? Taking a cue from the
current HTML5 specification
<https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#keywords-and-enumerated-attributes>,
I believe we can remove the first entry, and likely echo some of the text
from the HTML5 spec here as well:

The value may be one of the following types:
true/false/undefined
Value representing true or false, with a default "undefined" value
indicating the state or property is not relevant. If the attribute value
matches none of the given keywords, but the attribute has an *invalid value
default*, then the attribute represents that state. Otherwise, there is no
default, and invalid values mean that there is no state represented.

When the attribute is *not* specified, if there is a *missing value default*
state defined, then that is the state represented by the (missing)
attribute. Otherwise, the absence of the attribute means that there is no
state represented.

While I've been comfortable up to this point making very minor grammatical
changes, removing some content and augmenting this point feels "bigger" to
me, and before I propose the change, I'd like to get some feedback from the
group.

Anyone?

JF
--
*John Foliot* | Senior Industry Specialist, Digital Accessibility

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"