The ResizeObserver isActive check (to answer "was there a resize") is defined here:
https://drafts.csswg.org/resize-observer/#dom-resizeobservation-isactive
...and right now, it says Return true if currentSize is not equal to this.lastReportedSize. (where each size is basically an inlineSize, blockSize coordinate pair.
Right now, the spec text doesn't explain how to handle the possibility that currentSize and lastReportedSize may have different writing modes. So implicitly, this would suggest that the writing-mode could change and no notification would be fired as long as "old inlineSize" == "new inlineSize". But this disagrees with what Chrome's implementation does in this circumstance.
This needs to be clarified & either Chrome or the spec need to be fixed to agree.
Here's a live example that demonstrates that Chrome disagrees with the spec:
https://jsfiddle.net/dholbert/ce094nxj/
Basically:
According to the spec, the observer must fire when I hover the first div, and it must not fire when I hover the second div. But Chrome's implementation does the opposite of this.
I don't have particularly strong feelings about which behavior is best, but this will influence our implementation strategy in Firefox so I want to try to get it right up front. @atotic, what do you think we should do here?
CC @BorisChiou @atotic @gregwhitworth
[edit: I initially misspelled Boris's nick; apologies to him and the other Boris who I mistakenly pinged.]
BTW, I believe @borischiou 's not-yet-landed patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1545239 does what the spec currently says to do (and disagrees with Blink).
i.e. @borischiou's patch makes us notify if the new inlineSize differs from the old inlineSize (and same for blockSize), regardless of whether these sizes are recorded under different writing modes.
This seems logical to me. If this makes sense and no serious spec edit is needed here (beyond a clarification), then I'm happy to stick with the specced behavior and consider this a chromium bug.
Nice edge case. Your interpretation is correct. I've filed a Chrome bug https://crbug.com/959008
OK, thanks!
@dholbert I'm not necessarily seeing the best place for a clarification for this. Is a note of using the logical coordinate (not sure of a better term) space sufficient under lastReportedSize?
I would suggest a Note below the isActive() documentation here:
https://drafts.csswg.org/resize-observer/#dom-resizeobservation-isactive
...perhaps saying something like the following:
"Note: in the above comparison between currentSize and this.lastReportedSize, the two sizes may have been captured under different writing modes (in which case one size's inlineSize would be a width whereas the other inlineSize would be a height). User agents should not concern themselves with this difference of writing-mode in the equality comparison -- a user agent should simply compare the two inlineSize values for equality, and the two blockSize values for equality."
Most helpful comment
[edit: I initially misspelled Boris's nick; apologies to him and the other Boris who I mistakenly pinged.]
BTW, I believe @borischiou 's not-yet-landed patch on https://bugzilla.mozilla.org/show_bug.cgi?id=1545239 does what the spec currently says to do (and disagrees with Blink).
i.e. @borischiou's patch makes us notify if the new
inlineSizediffers from the oldinlineSize(and same forblockSize), regardless of whether these sizes are recorded under different writing modes.This seems logical to me. If this makes sense and no serious spec edit is needed here (beyond a clarification), then I'm happy to stick with the specced behavior and consider this a chromium bug.