Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
Doing it during layout instead. This also has the nice side-effect of
no longer needing to do a full restyle when counter-style rules are inserted.
Differential Revision: https://phabricator.services.mozilla.com/D18343
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
Once again, calculating the amount of font size inflation isn't as expensive as
it used to be, but there's still no need to do it unnecessarily. The current
code does this unconditionally as part of computing a frame's margins
Additionally, calculating the font size inflation for frames that we don't
actually want to inflate also messes with the planned writing mode assertions
from bug 1428670. In some special cases (e.g. the scroll bars), a frame might
use a different writing mode (horizontal/vertical) than its parent without
creating a new font inflation flow root at the boundary. As long as we never
want to apply font size inflation for that frame this is okay, but if the margin
computation then runs the font inflation calculation regardless, we have a
problem.
Differential Revision: https://phabricator.services.mozilla.com/D7329
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
