Meeting minutes
[updates?] [daniel] aria#2374 Enabling suggestions to update pull request branches
spectranaut_: decision is to do this. But rebase has to be done manually via the button; only merging main is possible automatically.
jamesn: could you recap what editors have to do ?
dmontalvo: whenever the base branch is updated, the PR will show the "update branch" button.
… then you can merge the base branch or rebase via the UI.
jamesn: and we'll have a procedure to make sure we do that.
dmontalvo: we should have something in the doc to say what we expect to happen.
pkra: doesn't squashing mean it doesn't matter whether we merge or rebase?
dmontalvo: good point. we can always disable it again if we experience issues with this process.
pkra: close via docs PR?
dmontalvo: yes, I'll take it on.
[new] aria #1862 Remove aria-expanded from listbox
pkra: I was wrong about this being new but it resurfaced on my end going through the labeled issues.
… should we have a separate issue?
spectranaut_: probably. it's been a long time.
pkra: there was the recent issue on deprecation notices for ARIA 1.2
jamesn: I feel like we don't need to do anything about this.
… if we remove or add normative guidance.
… this is just "no longer allowed on this".
… we only ever did deprecation for the global properties. That seemed like an exception.
spectranaut_: did we not decide so in that meeting?
pkra: I don't recall. I thought it's just to discuss.
jamesn: what do we benefit from this?
spectranaut_: oh, wilco specifically asked for deprecation instead of removal.
jamesn: but that holds for virtually all properties that don't have an effect.
spectranaut_: so we explicitly response to say we don't?
jamesn: I think so. Otherwise we will limit ourselves wth future changes.
… cf. aria-grabbed/dropped. We didn't have another use case for them. But this never had a use. It's just an error.
dmontalvo: if we say no, we should explain why.
… and this sounds reasonable to me.
jamesn: yes, we should have good reasons why we deprecate something or not. We only ever did that for the globals.
scotto: the globals didn't do anything, really.
jamesn: right, mostly unexpected role presentational which wasn't great.
… the other reason we deprecated them was so UAs may still expose them.
… but this change seems fine in this respect.
pkra: jamesn suggestion seems fine to me. But I don't have strong feelings.
spectranaut_: can you write a comment?
… we seem to be in agreement. What are next steps?
jamens: I'll write a comment.
pkra: maybe add something to the process docs on deprecation.
spectranaut_: I'll add it to the agenda for this week so we can gather input from the wider group.
[new] [peter] [aria#2230](w3c/aria#2230
pkra: basically, what I wrote in the issue. we can't have the history but we don't need it. I made a PR for the aria.js refactor.
… the old repo still pushes to css-aam and math-aria. Not sure we want that if we stop maintaining common.
… I'l llook into ESLint later.
[urgent?] [james] aria#2226 remove spec specific css or inline it
pkra: just bringing this up after we had 3 duplicats.
… any takers.
… I'll try to get to it.
[wrap up?] [scott] aria #2228 : re-direct "moved" PRs after merge (html-aam left with 1 PRs)
spectranaut_: we talked about it at the beginning of the meeting. I'll get to it.
spectranaut_: random: we have a lot of editorial issues. Should we do another hackathon? F2F or remote?
pkra: I'm all in for remote.
jamesn: local only bay area.
spectranaut_: F2F is probably harder.
jamesn: probably focus on TPAC since it's in Kobe.
spectranaut_: jan, feb, march?
jamesn: csun is in march.
spectranaut_: ok I'll suggest a few times.
scotto: random topic aria-in-html. Should it move to the monorepo?
jamesn: will it ever have dependencies where we'll want a single PR?
scotto: I suspect probably not
jamesn: then I'd prefer separate.
scotto: right. I wouldn't want PRs being held up because I'm waiting for something.
jamesn: makes sense.
scotto: ok. on a related note. aria-in-html has these strange purple boxes. Those came from web apps group requiring these styles for review.
… however, those styles are clunky for inline changes.
… I kept doing this because that was WAWG process. Could we remove them now?
dmontalvo: we can update the spec. Once in our charter period we will have to do a snapshot. Then we will have to document changes. I don't think the CSS is accessible. We need a comprehensive changelog though.
scotto: right. I've made sure we have a good changelog.
… I pushed back against an automated changelog with WAWG. I'm rather very explicit about it.
dmontalvo: +1
scotto: but removing the styles would be nice.
jamesn: do you want to remove the class or the associated styles?
scotto: good point. I don I an modify the styles.
… having a way to toggle it on may be useful but I'm not sure.
jamesn: activating some styles might be useful.
scotto: ok. On a related note: do we have to do that with ARIA once it's a living standard.
jamesn: I don't think so.
… the styles are not accessible and something semantic would just be noisy.
scotto: yes, especially inline.
jamesn: we can bring that back to W3C.
dmontalvo: I think changelog should be the answer to that.
… but we'll have to see