Skip to content
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

modernizing aria.js #104

Open
pkra opened this issue Nov 10, 2023 · 7 comments
Open

modernizing aria.js #104

pkra opened this issue Nov 10, 2023 · 7 comments
Assignees

Comments

@pkra
Copy link
Member

pkra commented Nov 10, 2023

Besides #92 we have w3c/aria#1833 (which has fallen of the radar) and now w3c/aria#2073 suggesting changes in aria.js

Looking at the code, I wonder if there's interest in modernizing it a bit (and if there are any restrictions or W3C guidelines on this).

@pkra
Copy link
Member Author

pkra commented Nov 19, 2023

@jnurthen following our discussion, I was looking at ariaChild.js and from a rough comparison, they seem nearly identical. While aria.js seems to do extra stuff, I don't think the relevant if-checks would trigger in a child spec. The rest in differences looks like like two files going out of sync.

Does that sounds about right?

(If so then ideally we could refactor aria.js so that its parts are directly re-used in ariaChild.)

@pkra pkra self-assigned this Nov 19, 2023
@pkra
Copy link
Member Author

pkra commented Nov 19, 2023

A quick search confirms that ariaChild is really only used in dpub-aria, graphics-aria. So mostly we'd worry about dpub aria.

@pkra
Copy link
Member Author

pkra commented Nov 19, 2023

Another point from the discussion with @jnurthen: re skipindex. A quick search only finds aria.js being used in the aria spec.

The performance benefit of ?fast seems to be ~1s (of 3.5s). I'd suggest to throw it out.

@pkra
Copy link
Member Author

pkra commented Nov 20, 2023

Some thoughts about testability. As James had said, running respec locally is probably the right direction.

Here's what I've got so far

  • get a copy of index.html from the aria repo
    * but replace common/ paths to relative paths
  • run it through respec - $ npx respec --src index.html --out out.html ("RESPEC RUN")
  • grab a copy of the real spec - $ wget https://w3c.github.io/aria/ ("TRUE SPEC")
  • diff!

Now the diff has some expected differences

  • respec version no
  • relative path to css
  • only true spec has revision hash (as meta tag and json data)
  • different dates in json metadata
  • different publications dates (respec run will be current date)
  • only true spec has github contributors
  • respec run has two warnings about terms not actually referenced (-> file issue on aria)
  • only true spec has wg-active and funders (no idea why respec run can't pick up on the files even with changed paths)

So diffing these seems at least initially a feasible step for testing changes to aria.js

Next steps:

  • mess around with aria.js to see what happens
  • think about testing roleInfo.js

@pkra
Copy link
Member Author

pkra commented Nov 26, 2023

As suggested by James the other day, it should be sufficient to diff a local respec run before & after aria.js changes.

It looks like there will always be differences in the aria-wg-active.html includes -- they fail and seem to get a changing ID in the data-include-id attribute.

@pkra
Copy link
Member Author

pkra commented Nov 26, 2023

It looks like there will always be differences in the aria-wg-active.html includes -- they fail and seem to get a changing ID in the data-include-id attribute.

Oh, and for funders.html as well, of course.

@pkra
Copy link
Member Author

pkra commented Nov 27, 2023

As a way to explore what's going on, I've tried to extract/condense the pieces that generate roleInfo.js. I eventually ran into a roadblock. I couldn't figure out how some props are generated. I think it comes down to roletype's special treatment.

Since this didn't work out, I think I'll try for a naive refactoring next.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant