- Notifications
You must be signed in to change notification settings - Fork48
Addition: expand role allowances for fieldset element#442
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:gh-pages
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
closes#400Updates allowances for the toolbar, menubar, menu, listbox, tablist, article, dialog and region roles to be used on the fieldset element.
Uh oh!
There was an error while loading.Please reload this page.
smhigley commentedDec 22, 2022
I like the role expansion. I think some of these other roles might also merit being allowed on fieldset:
|
stevefaulkner commentedDec 22, 2022
@scottaohara@smhigley Am not understanding the use cases for makingcontrol grouping/labelling semantic elements into non control grouping. |
stevefaulkner left a comment
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.
Until a discussion around addition ofarticle has occurred please do not commit
scottaohara commentedDec 28, 2022
@stevefaulkner happy to talk about this when i get back to work in the new year. but quickly, the intent here is to stop disallowing the use of roles on elements where it's actually preventing the ability for some developers to rectify poor markup. An alternate proposal i have also been working on is to more clearly indicate what roles MUST NOT be used by developers, vs those which belong more in the SHOULD NOT category (e.g., use the appropriate HTML element instead). |
stevefaulkner commentedDec 28, 2022 via email
Yeah no worries let’s discuss when you are back! …On Wednesday, 28 December 2022, scottaohara ***@***.***> wrote:@stevefaulkner <https://github.com/stevefaulkner> happy to talk about this when i get back to work in the new year. but quickly, the intent here is to stop disallowing the use of roles on elements where it's actually preventing the ability for some developers to rectify poor markup. An alternate proposal i have also been working on is to more clearly indicate what roles MUST NOT be used by developers, vs those which belong more in the SHOULD NOT category (e.g., use the appropriate HTML element instead). article, and maybe some of the roles that Sarah mentioned, could very well belong to the 'should not' category... more on that when we speak though. — Reply to this email directly, view it on GitHub <#442 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCE3LKX623LM6STN5YNTWPRWYDANCNFSM6AAAAAATF3OCDM> . You are receiving this because you were mentioned.Message ID: ***@***.***> -- --RegardsSteve FaulknerWeb Standards messagingone t-shirt at a timehttps://www.etsy.com/uk/shop/HTMLZ |
scottaohara commentedJan 5, 2023
noting that steve and i talked this over. going to move forward with the further clarification proposal i had mentioned in my last comment, so this PR will be adjusted. |
incorporates feedback from steve and sarah. includes language "the following roles are allowed, but are NOT RECOMMENDED" to introduce new allowed roles which _can_ work depending on what's been built, but there are probably better ways to do this. This wording is also used in#446, and allows for us to indicate these changes per element, without having to restructure the entire table (as this can be the end goal, rather than trying to get all allowed roles for all elements updated at once).
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
closes#400
Updates allowances for the toolbar, menubar, menu, listbox, tablist, article, dialog and region roles to be used on the fieldset element.
Preview |Diff