New rule: Content triggered on hover is hoverable (ep1s13) #1396
Conversation
carlosapaduarte
added
Rule
carlosapaduarte
changed the title
|
|
carlosapaduarte
requested review from
adilsofficial,
ajanec01 and
daniel-montalvo
|
@WilcoFiers @kasperisager @ShadowBB |
pages/glossary/overlap.md
Outdated
| - DOM tree | ||
| --- | ||
|
|
||
| [Bounding boxes][] A and B _overlap_ if at least one point inside box A has the same [left][left coordinate] and [top coordinates][top coordinate] of one point inside box B. |
There was a problem hiding this comment.
Points don't have a left / to pcoordinate. I would suggest you define this as any corner of element A is between the left and right, and top and bottom edges of element B, or visa versa.
There was a problem hiding this comment.
Correct. Thanks for the suggestion.
pages/glossary/center.md
Outdated
| - The [x coordinate][] is equal to the [left coordinate][] of the [bounding box][] plus half of the [width][] of the [bounding box][] (rounded down); and | ||
| - The [y coordinate][] is equal to the [top coordinate][] of the [bounding box][] plus half of the [height][] of the [bounding box][] (rounded down). |
There was a problem hiding this comment.
I think this is enough:
| - The [x coordinate][] is equal to the [left coordinate][] of the [bounding box][] plus half of the [width][] of the [bounding box][] (rounded down); and | |
| - The [y coordinate][] is equal to the [top coordinate][] of the [bounding box][] plus half of the [height][] of the [bounding box][] (rounded down). | |
| - The [x coordinate][] is equal to the [left coordinate][] of the [bounding box][] plus half its [width][]; and | |
| - The [y coordinate][] is equal to the [top coordinate][] of the [bounding box][] plus half its [height][]. |
pages/glossary/adjacent.md
Outdated
| - DOM tree | ||
| --- | ||
|
|
||
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 point from one point in box B. |
There was a problem hiding this comment.
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 point from one point in box B. | |
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 [CSS pixel[] from one point in box B. |
pages/glossary/adjacent.md
Outdated
| - DOM tree | ||
| --- | ||
|
|
||
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 point from one point in box B. |
There was a problem hiding this comment.
Problem with this definition is that it also includes overlapping elements.
pages/glossary/adjacent.md
Outdated
|
|
||
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 point from one point in box B. | ||
|
|
||
| The distance between two points is obtained by adding the horizontal distance between the two points with the vertical distance between the two points. |
There was a problem hiding this comment.
That doesn't sound right. So something with x:0,y0 has a distance of 2 to x:1,y:1? I don't think we should do that.
There was a problem hiding this comment.
What don't you think we should do? Consider (0,0) and (1,1) to not be adjacent or that the distance between them should not be 2? Or both?
In my opinion they are not adjacent, but its just an opinion and I don't feel too strong about that.
But I do feel the distance is 2 pixels (I have to move 1 pixel right and 1 pixel down to get from one point to the other). Pixels must be integer, therefore it cannot be the square root of 2.
There was a problem hiding this comment.
I don't think they are adjacent, and I don't think the distance is 2, it's 1.4px. The distance between two point is a straight line, what you're calculating is something else. Not sure what the right phrase for it is... or why using distance would be a problem here. Keep in mind that things don't have to be whole pixels distant from each other. Something can be 1/3rd of a pixel away from something else.
There was a problem hiding this comment.
I was trying to come up with a distance metric that would always result in whole pixels. But, you're right, for distance we don't need to require that. I'll delete the definition of distance from this definition.
| - DOM tree | ||
| --- | ||
|
|
||
| The _content that becomes visible_ is the [root][] element, if one exists, of the [tree][] that contains all elements that, as result of an [event][] [firing][], meet any of the following: |
There was a problem hiding this comment.
I'm not too sure what is going on here. How can a tree not have a root element? Do you maybe mean to find the closest common ancestor? How do I know that something is the "result of an event firing"? I don't think we should try to figure out if something is or isn't the result of an event. I think it's sufficient to determine that the content appears within half a second of firing the event, and that the content part of a region that updates without user input.
There was a problem hiding this comment.
The "if one exists" was meant to apply to the tree, not the root element. My bad.
And I'll update to use the half a second instead of resulting from. That's definitely more testable!
| - the element has [visible text content][] and is added to the [web page][] where the [event][] was [fired][firing]; or | ||
| - the element [attributes][]' [values][] are modified in a way that cause some or all of its [text nodes][] to become [visible][]. |
There was a problem hiding this comment.
Visible text content isn't bound to the closest ancestor. Any text nodes added to the page results in the HTML element having visible text content added.
How about something like:
| - the element has [visible text content][] and is added to the [web page][] where the [event][] was [fired][firing]; or | |
| - the element [attributes][]' [values][] are modified in a way that cause some or all of its [text nodes][] to become [visible][]. | |
| has visible text content that did not exist on the page prior to the event firing. |
There was a problem hiding this comment.
We don't need to worry about the bounding because this tree only contains new elements (therefore elements that were there already are not considered) and elements that have had their attributes modified (therefore if their text nodes changed without a change in their attributes, they are not considered)
|
@WilcoFiers this is ready for another round |
pages/glossary/adjacent.md
Outdated
|
|
||
| [Bounding boxes][] A and B are _adjacent_ if at least one point from box A is at the distance of 1 point from one point in box B. | ||
|
|
||
| The distance between two points is obtained by adding the horizontal distance between the two points with the vertical distance between the two points. |
There was a problem hiding this comment.
I don't think they are adjacent, and I don't think the distance is 2, it's 1.4px. The distance between two point is a straight line, what you're calculating is something else. Not sure what the right phrase for it is... or why using distance would be a problem here. Keep in mind that things don't have to be whole pixels distant from each other. Something can be 1/3rd of a pixel away from something else.
pages/glossary/center.md
Outdated
| - The [x coordinate][] is equal to the [left coordinate][] of the [bounding box][] plus half its [width][] (rounded down); and | ||
| - The [y coordinate][] is equal to the [top coordinate][] of the [bounding box][] plus half its [height][] (rounded down). |
There was a problem hiding this comment.
Why do you want this rounded down? What's the use of that?
There was a problem hiding this comment.
I was ensuring once again that coordinates were whole numbers. But they don't need to be (they're doubles).
|
|
||
| The _content that becomes visible_ is the [root][] element of the [tree][], if a [tree][] exists, that contains all elements that, after half a second of an [event][] [firing][], meet any of the following: | ||
|
|
||
| - the element did not exist on the [web page][] prior to the [event][] [firing][] and has [visible text content][]; or |
There was a problem hiding this comment.
I think there is a fundamental problem in this. If I have an event rerenders the page, all elements are new, even if nothing changed. body.innerHTML = body.innerHTML will do that. Modern frameworks try to avoid unnecessary rerenders, but there is a lot of code on the web that rerenders components, irrespective of if something actually changed.
I think we need to define this in a way that works with rerenders. I took a stab at doing that just for text nodes, here's what I've come up with. That isn't enough, but I hope it gets helps move this forward.
A text node is considered to be _visible after an event_ if both of the following of the following are true:
- A tick before the event, there was no [visible][] text node with the same node value; and
- 500 milliseconds after the [event][] [firing][], there the text node is [visible][].There was a problem hiding this comment.
I don't think that works because it requires that there are no text nodes with the same node value. If the new content includes a text node with the same value of an already present text node, then it will miss the new content.
I'll try to think of a solution for this...
There was a problem hiding this comment.
Following your suggestion, check if you think that what I came up with works
|
|
||
| The _content that becomes visible_ after an [event][] [firing][] is any element for which all of the following is true: | ||
|
|
||
| - 500 milliseconds after the [event][] [firing][] the element has [visible text content][]; and |
There was a problem hiding this comment.
We need to capture an assumption that content on hover will appear within 500ms.
| The _content that becomes visible_ after an [event][] [firing][] is any element for which all of the following is true: | ||
|
|
||
| - 500 milliseconds after the [event][] [firing][] the element has [visible text content][]; and | ||
| - a tick before the [event][] [firing][] there was no element with the same [descendant text content][] that the element has after the [event][] [firing][]; and |
There was a problem hiding this comment.
Seems to me like this would apply to elements that update their content too. If I have a button that changes its text on hover, it 1. has visible content after the event. and 2. does not have the same descendant text content. Additionally, descendant text content does not take shadow DOM into account.
| - DOM tree | ||
| --- | ||
|
|
||
| [Bounding boxes][] A and B are _adjacent_ if they do not [overlap][] and at least one point from box A is at the Euclidean distance of 1 [CSS pixel][] from one point in box B. |
There was a problem hiding this comment.
I'm a little nervous about this being exactly 1px with no margin of error. I think we should include anything less than 2, and greater than 0.
Rule partially checking SC 1.4.13 (the hoverable part of SC 1.4.13)
Blocked: waiting for decision on how to handle states in rules
This will require a 2 weeks Final Call (new rule)
Pull Request Etiquette
How to Review And Approve