-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resolves #1058, enumerated values for DOMString reflection #1261
Conversation
You may want to link to https://w3c.github.io/aria/#propcharacteristic_value somewhere in that prose... perhaps link "allowed values" or just the word "values"? |
This definitely helps, thanks! What about when the table does not notate one of the values as "(default)"? It would also be good to link:
|
Good spot. There is only one: |
It occurred to be that we may need to mention the difference between enumerated attributes that take a single value (token, tristate, etc) versus those that take multiple values (token list), including |
One additional thing, is that you should add a similar blanket statement making it clear what the states and their corresponding keywords are. Something like "Each value in the table is a keyword for the attribute, mapping to a state of the same name". Stepping back a bit further, it would probably make sense to move this out of the "ARIA Attribute Reflection" section, since it has a broader impact on the processing model of these attributes. E.g. it implies that:
|
Hmm, yeah, this doesn't use the enumerated attribute framework in HTML then, and will need a different processing model and reflection support. A precedent in HTML is
and
It sounds like you'd want to layer some additional processing on top of that, e.g. if the resulting set is empty, then set it to « "additions", "text" ». How many such cases are there? Maybe we should make this the HTML editor's job, to create a common infrastructure (like enumerated attributes) which could be shared by the relevant ARIA attributes and |
In ARIA 1.2 there are two attrs, but only one relevant in the IDL context:
|
Yes. I think it makes sense to include this in the values section, rather than just linking to it from the IDL section. I'll think on this a bit more before updating the PR. Thanks for your help. |
Hmm OK. That's a very interesting attribute. I see two options: IDL attribute directly manipulates and reflects the content attributeThis version would involve changing el.ariaRelevant = "aDDitions removals"; // shortcut for el.ariaRelevant.value = "aDDitions removals"
el.ariaRelevant.remove("removals");
el.ariaRelevant.add("all");
console.assert(el.ariaRelevant.value === "aDDitions all"); If you do that, then the resulting This follows a number of attributes in HTML, like IDL attribute is customized to reflect the data model betterThis version would not use HTML's attribute reflection framework at all, and would not use The setter would probably just set the attribute to the given value. The getter would figure out the normalized list of tokens, and return a canonicalized form. For example, it could normalize el.ariaRelevant = "all asdf additions !";
console.assert(el.ariaRelevant === "additions removals text");
el.ariaRelevant = "additions text REMOvALS ";
console.assert(el.ariaRelevant === "addition removals text");
el.ariaRelevant = "";
console.assert(el.ariaRelevant === "additions text"; This kind of "custom reflection" has some precedent in HTML in attributes like |
Okay. I think I'm going to file |
Just thought I'd mention that there's one more token list attribute that did not make it into ARIA 1.2, that may (or may not) go into ARIA 1.3. Here's the preview for aria-textseparation from PR #996. The default value is a single token, It's a particularly weird attribute because it can only take 1 or 2 tokens. :) |
Looking at this PR I'm not sure how it solves the nullable problem? Or does it help with #1058, but not fully resolve it? Also, |
Edit: Oh right, it's because that makes it available to other markup languages/technologies. So maybe it's not technically an ARIA attribute, but the ARIA spec is specifying its reflection, so definitely needs to be part of the "token list" discussion. :) |
@annevk wrote:
@domenic's comments starting here in #1058 led me to believe this was sufficient given the current limitations of what is definable in WebIDL syntax today. If it's insufficient, I may need your help determining why or suggesting a resolution.
Issue #1058 refers directly to the |
@cookiecrook I guess it depends on whether all attributes with a nullable string are enumerated. I thought that some were not, such as |
…ection, and includes examples per comment by @asurkov
…g props are removed in another branch, so not modified here.
@annevk wrote:
Ah. Thanks. Yes, now that we have the prose, I think the original intention for for the IDL nullable |
Recycling the review requests because this diff has grown substantially. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Just a few typos (I'll just push them in).
+1
(just curious... what is the missing value default for role
? Is it "undefined"? Any chance we can talk the browsers into returning the implicit role for element.role
if no explicit role was assigned? That would be so useful! 😄 )
@carmacleod wrote:
Thanks !
Empty string
That's pretty difficult to do without spinning up the accessibility code in most browsers now. TagName isn't the only factor that affects role. For example, a The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with nit/addition. Thanks so much for working through this; it makes the processing model a lot clearer, both for reflection and ARIA behavior in general.
Probably the next step would be to tackle #1110, since that's simpler than element reflection and ariaRelevant.
* Enumerated values section now replaces superseded state_prop_values section, and includes examples per comment by @asurkov * remove the nullable flag from most IDL properties; Note: the remaining props are removed in another branch, so not modified here. Co-authored-by: Carolyn MacLeod <[email protected]>
This attribute was removed from the ARIA spec in 2020: see w3c/aria#1261 and w3c/aria#1267.
This prose addition should reconcile our use of DOMString reflection for enumerated values for #1058.
💥 Error: 500 Internal Server Error 💥
PR Preview failed to build. (Last tried on May 22, 2020, 9:31 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.