-
Notifications
You must be signed in to change notification settings - Fork 783
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
Fix getSelector
for namespaced elements + introduce XHTML fixtures
#582
Fix getSelector
for namespaced elements + introduce XHTML fixtures
#582
Conversation
Not quite sure what I should do about the codacy checks, I tried to follow the code style from the other files. Please LMK if you want me to update the PR! |
Thanks @rdeltour! The codacy thing was just added but it conflicts with our jshint rules, so you can probably disregard for now. |
Apologies. I meant to delete the Codacy hook but I hadn't done so yet. Shouldn't turn up on new commits anymore. |
}); | ||
|
||
it('should return true on any document that is XHTML', function () { | ||
var doc = document.implementation.createDocument('http://www.w3.org/1999/xhtml', 'html', null); |
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.
test/xhtml/core/utils/is-xhtml.js
Outdated
@@ -0,0 +1,7 @@ | |||
describe('axe.utils.isXHTML', function () { |
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.
I don't think you need this file, it's redundant with test/core/utils/is-xhtml.js
.
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.
see explanation in the general comment below
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.
specifically, this will test that the document
from the current fixture is XHTML. I copied the pattern from aXe's pre-existing is-html5.js
tests
@@ -0,0 +1,24 @@ | |||
|
|||
describe('axe.utils.getSelector', function () { |
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.
It's a little strange to have a test for get-selector
duplicated in another directory. Can you make it work in the existing core unit tests by creating a document like in test/core/utils/is-xhtml.js
?
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.
see explanation in the general comment below
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.
This makes sense, although I'd suggest we move it to tests/integrations
instead.
Thank you @marcysutton for the review! re:
and
let me try to explain why I did this: As far as I understand, all aXe’s tests are run in an HTML fixture, injected in the But for some tests, I needed to be in an XHTML context. So, I created another fixture. All the tests in the The idea is that the For instance, if If the XHTML-specific tests were in the same directories as their HTML counterparts, they'd need an option to be ignored in the regular HTML-fixture-based tests, and enabled in the XHTML-fixture-based tests. I thought for now it would be clearer to just have to separate directory structures. I hope it's clear 😅 Alternatively, another option would actually make aXe run all the existing tests both in HTML and XHTML environments. That would provide better coverage but would basically duplicate the testing time, so I thought that would be a bit aggressive. |
lib/core/utils/get-selector.js
Outdated
@@ -130,7 +129,9 @@ const createSelector = { | |||
* recognize the element by (IDs, aria roles, custom element names, etc.) | |||
*/ | |||
function getElmFeatures (elm, featureCount) { | |||
const nodeName = elm.nodeName.toLowerCase(); | |||
const nodeName = escapeSelector(axe.utils.isXHTML(document)? |
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.
We could probably just check this once at the top of the file and keep the boolean around instead of having to call this every time this method runs.
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.
We could probably just check this once at the top of the file and keep the boolean around
where would be the best place to memoïze the boolean value? Using a const
at the top of the file won't work.
Calling the function shouldn't be too costly in any case, so maybe it's too early an optimization?
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.
This could potentially create many thousands new elements, so I do think this is relevant. Why wouldn't a const up top work? Alternative the result can be stored in utils.isXHTML itself.
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.
Why wouldn't a const up top work?
I tried and got an error when running tests :/ But I haven't tried hard nor dug deep into the issue.
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.
@rdeltour Can you update this according what we discussed at TPAC?
if (!doc.createElement) { | ||
return false; | ||
} | ||
return doc.createElement('A').localName === 'A'; |
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.
What does this do on JSDOM? We should make sure we don't accidentally treat JSDOM as XHTML.
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.
Yes, confirmed to work on JSDOM.
@@ -0,0 +1,21 @@ | |||
describe('axe.utils.isXHTML', function () { |
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.
@rdeltour Have you tested this with Edge and IE? This seems like one of those things that might not work across the board :)
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.
Confirmed to work on Edge and IE too.
The logic relies on the fact that HTML parsers lower-case the tag names when parsing. It's been suggested as a possible reliable option by Anne van Kesteren on Twitter.
@@ -0,0 +1,24 @@ | |||
|
|||
describe('axe.utils.getSelector', function () { |
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.
This makes sense, although I'd suggest we move it to tests/integrations
instead.
Gruntfile.js
Outdated
@@ -281,6 +281,21 @@ module.exports = function (grunt) { | |||
} | |||
} | |||
}, | |||
xhtml: { |
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.
I think it would be easier to move this xhtml test into tests/integrations
. That way we don't have to do all this scaffolding work. WDYT?
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.
these are not strictly speaking integration tests, but if you feel that will fit better there (and disturb less the code organization), sure! let me know.
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.
Yep, I think so.
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.
ok, I'll try to update the PR accordingly (I'm currently on vacation)
@rdeltour Any updates on this PR? |
I was just working on it, in fact 😀. If time allows I will update it this afternoon. |
@rdeltour That's good to know. We are planning to release 2.6 today and I'd like to have this in if we could. Otherwise it'll have to wait for 3.0. |
936184f
to
083b701
Compare
- by default, ensure the nodename is escaped - for XHTML documents, only use the local name Replaces dequelabs#566 Closes dequelabs#563
…aced XHTML element
083b701
to
69a3950
Compare
@WilcoFiers ready to be reviewed! |
) * feat(utils): add function `isXHTML` to test if a document node is XHTML * test(utils): add a test for `axe.utils.isXHTML` on an XHTML document * fix(getSelector): improve selectors for namespaced elements - by default, ensure the nodename is escaped - for XHTML documents, only use the local name Replaces #566 Closes #563 * test(getSelector): add a test for `axe.utils.getSelector` on a namespaced XHTML element
…s/shadow-dom (dequelabs#582) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Replaces #566
Closes #563