-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
core(tap-targets): don't exclude visible position absolute elements from audit #7778
Conversation
This reverts commit 90404ff.
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.
high level looks pretty good! did you have the stats on sites that start failing more now in the issue or was that something else I was remembering?
I did a few of those recently, so you're probably thinking of something else. But I do plan to get some stats for this one too. |
DZL, do a barrel roll! |
Here are some examples of how scores are impacted. Generally it looks good, not just in terms of including position absolute elements, we're also detecting much better whether elements are visible. Do you think we need to do anything about the For 100 sites I tested there's a change of ±5.7 point on average. Positive and negative changes even out overall and there's a drop of just over 1 point in the average score. |
@patrickhulce Should be good for some more review now 🙂 |
DZL is done! Go check it out http://lh-dzl-7778.surge.sh |
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.
LGTM!
<div style="position: relative"> | ||
<a style="display: block; position: absolute; top:0; height: 40px; width: 40px;">inner</a> | ||
<a style="display: block; height: 100px; width: 100px; background: yellowgreen">outer</a> | ||
<!-- The left tap target has a large client rect that would normally overlap with the right tap 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.
😍 LOVIN' these tests :D
const SCORE_FACTOR = 0.89; | ||
return Math.floor(PASSING_TAP_TARGETS / TOTAL_TAP_TARGETS * SCORE_FACTOR * 100) / 100; | ||
return Math.round(passingTapTargets / totalTapTargets * SCORE_FACTOR * 100) / 100; |
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.
a tad worried by how much logic ends up living in our expectations, but I sympathize with the tedium of updating these and would rather have it be more precise 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.
a tad worried by how much logic ends up living in our expectations, but I sympathize with the tedium of updating these and would rather have it be more precise so 👍
I think this might be going too far in this direction :/ It's one thing when it's broken down but still defined by constants, but since this is pulling live from the test file, it would be difficult to notice e.g. if we broke one of the overlapping tap target examples in the test page. So long as it also no longer matched the regex it would still pass and we wouldn't notice we were losing coverage.
It's also nice to have a place we can point to with "here's what we expect a failing/real value for this audit to look like", and with this approach the only way to do that is to put in a breakpoint and open up a debugger.
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.
left a couple real comments and some nitpicky ones that came up as I was reading :)
Higher level, though: to sidestep the need for switching on/off pointer-events
, did you consider document.elementsFromPoint()
? Since the returned array is in paint order, seems like it would be possible to shift
off any starting elements that are fixed or sticky?
Or just not feasible?
const SCORE_FACTOR = 0.89; | ||
return Math.floor(PASSING_TAP_TARGETS / TOTAL_TAP_TARGETS * SCORE_FACTOR * 100) / 100; | ||
return Math.round(passingTapTargets / totalTapTargets * SCORE_FACTOR * 100) / 100; |
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.
a tad worried by how much logic ends up living in our expectations, but I sympathize with the tedium of updating these and would rather have it be more precise so 👍
I think this might be going too far in this direction :/ It's one thing when it's broken down but still defined by constants, but since this is pulling live from the test file, it would be difficult to notice e.g. if we broke one of the overlapping tap target examples in the test page. So long as it also no longer matched the regex it would still pass and we wouldn't notice we were losing coverage.
It's also nice to have a place we can point to with "here's what we expect a failing/real value for this audit to look like", and with this approach the only way to do that is to put in a breakpoint and open up a debugger.
@@ -208,13 +204,15 @@ function getRectAtCenter(rect, centerRectSize) { | |||
/** | |||
* @param {LH.Artifacts.Rect} rect | |||
*/ | |||
/* istanbul ignore next */ |
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.
same with this and getLargestRect
, which are called from the tap-targets.js
audit?
Co-Authored-By: mattzeunert <matt@mostlystatic.com>
Co-Authored-By: mattzeunert <matt@mostlystatic.com>
…gleChrome/lighthouse into tap-target-position-absolute
No I didn't consider it, that's a good idea! I tried it now and |
DZL is done! Go check it out http://lh-dzl-7778.surge.sh |
@brendankenny want another pass or is this g2g? |
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 have some lingering doubts about modifying the DOM like this, but the increased functionality and tests are great, so lets land and then take a look at it again in the future
Summary
Also catching this now:
Related Issues/PRs
Closes #7365