| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
| |
I got very anxious about making sure I included VARIANT_OPACITY in all the places VARIANT_NUMBER was included to make sure it couldn't possibly break unexpectedly, and that led to me accidentally breaking a mechanism that prevented percentages from serializing as numbers in other parts of the code. It was a total accident, and these additions were unnecessary. Basically, the situation is that there was one part of the code where it determines what's allowed for the flex statement (and possibly other statements) by checking whether it got stored as a "number", and basically only disallows percentages if it attempted to store/serialize them as percentages.
However, it only got to that part of the code because I accidentally allowed VARIANT_OPACITY as a valid way for certain tokens to parse where it wasn't necessary. If it tries to parse it that way under very specific circumstances... percentages will be marked valid and fed through the system as numbers rather than being rejected and not serialized at all, because the check to disallow percentages there relied on them being stored as percentages.
It's a really weird thing to have a problem with in a lot of ways, because if percentages aren't allowed in a field, you would think people wouldn't try to use them there, much less depend on the broken behavior that results from them not parsing as a related value.
|
| |
|
|
| |
Another S&R run with some smarter matching.
|
| |
|
|
| |
Even though percentages are already treated as floats internally by the style system for computation purposes, you have to go out of your way to stop them from being read back out as percentages. What I do here amounts to storing the percentage token in the "wrong" container, the one normally used for floats. This allows a value that was read in as a percentage to be read back out as something else, which is normally prevented by the design of the style system.
|
| |
|
|
|
|
| |
* Remove marquee code
* Regenerate HTML Elements/parser code for Removal of Marquee.
Co-authored-by: Gaming4JC <g4jc@hyperbola.info>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This stub is added because websites insist on considering this
very hardware-dependent and O.S.-variable low-level font-control
as a "critical feature" which it isn't as there is 0 guarantee
that font variation settings are supported or honored by any
operating system used by the client.
On top this is a WD status feature that sites shouldn't be using, and
the feature itself is strongly discouraged for use in favor of standard
CSS font manipulation keywords like `font-weight`.
|
| | |
|
| |
|
|
| |
Follow-up for #891. Tag #457.
|
| |
|
|
| |
This resolves #891
|
| |
|
|
| |
not correctly interpreted
|
| |
|
|
| |
repeat()
|
| |
|
