-
Notifications
You must be signed in to change notification settings - Fork 133
editorial: refactor aria.js #2408
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
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Copies the proposed refactor from w3c/aria-common#106 at caf8e9e The PR has many separate commits for easier review.
Copies from w3c/aria-common#106 at caf8e9e The PR has many separate commits for easier review.
717ecc5
to
d167788
Compare
// if we are in a div, convert that div to a section | ||
// TODO: | ||
// a) seems to be always the case. | ||
// b) Why don't we author the spec this way? |
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.
Copied from w3c/aria-common#106 (comment)
Seems like we should. Anything that is not generated should just be in the static html. It's odd because this container has
id=<attributename>
on it for the url fragment, which probably should be generated, since it is the same as the pdef/sdef
const itemEntry = propList[title]; | ||
const dRef = item.nextElementSibling; | ||
dRef.id = "desc-" + title; // TODO: too much of a side-effect? | ||
dRef.setAttribute("role", "definition"); // TODO: ditto? |
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.
From w3c/aria-common#106 (comment)
this kind of stuff is a little weird to be adding here, it's not generated, it should just be in the html, it seems.
common/script/aria.js
Outdated
|
||
pdefsAndsdefs.forEach(populatePropList.bind(null, propList)); | ||
pdefsAndsdefs.forEach(populateGlobalSP.bind(null, propList, globalSP)); | ||
pdefsAndsdefs.forEach(generateHTMLStatesAndProperties.bind(null, propList)); |
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.
From w3c/aria-common#106 (comment)
Each of these new function names could maybe follow a bit better of conventions... my top preference is at at least to rename any function that changes or produces html to have the prefix
render...
, and to describe specifically what it is creating -- like,renderStatesAndPropertiesHeadings
instead ofgenerateHTMLStatesAndProperties
.Also, related, I guess the "populate" is fine, but I might use a word like
build...
for anything that is just producing a data structure. LikebuildPropList
andbuildGlobalStatesAndPropertiesList
and wherever else data is just being mined from the html and then rearranged.Also.... I know you are reusing variable names, but personally I would use no short hands -- so, "buildStateAndPropertyList" instead of "buildPropList". I guess "pdefs" and "sdefs" etc are ok, considering they are using in our spec.
but right now I still don't really understand why there is a
globalSP
andpropList
and the difference between these two things.. could they somehow be names a bit more clearly? Or are you trying to reuse these original names to make it easier to compare to the original script?
applicabilityText === | ||
"All elements of the base markup except for some roles or elements that prohibit its use"; | ||
const isDeprecated = | ||
applicabilityText === "Use as a global deprecated in ARIA 1.2"; |
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.
From w3c/aria-common#106 (comment)
I see, this is awful. Definitely, it makes more sense to start with a JSON object rather than looking for this text..
After the individual comments above, here's the closing comment from @spectranaut's review at w3c/aria-common#106 (review)
|
I'm interested and I will try to get to this before the editors' call next week. (fingers crossed) |
Following reviewer comments - render***: (primarily) generates HTML - build***: (primarily) extracts data for rendering & roleInfo.js - a few comments added or tweaked Respec output with only expected changes.
whoo!! I'll take a look tomorrow! |
Ok @pkra -- what do you think should be the goal here? How close of a review do you want at this stage? Should we just merge this, as an intermediate step, then decide how to clean up more in the future? I'm fine with merging it as is without a close review, as it's just clean up and the spec is the same. |
That would be my suggestion. That way, we can start fixing the bugs we already know about (cf. the editors' board's "blocked" column). And of course we should continue to refactor it (incl. changing the spec to simplify the post-processing).
I did my best to test that, diffing local respec builds before/after. The local respec builds would always fail to find the funders.html include so I checked against the gh-pages branch just now, too. |
I've moved the TODOs from the top card to #2501 |
Part of #2230
Partially moved from w3c/aria-common#106 at caf8e9e
From the original PR:
Much work to be done.
test.sh
runs respec on ARIA before/after applying aria.js changes and diffs the two resultsPreview | Diff