-
Notifications
You must be signed in to change notification settings - Fork 788
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: Use virtualNode in hidden-content rule #404
Conversation
@@ -10,37 +10,44 @@ describe('hidden content', function () { | |||
} | |||
}; | |||
|
|||
function checkSetup (html, options, target) { | |||
fixture.innerHTML = html; | |||
axe._tree = axe.utils.getFlattenedTree(fixture); |
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.
indentation
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.
Annoying... this file had space/tabs mixed up when I started, and the editor didn't help :/
fixture.innerHTML = '<div id="target" style="display: none;"><p>Some paragraph text.</p></div>'; | ||
var node = fixture.querySelector('#target'); | ||
assert.isUndefined(checks['hidden-content'].evaluate.call(checkContext, node)); | ||
var params = checkSetup('<div id="target" style="display: none;"><p>Some paragraph text.</p></div>'); |
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.
indentation
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.
There are a bunch more of these below, not going to comment all of them
This check needs some actual shadow DOM support built in. It checks the parentNode. This means it needs to do:
Which we may want to generalize into a commons function so we can use it elsewhere You will also want to add shadow DOM tests for this check. |
24e8361
to
789d62e
Compare
@marcysutton @dylanb I've made a bunch of changes. Please review once more. |
@@ -1,13 +1,16 @@ | |||
let styles = window.getComputedStyle(node); | |||
const whitelist = ['SCRIPT', 'HEAD', 'TITLE', 'NOSCRIPT', 'STYLE', 'TEMPLATE']; | |||
if ( |
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 this weird style? No need to introduce new styles for if statements.
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 is a weird style? I've been writing multi-line if's like this since forever. The line was getting a bit long so I wrapped it.
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 notice that this style is used elsewhere in the code - but not consistently. I would prefer we stick to the original coding style for if statements and only break lines if they go above 80 characters - and also keep braces and parentheses on the same lines
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.
There are currently only 5 files that use this coding style - lets change them all back
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 agree that one line is more readable, as long as it doesn't run over 80-100 chars.
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 would like us to stick with an 80 char line length. My setup enlarged screen doesn't fit more than that on it. I also don't much like reading longer lines. They hare hard to scan. Anyway, I fixed the line, adding double indent.
We could consider something like Prettier, if we want to get a cleaner, more consistent format.
return parentNode.host; // Shadow root | ||
} | ||
} | ||
return null; // Root node |
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.
Thanks for all the comments! They're helpful. 👍
var checkContext = { | ||
_data: null, | ||
data: function (d) { | ||
this._data = d; | ||
} | ||
}; | ||
|
||
function checkSetup (html, options, target) { |
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.
Should we abstract this into a reusable utility so it doesn't have to get repeated in every test file needing Shadow DOM support?
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.
Not sure. I like having some test utilities to work with, but I don't much like just dropping a bunch of extra functions on the global object. I suppose we could create a /test/utils
dir, and have a global testUtils
object that has everything on it. Something like that?
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. Something we could import would be helpful–then if it needed additional code, we could change it in one place.
assert.isTrue(checks['hidden-content'].evaluate(node, undefined, virtualNode)); | ||
}); | ||
|
||
(shadowSupport ? it : xit)('works on elements in a shadow DOM', 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.
Crafty 👍
'use strict'; | ||
var getComposedParent = axe.commons.dom.getComposedParent; | ||
var fixture = document.getElementById('fixture'); | ||
var shadowSupport = document.body && typeof document.body.attachShadow === '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 know it's short, but this line seems like something we could abstract into a common test utility.
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 line is only shadow DOM v1, so it should only be used when we are sure that we don't need tests for shadow DOM v0
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.
@dylanb I'm not sure what you're suggesting. With Shadow DOM v0 I take it you mean the <content>
element and createShadowRoot()
method? Those are deprecated now, right? I hadn't considered it. I can see that we might need to write specific tests for our utilities to cover those cases, but I'm not sure our checks need them. Are you suggesting we do?
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.
The fact that there are different APIs for v0 and v1 make SD pretty difficult to work with. I'd be curious to hear how much test coverage we need for both.
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 the general approach should be that if we are relying on utils and commons that have been tested with both versions, then the tests for checks and rules themselves do not need both
No description provided.