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

Fix: Use virtualNode in hidden-content rule #404

Merged
merged 7 commits into from
Jul 10, 2017
Merged

Conversation

WilcoFiers
Copy link
Contributor

No description provided.

@WilcoFiers
Copy link
Contributor Author

Should resolve #392 and #395.

@@ -10,37 +10,44 @@ describe('hidden content', function () {
}
};

function checkSetup (html, options, target) {
fixture.innerHTML = html;
axe._tree = axe.utils.getFlattenedTree(fixture);
Copy link
Contributor

@dylanb dylanb Jul 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation

Copy link
Contributor Author

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>');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation

Copy link
Contributor

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

@dylanb
Copy link
Contributor

dylanb commented Jul 3, 2017

This check needs some actual shadow DOM support built in. It checks the parentNode. This means it needs to do:

	parent = (element.assignedSlot) ? element.assignedSlot : element.parentNode;
	if (parent.nodeType === 11) {
		parent = parent.host;
	}

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.

@WilcoFiers WilcoFiers force-pushed the sd/hidden-content branch from 24e8361 to 789d62e Compare July 5, 2017 16:26
@WilcoFiers
Copy link
Contributor Author

@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 (
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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 () {
Copy link
Contributor

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';
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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

@dylanb dylanb merged commit f8f7344 into shadowDOM Jul 10, 2017
@marcysutton marcysutton deleted the sd/hidden-content branch July 21, 2017 16:55
mrtnvh pushed a commit to mrtnvh/axe-core that referenced this pull request Nov 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants