Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
Specifically:
For "bullets", i.e. 'list-style-type:disc|circle|square|
disclosure-closed|disclosure-open', we use a built-in font
(-moz-bullet-font, which has glyphs for those symbols + space) to
retain mostly backwards compatible rendering for those. Authors may
override that with an explicit 'font-family' ::marker style though.
We also use this font for 'list-style-image' in case it would
fallback to one of the above when the image fails to load (so that
we get the same width space).
When the -moz-bullet-font is used we also set 'font-synthesis' to
avoid synthesizing italic/bold for this font. Authors may override
this with an explicit ::marker declaration.
We also set 'letter-spacing' and 'word-spacing' to the initial value
for bullets for web-compat reasons. Again, authors may override
this with an explicit ::marker declaration. (This breaks backwards-
compat slightly but makes us compatible with Chrome. We used to
ignore these for list-style-type:<string> too.)
Differential Revision: https://phabricator.services.mozilla.com/D111693
Otherwise we assert due to the styles being different from the cached
ones, but it doesn't matter as these don't influence Gecko scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D117147
This results in lots of new WPT test passes.
There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.
Depends on D117331
Differential Revision: https://phabricator.services.mozilla.com/D117332
So we update d property in the style system as well. This makes sure we
have the correct computed style and the correct rendering result.
Differential Revision: https://phabricator.services.mozilla.com/D115570
Support fit-content for preferred size, min size, and max size. This
patch only implement the style system. For layout part, we will do that
in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D107161
Those can't be ordered at specified / computed value time, since the
percentage basis could be negative.
Needs tests of course, running through try atm.
Differential Revision: https://phabricator.services.mozilla.com/D115591
This prevents incorrectly reusing cached results when the contents go
away and new contents are allocated with the same address.
Note that these keep alive transitively everything else under them, so
all other medialist keys don't need this.
By making this a proper hashmap it should also improve cache lookup
times if the cache grows too big.
Differential Revision: https://phabricator.services.mozilla.com/D115202
They are not. The serialization code already checks if the result is
empty, which can happen for other reasons. This makes the code a bit
more resilient to misuse.
Differential Revision: https://phabricator.services.mozilla.com/D115133
As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
It's the wrong pseudo-class name! Plus, it's not really needed, just
override the page styles temporarily.
Remove the pseudo-class, since it's its only remaining usage.
Differential Revision: https://phabricator.services.mozilla.com/D113374
