Meeting minutes
synonyms
summary of discussion so far: we should link from one role section to the other
summary of current discussion: how easy/hard should it be to find the synonym we don't want used?
issue for this topic: w3c/
mcking: the non-preferred section links to the other
mcking: in characteristics table, where name is prohibited on role `none`, do we also role `presentation`?
mcking: how does this effect aria.js
jamesn: would the easier way to do this by adding an extra script to post process
jamesn: to fix the few links
mcking: role reference to synonym to instead of PR
spectranaut_: if you link to the synonym, if will just redirect you to the other role
spectranaut_: so it doesn't seem like a problem to me
PR/Merge process - next steps after deep dive?
spectranaut_: I was going to update the process document with more clarity on the process, re james craig's confusion
mcking: also we need to discuss next steps for the monorepo, so resolve james craig's concerns
spectranaut_: anyone have experience with combining git repos
(resounding silence)
mcking: but we don't want to combine issues, also, there is the challenge with the history
peter: you can merge repos and keep the histories
peter: they are working on different files/subfolders
spectranaut_: we were discussing keeping the other repos open for issue tracking, alone
peter: you can have a PR that closes issues in a different repo
peter: I'm worried that we have repos that we don't officially maintain, like svg-aam and dpub-aria
peter: we can't just put those into our monorepo
mcking: most of our issues are only related to core-aam and html-aam and accname
peter: james wants everything done in one PR
spectranaut_: if we build a pr-preview for a PR that has changes to core-aam and aria, will the links between the two of them be links to the pr-preview? I think not
peter: right, interlinks won't work, but PR preview will link to all of the specs revised by the PR
mcking: sounds feasible to make those links work
jamesn: maybe, but it might be too hard
mcking: right now we uses classes for those links to accname. so if you are linking something in accname in the ARIA spec... it depends on how you build the preview
jamesn: we don't build it, we use pr-preview, respec runs, and the code to generate links happens in there
james: we want to remove the special linking that we do, the way we link between specs, there is a ton of code to make sure the editor drafts link to editors draft
jamesn: those concepts don't exist. maybe we should just use xref, and export our definitions, we can use standard respec
jamesn: if we use xref, the standard, then we have no way to interlink the specs
peter: is there agreement that if we at least have preview links, that would be a sufficient first step?
mcking: I don't know if it would resolve the issue james craig has for implementors
mcking: you can't just send the implementor this one link to this preview
mking: if that aria actions preview has a link to core-aam in it... you can't use the link to core-aam, you have to hunt down the relevant information using this preview. it sounds very complicated.
jamesn: it sounds like need to talk to james and see if it will solve his problem, if it doesn't, we need to investigate more
mcking: doesn't seem like there is a ton of value in a mono repo other than having a single PR, doesn't add any value other than that
jamesn: it allows someone to review the PR with all the changes in one place. I think it makes the review and maintenance processes easier.
mcking: so there is a huge advantage to us, the working group members
mcking: maybe some advantage to the implementor
roll out prettier setup - tracked via aria-common#99
peter: should i merge these?
jamesn: yeah it is scary
ISSUE: w3c/
peter will open a PR on aria-html
jamesn will review the change on svg-aam
retiring contributors.md across specs - tracked via aria-common#103)
<pkra> w3c/
matt garish doesn't like it for dpub
jamesn: he is welcome to maintain his own
peter: it's fine if they don't want to use our automated stuff....
jamesn: I think it's possible to only add stuff after a certain date... I could make an enhancement to respect to do that
jamesn: for example, you would want, from this version forward
spec markup for advice for AT (jnurthen)
to bug james :)
modernizing aria.js (aria-common#104)
peter: after talking to james, I created the issue... I thought I'd make some progress but I haven't
peter: I'm going to start refactoring just to make it more readable.. so intertwined... hard to understand how things work
ISSUE: w3c/
peter made notes in the issue
peter: I have a dream where we have less of this data extraction and html stuff
peter: cleaner more understandable code
jamen: we know what the logic should be
jamesn: we start with list of roles, a hierarchy, assign states and properties as we go down the hierarchy
peter: some things like alert, there are no local props, it gets them through parental properties -- on structure and role type, its hard to compare whats currently in the role info.js info file and what the spec would generate...
(scribe is not really catching this)
peter: it is fun!