Another preliminary change to simplify the `vertical-align` shorthand conversion (D277725). It introduces a new enum called `HTMLAlignValue` designed to avoid the problem of having different CSS enum types in the attribute mappings for the `align` attribute.
In the process of implementing this, I found that the existing parsing and mapping of this attribute was convoluted and messy, with it not being immediately clear within a single element type how exactly the attribute value mapped to the CSS properties. (For example, the "div alignment" mapping was used for table elements, too, even though they had different parsing.) I added additional mapping methods so that each parser has a 1:1 correspondence with a mapper to avoid this confusion.
Try for this change: https://treeherder.mozilla.org/jobs?repo=try&revision=04da2213b1818b7b0285563f430871e48ad0d3da
Differential Revision: https://phabricator.services.mozilla.com/D277792
Another preliminary change to simplify the `vertical-align` shorthand conversion (D277725). It introduces a new enum called `HTMLAlignValue` designed to avoid the problem of having different CSS enum types in the attribute mappings for the `align` attribute.
In the process of implementing this, I found that the existing parsing and mapping of this attribute was convoluted and messy, with it not being immediately clear within a single element type how exactly the attribute value mapped to the CSS properties. (For example, the "div alignment" mapping was used for table elements, too, even though they had different parsing.) I added additional mapping methods so that each parser has a 1:1 correspondence with a mapper to avoid this confusion.
Try for this change: https://treeherder.mozilla.org/jobs?repo=try&revision=04da2213b1818b7b0285563f430871e48ad0d3da
Differential Revision: https://phabricator.services.mozilla.com/D277792
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
We don't need to parse 'width' on <tr> because we never use the parsed value for
anything and neither does the spec.
We don't need to parse 'charoff' on <col> because we never use that for anything
either, and neither does the spec.
Differential Revision: https://phabricator.services.mozilla.com/D36128
The spec allows non-integer values, but we don't have a good way to store them
in nsAttrValue yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1561440
HTMLTableCellElement::MapAttributesIntoRule can now call
MapImageSizeAttributesInto instead of manually mapping width and height, because
0 values (which it was excluding before) are now excluded at attribute parse
time.
For 'width' on HTMLTableElement I kept our old behavior for 0, which matches the spec
but not Safari or Chrome.
For 'height' on HTMLTableElement I kept our old behavior for 0, which matches
Safari and Chrome but not the spec. https://github.com/whatwg/html/issues/4715
tracks a possible spec change.
Same thing for 'height' on HTMLTableRowElement.
Same thing for 'width' on HTMLTableColElement.
The ParseImageAttribute call in HTMLMediaElement is not needed, because
HTMLAudioElement does not map any of those to style and HTMLVideoElement only
maps width/height, which it already parses.
Differential Revision: https://phabricator.services.mozilla.com/D36127
This was useful because nsRuleData in the old style system may not hold
all the data, but the only subclass ServoSpecifiedValues is always able
to hold any data, and thus passes NS_STYLE_INHERIT_MASK to mSIDS. Given
this, this method and mSIDs seems to be useless and can be removed.
MozReview-Commit-ID: 4vWcV4DRS2i
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
The spec recently changed to match browsers better. There's currently
not much interop in exact details of how this work. This brings us in
line with the spec except for the limit of 1000 on the span attribute.
The added textarea failures are spurious, because I'm not updating our
local tests in this commit. The new tests are submitted upstream at
<https://github.com/w3c/web-platform-tests/pull/3518>.
MozReview-Commit-ID: 1L8aUtF47Qi
Sylvestre Ledru