Steps to reproduce
Steps to reproduce:
- Visit https://bug1362999.bmoattachments.org/attachment.cgi?id=8877784
- Hover the purple div.
EXPECTED RESULTS: The relationship between the dotted red border and the purple square (if any) should be maintained when you hover.
ACTUAL RESULTS, in Edge 15:
- The initial layout has the dotted border shrinkwrapping the height & width of the purple canvas.
- BUT, when you hover (which tweaks ‘bottom’ on an ancestor & changes the available height), the dotted border isn’t correctly updated. The purple canvas gets its width + height resized, but its parent (the dotted border ) only gets its height resized, and it’s left with a stale too-small width.
Comments and activity
For reference, here’s a version of the testcase where the initial CSS & the hover CSS have been swapped: https://bug1362999.bmoattachments.org/attachment.cgi?id=8877787
So, for a browser engine to be consistent, the expectation is that this first testcase when the purple square is hovered…
…should match the default rendering of this second testcase:
And vice versa.
Changed Title from “Intrinsically sized div fails to update size, as child of abspos & parent of canvas or img” to “Percent-height intrinsically sized div fails to update size, as child of abspos & parent of canvas or img”
- Microsoft Edge Team
Changed Assigned To to “James M.”
Changed Steps to Reproduce
Changed Assigned To to “Bogdan B.”
Changed Assigned To from “Bogdan B.” to “Francois R.”
If instead of using bottom:310px -> bottom:200px you use height:90px -> height:200px, then you find out Chrome behaves as we do. It is not clear why you would want to behave differently in those two cases. In the reverse scenario Chrome behaves like Edge in both scenarios.
In the light of that statement, I am not confident this is something we actually want to change. Have you by chance found the relevant piece of specification that justifies your expectations? It would be useful to link it here.
Have you by chance found the relevant piece of specification that justifies your expectations?
My basic expectation here is: a page with a dynamic hover-triggered style change should render the same as if that style were there up-front. That is a general principle of CSS.
Based on that principle, this page with the div hovered…
…should look like the initial (no-hovering) rendering of this page:
And vice versa, as noted above. Does that make sense?
Chrome has some (different) bugs with dynamic updates on these testcases, too, so I wouldn’t trust their rendering too much (per https://bugs.chromium.org/p/chromium/issues/detail?id=719452#c8 ) – though it looks like they’ve got a fix that just landed on their trunk a day or two ago, per recent comments there. (They might be a more useful reference after that fix is in a shipping version – it’s not shipping in my “chrome dev” version installation yet)
(Sorry, the “Have you by chance…” statement at the beginning of my previous comment was meant to be a quote, which I am replying to in the rest of the comment. I must’ve not typed the right characters to make it render as a quote - apologies if that ended up making my comment less clear.)
I do agree the dynamic and static paths to the same style should render the same way. Let’s revisit when the issue has been fixed in Chrome;
Hi Francois – the Chrome version of this issue has been fixed and is viewable in Chrome Canary, and they now match my “expected results” here. Here’s a screencast I took with latest Chrome Canary (in a remote-desktop session, hence the 2 cursors):
Thanks for notifying!
- Microsoft Edge Team
Changed Status to “Confirmed”