Closed dd8 closed 2 years ago
Hi @dd8,
Thank you for raising this issue. I'm going to re-review how these are working and, along with some other table element rules that need to be updated, make necessary edits.
@scottaohara I'm writing some unit tests to test our implementation against the spec wording - so may end up filing another issue.
I've also raised a couple of issues against the W3 validator: https://github.com/validator/validator/issues/1198 https://github.com/validator/validator/issues/1196
after digging into this more, I'm thinking the best course of action would be to file some really odd browser quirks and remove the MAY rules for this version of the spec. The SHOULD NOT and MUST rules would still apply, so we can keep those in and make further updates in the next version of the spec as needed.
@stevefaulkner, @patrickhlauke thoughts?
@scottaohara agreed
after digging into this more, I'm thinking the best course of action would be to file some really odd browser quirks and remove the MAY rules for this version of the spec. The SHOULD NOT and MUST rules would still apply, so we can keep those in and make further updates in the next version of the spec as needed.
@stevefaulkner, @patrickhlauke thoughts?
would removing that MAY clause not essentially result in:
colspan
when the element allows colspan
aria-colspan
if there's already a colspan
(but if you do, they need to match value)colspan
and aria-colspan
if there's a mismatch in valueessentially...making it pointless? (use colspan
; then, if you have good reason, double it up with aria-colspan
that says the same thing)
@patrickhlauke deleting my previous comment cause I was looking at the text for the next version rather than what's there now.
But yes, further updates are needed (and i'm working on them) but doing any more at this point would require getting updated implementations.
the should not now would indicate to developers that they're using aria needlessly since they already declared the native colspan.
the must not indicates that not only are they using aria needlessly, they're also just doing stuff wrong.
so, "pointless" as much as warning anyone about misuse of ARIA is pointless. But as mentioned, I think that's the best we can do for right now without removing it all and asking current implementations to revert changes / filing requests for new rule implementations.
jeez. i clearly need to call it a day. pushed up the wrong changes. will get this sorted tomorrow.
The
colspan
androwspan
attributes both default to 1 onth
/td
in the DOM and the table processing model if the attributes are absent.https://html.spec.whatwg.org/multipage/tables.html#forming-a-table https://html.spec.whatwg.org/multipage/tables.html#dom-tdth-colspan
https://w3c.github.io/html-aria/#att-colspan
Should the only allowed value be
aria-colspan=1
onth
/td
whencolspan
is absent? (to avoid conflicts with the default value of 1). Ditto witharia-rowspan
androwspan
.Edit: or put another way these both result in the same DOM, and the same rendered cell, but it looks like only the second one is prohibited with the current wording:
I think this is a bit different to attributes like
aria-required
vsrequired
, since I don't believe there's any way to change the table processing model with script.