dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/CSS/Properties.json

3750 lines
79 KiB
JSON
Raw Normal View History

LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
{
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-align-content": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "align-content"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-align-items": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "align-items"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-align-self": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "align-self"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-delay": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-delay"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-direction": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-direction"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-duration": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-duration"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-fill-mode": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-fill-mode"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-iteration-count": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-iteration-count"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-name": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-name"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-play-state": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-play-state"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-animation-timing-function": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "animation-timing-function"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb: Make -webkit-appearance an alias for the appearance css property
2023-12-20 14:16:55 -03:00
"-webkit-appearance": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "appearance"
LibWeb: Make -webkit-appearance an alias for the appearance css property
2023-12-20 14:16:55 -03:00
},
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-background-clip": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "background-clip"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-background-origin": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "background-origin"
},
"-webkit-background-size": {
"legacy-alias-for": "background-size"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-border-bottom-left-radius": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "border-bottom-left-radius"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-border-bottom-right-radius": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "border-bottom-right-radius"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-border-radius": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "border-radius"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-border-top-left-radius": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "border-top-left-radius"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-border-top-right-radius": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "border-top-right-radius"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb: Add -webkit-box-* legacy CSS property aliases
2025-05-05 03:33:23 -03:00
"-webkit-box-align": {
"legacy-alias-for": "align-items"
},
"-webkit-box-flex": {
"legacy-alias-for": "flex-grow"
},
"-webkit-box-ordinal-group": {
"legacy-alias-for": "order"
},
"-webkit-box-orient": {
"legacy-alias-for": "flex-direction"
},
"-webkit-box-pack": {
"legacy-alias-for": "justify-content"
},
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-box-shadow": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "box-shadow"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-box-sizing": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "box-sizing"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb/CSS: Add `-webkit-filter` as a legacy alias
2025-07-23 01:07:36 -03:00
"-webkit-filter": {
"legacy-alias-for": "filter"
},
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-flex": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-basis": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-basis"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-direction": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-direction"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-flow": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-flow"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-grow": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-grow"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-shrink": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-shrink"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-flex-wrap": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "flex-wrap"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-justify-content": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "justify-content"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-mask": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "mask"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb: Implement `mask-image` CSS property support Implemented by reusing AddMask display list item that was initially added for `background-clip` property. Progress on flashlight effect on https://null.com/games/athena-crisis
2024-11-15 21:25:48 -03:00
"-webkit-mask-image": {
"legacy-alias-for": "mask-image"
},
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-order": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "order"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb: Add support for -webkit-text-fill-color
2024-07-07 22:41:18 -03:00
"-webkit-text-fill-color": {
"animation-type": "by-computed-value",
"inherited": true,
"initial": "currentColor",
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"valid-types": [
"color"
]
LibWeb: Add support for -webkit-text-fill-color
2024-07-07 22:41:18 -03:00
},
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
"-webkit-transform": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transform"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transform-origin": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transform-origin"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transition": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transition"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transition-delay": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transition-delay"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transition-duration": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transition-duration"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transition-property": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transition-property"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
"-webkit-transition-timing-function": {
LibWeb/CSS: Implement legacy name aliases for properties When a property is a "legacy name alias", any time it is used in CSS or via the CSSOM its aliased name is used instead. (See https://drafts.csswg.org/css-cascade-5/#legacy-name-alias) This means we only care about the alias when parsing a string as a PropertyID - and we can just return the PropertyID it is an alias for. No need for a distinct PropertyID for it, and no need for LibWeb to care about it at all. Previously, we had a bunch of these properties, which misused our code for "logical aliases", some of which I've discovered were not even fully implemented. But with this change, all that code can go away, and making a legacy alias is just a case of putting it in the JSON. This also shrinks `StyleProperties` as it doesn't need to contain data for these aliases, and removes a whole load of `-webkit-*` spam from the style inspector.
2024-09-27 08:54:08 -03:00
"legacy-alias-for": "transition-timing-function"
LibWeb: Add more legacy -webkit- aliases
2024-07-12 00:22:14 -03:00
},
LibWeb: Improve user-select support
2025-01-04 11:25:17 -03:00
"-webkit-user-select": {
"legacy-alias-for": "user-select"
},
LibWeb: Parse and plumb the `accent-color` CSS property
2023-03-18 16:49:00 -03:00
"accent-color": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse and plumb the `accent-color` CSS property
2023-03-18 16:49:00 -03:00
"inherited": true,
"initial": "auto",
"valid-types": [
"color"
],
"valid-identifiers": [
"auto"
]
},
LibWeb: Parse the CSS align-content property
2022-10-14 08:50:06 -03:00
"align-content": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse the CSS align-content property
2022-10-14 08:50:06 -03:00
"inherited": false,
LibWeb: Add support for "align-content: normal" in CSS parser
2024-01-04 04:13:37 -03:00
"initial": "normal",
LibWeb: Parse the CSS align-content property
2022-10-14 08:50:06 -03:00
"valid-types": [
"align-content"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"align-items": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Make `align-items: normal` behave like `stretch` on flex items CSS-ALIGN-3 tells us that `normal` behavior inside flex containers is simply to behave as `stretch` so this patch makes them behave the same inside FFC. Furthermore, we change the `align-items` initial value to `normal`, matching other engines.
2023-08-20 11:39:49 -03:00
"initial": "normal",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"align-items"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibWeb: Honor `align-self` over `align-items` when non-auto on flex item
2022-07-11 18:52:36 -03:00
"align-self": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Honor `align-self` over `align-items` when non-auto on flex item
2022-07-11 18:52:36 -03:00
"inherited": false,
"initial": "auto",
"valid-types": [
"align-self"
]
},
LibWeb: Add support for the 'all' CSS property The "longhands" array is populated in the code generator to avoid the overhead of manually maintaining the list in Properties.json There is one subtest that still fails in 'cssstyledeclaration-csstext-all-shorthand', this is related to us not maintaining the relative order of CSS declarations for custom vs non-custom properties.
2025-06-09 10:31:14 -03:00
"all": {
"affects-layout": true,
"affects-stacking-context": true,
"inherited": false,
"initial": "initial",
"longhands": [],
"_comment": "The 'longhands' array is populated in the code generator to avoid having to maintain it manually"
},
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"animation": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
"initial": "none 0s ease 1 normal running 0s none",
"longhands": [
"animation-name",
"animation-duration",
"animation-timing-function",
"animation-iteration-count",
"animation-direction",
"animation-play-state",
"animation-delay",
"animation-fill-mode"
]
},
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"animation-delay": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"initial": "0s",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-types": [
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"time [-∞,∞]"
]
},
"animation-direction": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"inherited": false,
"initial": "normal",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-identifiers": [
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"normal",
"reverse",
"alternate",
"alternate-reverse"
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
]
},
"animation-duration": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
LibWeb/CSS: Use "0s" as the initial value for `animation-duration`
2025-03-21 21:50:02 -03:00
"initial": "0s",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-types": [
"time [0,∞]"
LibWeb: Allow `auto` as `animation-duration` and make that the default This is a spec change: https://github.com/w3c/csswg-drafts/commit/2a7cc4b58f903389926cb429af2f42307dced186
2023-06-09 10:25:32 -03:00
],
"valid-identifiers": [
"auto"
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
]
},
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"animation-fill-mode": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"initial": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-identifiers": [
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"none",
"forwards",
"backwards",
"both"
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
]
},
"animation-iteration-count": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
"initial": "1",
"valid-types": [
"number [0,∞]"
],
"valid-identifiers": [
"infinite"
]
},
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"animation-name": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"initial": "none",
"valid-types": [
"string",
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![none]"
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
],
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-identifiers": [
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"none"
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
]
},
"animation-play-state": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
"initial": "running",
"valid-identifiers": [
"running",
"paused"
]
},
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"animation-timing-function": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"inherited": false,
LibWeb: Alphabetize animation properties I didn't notice this when they were added, whoops
2023-06-09 10:07:59 -03:00
"initial": "ease",
LibWeb: Fully implement CSS animation-timing-function This implements all the timing functions, and hopefully all their quirks. Also changes the animation demo to use some funny cubic timing functions.
2023-07-06 10:26:25 -03:00
"valid-types": [
"easing-function"
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
]
},
LibWeb: Implement `appearance` CSS property This includes the "compat" values even though they are not strictly necessary.
2022-07-22 12:05:11 -03:00
"appearance": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Implement `appearance` CSS property This includes the "compat" values even though they are not strictly necessary.
2022-07-22 12:05:11 -03:00
"inherited": false,
LibWeb/CSS: Set the initial value of the `appearance` property to "none"
2025-03-21 22:32:36 -03:00
"initial": "none",
LibWeb: Implement `appearance` CSS property This includes the "compat" values even though they are not strictly necessary.
2022-07-22 12:05:11 -03:00
"valid-types": [
"appearance"
]
},
LibWeb: Parse `aspect-ratio` property Parse it, store the result in the ComputedValues, and also expose it to ResolvedCSSStyleDeclaration.
2023-06-08 11:25:16 -03:00
"aspect-ratio": {
"affects-layout": true,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse `aspect-ratio` property Parse it, store the result in the ComputedValues, and also expose it to ResolvedCSSStyleDeclaration.
2023-06-08 11:25:16 -03:00
"inherited": false,
"initial": "auto",
"valid-types": [
"ratio"
],
LibWeb: Make the linter happy in Properties.json There was a space missing and the linter complained.
2023-08-01 15:11:03 -03:00
"valid-identifiers": [
LibWeb: Parse `aspect-ratio` property Parse it, store the result in the ComputedValues, and also expose it to ResolvedCSSStyleDeclaration.
2023-06-08 11:25:16 -03:00
"auto"
]
},
LibWeb+Meta: Parse the `backdrop-filter` CSS property Note: The parsing and style value completely ignores the SVG filters part of the spec for now... That's a yak for another day :^)
2022-09-15 04:31:17 -03:00
"backdrop-filter": {
"affects-layout": false,
LibWeb: Establish stacking context when backdrop-filter is not 'none'
2022-10-24 12:05:10 -03:00
"affects-stacking-context": true,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibWeb+Meta: Parse the `backdrop-filter` CSS property Note: The parsing and style value completely ignores the SVG filters part of the spec for now... That's a yak for another day :^)
2022-09-15 04:31:17 -03:00
"inherited": false,
"initial": "none",
LibWeb: Fill in some missing property data and bodge extra types We don't yet have generic parsing support for `<filter-value-list>` or `<paint>`, so listing them here confuses the new StyleValue parsing code I'm working on. For now, let's skip `<filter-value-list>` since it's only used in one pkace which manually parses it, and list the parts of `<paint>` instead which are taken from here: https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint
2023-05-10 13:19:08 -03:00
"__comment": "FIXME: List `filter-value-list` as a valid-type once it's generically supported.",
LibWeb+Meta: Parse the `backdrop-filter` CSS property Note: The parsing and style value completely ignores the SVG filters part of the spec for now... That's a yak for another day :^)
2022-09-15 04:31:17 -03:00
"valid-identifiers": [
"none"
]
},
LibWeb: Add initial values and longhands to `background` definition There is no specified initial value, but `transparent` is equivalent to setting all the background properties to their defaults.
2021-11-10 10:29:41 -03:00
"background": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add initial values and longhands to `background` definition There is no specified initial value, but `transparent` is equivalent to setting all the background properties to their defaults.
2021-11-10 10:29:41 -03:00
"inherited": false,
"initial": "transparent",
"longhands": [
"background-attachment",
"background-clip",
"background-color",
"background-image",
"background-origin",
"background-position",
"background-repeat",
"background-size"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"background-attachment": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "scroll",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"background-attachment"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Improved implementation of `background-blend-mode` This is a improved version of a73cd88f0c8b76e8413c1b35e6bc667e03eba5b4 The old commit was reverted in 552dd18696b1009d84d2a605491d9339c3e1da12 The new version only paints an element into a new layer if background blend modes other than normal are used. The rasterization performance of most websites should therefore not suffer. Co-Authored-By: Alexander Kalenik <kalenik.aliaksandr@gmail.com>
2025-03-29 19:44:25 -03:00
"background-blend-mode": {
LibWeb: Update animation type of compositing properties This updates `background-blend-mode`, `mix-blend-mode`, and `isolation` to be animation type `discrete` rather than `none`. This reflects https://github.com/w3c/fxtf-drafts/commit/169b0e1 but isn't reflected on the published spec as the published spec is out of date - see https://github.com/w3c/fxtf-drafts/issues/547 Gains us 26 WPT tests.
2025-09-10 10:30:47 -03:00
"animation-type": "discrete",
LibWeb/CSS: Improved implementation of `background-blend-mode` This is a improved version of a73cd88f0c8b76e8413c1b35e6bc667e03eba5b4 The old commit was reverted in 552dd18696b1009d84d2a605491d9339c3e1da12 The new version only paints an element into a new layer if background blend modes other than normal are used. The rasterization performance of most websites should therefore not suffer. Co-Authored-By: Alexander Kalenik <kalenik.aliaksandr@gmail.com>
2025-03-29 19:44:25 -03:00
"inherited": false,
"initial": "normal",
"valid-types": [
"mix-blend-mode"
]
},
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
"background-clip": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
"inherited": false,
"initial": "border-box",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"background-box"
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"background-color": {
LibWeb: Annotate which CSS properties may affect layout This patch adds CSS::property_affects_layout(PropertyID) which tells us whether a CSS property would affect layout if it were changed. This will be used to avoid unnecessary relayout work when something changes that really only requires us to repaint the page. To mark a property as not affecting layout, set "affects-layout" to false in the corresponding Properties.json entry. Note that all properties affect layout by default.
2022-03-16 13:46:24 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "transparent",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"background-image": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
"valid-types": [
"image"
],
"valid-identifiers": [
"none"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
"background-origin": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
"inherited": false,
"initial": "padding-box",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"background-box"
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 17:28:34 -03:00
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"background-position": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0% 0%",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"max-values": 4,
"valid-types": [
LibWeb: Merge background-position parsing into position code Implemented by adding the extra 3-value syntax as its own case and only running it when parsing background-position. I'm sure it could be implemented in a smarter way but this is still a bunch less code than before. :^)
2023-11-20 12:33:21 -03:00
"background-position"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
"quirks": [
"unitless-length"
],
"longhands": [
"background-position-x",
"background-position-y"
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
},
"background-position-x": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
"inherited": false,
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
"initial": "0%",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
],
"valid-identifiers": [
"center",
"left",
"right"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
},
"background-position-y": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
"inherited": false,
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
"initial": "0%",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add longhand properties for background-position If background-position was not longhand enough for you, we've now got background-position-x and background-position-y :^)
2023-04-02 18:52:54 -03:00
],
"valid-identifiers": [
"center",
"bottom",
"top"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"background-repeat": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Combine background-repeat-x/y pseudo-properties While right now this doesn't save much complexity, it will do once we care about multiple background layers per node. Then, having a single repeat value per layer will simplify things. It also means we can remove the pseudo-property concept entirely! :^)
2021-11-04 13:51:34 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "repeat",
"max-values": 2,
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
LibWeb/CSS: Rename background-repeat related symbols to align with spec These will be used for the mask-repeat property as well in an upcoming commit, hence the more generic names. Also, this more closely matches the names used in the spec.
2025-07-18 15:36:09 -03:00
"repetition"
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
],
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-identifiers": [
"repeat-x",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"repeat-y"
LibWeb: Support two-value background-repeat The background-repeat value may be specified as either one- or two-value identifiers (to be interpreted as horizontal and vertical repeat). This adds two pseudo-properties, background-repeat-x and background-repeat-y, to handle this. One-value identifiers are mapped to two-value in accordance with the spec.
2021-04-05 13:05:35 -03:00
]
},
LibWeb: Parse `background-size` property
2021-11-05 10:44:37 -03:00
"background-size": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
LibWeb: Parse `background-size` property
2021-11-05 10:44:37 -03:00
"inherited": false,
"initial": "auto",
"max-values": 2,
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Parse `background-size` property
2021-11-05 10:44:37 -03:00
],
"valid-identifiers": [
"auto",
"cover",
"contain"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Parse `background-size` property
2021-11-05 10:44:37 -03:00
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"block-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "size",
"mapping": "block-size"
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"initial": "auto",
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "medium currentcolor none",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"border-width",
"border-style",
"border-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Support border-{block,inline} shorthands Gains us 4 WPT tests
2025-07-09 05:47:34 -03:00
"border-block": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-block-width",
"border-block-style",
"border-block-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Support border-{block,inline} shorthands Gains us 4 WPT tests
2025-07-09 05:47:34 -03:00
},
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
"border-block-color": {
"inherited": false,
"initial": "currentcolor",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
"longhands": [
"border-block-start-color",
"border-block-end-color"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
"color"
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
]
},
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
"border-block-end": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-block-end-width",
"border-block-end-style",
"border-block-end-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
},
"border-block-end-color": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-color",
"mapping": "block-end"
},
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
"max-values": 1
},
"border-block-end-style": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-style",
"mapping": "block-end"
},
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
"max-values": 1
},
"border-block-end-width": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-width",
"mapping": "block-end"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
},
"border-block-start": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-block-start-width",
"border-block-start-style",
"border-block-start-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
},
"border-block-start-color": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-color",
"mapping": "block-start"
},
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
"max-values": 1
},
"border-block-start-style": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-style",
"mapping": "block-start"
},
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
"max-values": 1
},
"border-block-start-width": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-width",
"mapping": "block-start"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Parse `border-block-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 20:16:50 -03:00
},
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
"border-block-style": {
"inherited": false,
"initial": "none",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
"longhands": [
"border-block-start-style",
"border-block-end-style"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
"line-style"
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
]
},
"border-block-width": {
"inherited": false,
"initial": "medium",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
"longhands": [
"border-block-start-width",
"border-block-end-width"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Add the `border-block-*` shorthand properties
2025-06-30 07:59:02 -03:00
},
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 11:14:31 -03:00
"border-bottom": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "medium currentcolor none",
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 11:14:31 -03:00
"longhands": [
"border-bottom-width",
"border-bottom-style",
"border-bottom-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 11:14:31 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-bottom-color": {
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"affects-layout": false,
"animation-type": "by-computed-value",
LibWeb: Make "currentcolor" lowercase in Properties.json It's technically case-insensitive, but the spec always defines it as "currentcolor" so it feels wrong to capitalise it differently there.
2021-09-16 16:59:45 -03:00
"initial": "currentcolor",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 17:00:54 -03:00
"valid-types": [
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
"border-bottom-left-radius": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Quote all initial values in Properties.json This is in preparation for parsing these into StyleValues automatically. Having them all be Strings makes the generation code simpler.
2021-08-16 13:09:34 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
"max-values": 2,
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
},
"border-bottom-right-radius": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Quote all initial values in Properties.json This is in preparation for parsing these into StyleValues automatically. Having them all be Strings makes the generation code simpler.
2021-08-16 13:09:34 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
"max-values": 2,
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-bottom-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"line-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-bottom-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "medium",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"border-collapse": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": true,
"initial": "separate",
"valid-types": [
"border-collapse"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-color": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Correct some initial values and add missing ones - The `text-decoration-foo` values now match the spec. - Added values for `border-foo` since those are needed soon. - Make `color`'s initial value be `-libweb-palette-base-text`.
2021-09-17 13:18:06 -03:00
"initial": "currentcolor",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"border-top-color",
"border-right-color",
"border-bottom-color",
"border-left-color"
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
],
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
]
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"border-end-end-radius": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-radius",
"mapping": "end-end"
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"max-values": 1
},
"border-end-start-radius": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-radius",
"mapping": "end-start"
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"max-values": 1
},
LibWeb: Parse `border-image` shorthand property
2025-06-11 08:35:32 -03:00
"border-image": {
"inherited": false,
"initial": "none 100% 1 0 stretch",
"longhands": [
"border-image-source",
"border-image-slice",
"border-image-width",
"border-image-outset",
"border-image-repeat"
]
},
LibWeb: Parse the `border-image-outset` property
2025-06-10 19:54:48 -03:00
"border-image-outset": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "0",
"max-values": 4,
"valid-types": [
"length [0,∞]",
"number [0,∞]"
]
},
LibWeb: Parse the `border-image-repeat` property
2025-06-10 20:08:37 -03:00
"border-image-repeat": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": false,
"initial": "stretch",
"max-values": 2,
"valid-types": [
"border-image-repeat"
]
},
LibWeb: Parse the `border-image-slice` property
2025-06-10 12:58:54 -03:00
"border-image-slice": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "100%",
"valid-identifiers": [
"fill"
],
"valid-types": [
"number [0,∞]",
"percentage [0,∞]"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Parse the `border-image-slice` property
2025-06-10 12:58:54 -03:00
},
LibWeb: Parse the `border-image-source` property
2025-06-10 01:29:50 -03:00
"border-image-source": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": false,
"initial": "none",
"valid-types": [
"image"
],
"valid-identifiers": [
"none"
]
},
LibWeb: Parse the `border-image-slice` property
2025-06-10 12:58:54 -03:00
"border-image-width": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "1",
"max-values": 4,
"valid-types": [
"length [0,∞]",
"percentage [0,∞]",
"number [0,∞]"
],
"valid-identifiers": [
"auto"
LibWeb: Resolve border-image-width percentages as lengths All remaining failing subtests in border-image-width-interpolation.html are related to incorrect handling of mixed dimension and percentage interpolation and are fixed by #6142.
2025-09-10 09:35:56 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Parse the `border-image-slice` property
2025-06-10 12:58:54 -03:00
},
LibWeb: Support border-{block,inline} shorthands Gains us 4 WPT tests
2025-07-09 05:47:34 -03:00
"border-inline": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-inline-width",
"border-inline-style",
"border-inline-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Support border-{block,inline} shorthands Gains us 4 WPT tests
2025-07-09 05:47:34 -03:00
},
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
"border-inline-color": {
"inherited": false,
"initial": "currentcolor",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
"longhands": [
"border-inline-start-color",
"border-inline-end-color"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
"color"
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
]
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"border-inline-end": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-inline-end-width",
"border-inline-end-style",
"border-inline-end-color"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
},
"border-inline-end-color": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-color",
"mapping": "inline-end"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
"border-inline-end-style": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-style",
"mapping": "inline-end"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
"border-inline-end-width": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-width",
"mapping": "inline-end"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
"border-inline-start": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-inline-start-width",
"border-inline-start-style",
"border-inline-start-color"
]
},
"border-inline-start-color": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-color",
"mapping": "inline-start"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
"border-inline-start-style": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-style",
"mapping": "inline-start"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
"border-inline-start-width": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-width",
"mapping": "inline-start"
},
LibWeb/CSS: Parse `border-inline-*` properties This doesn't currently honor `writing-mode`, `direction` and `text-orientation`.
2025-03-10 19:39:22 -03:00
"max-values": 1
},
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
"border-inline-style": {
"inherited": false,
"initial": "none",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
"longhands": [
"border-inline-start-style",
"border-inline-end-style"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
"line-style"
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
]
},
"border-inline-width": {
"inherited": false,
"initial": "medium",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
"longhands": [
"border-inline-start-width",
"border-inline-end-width"
LibWeb: Handle border-{inline,block}-* properties with a single value Gains us 14 WPT tests
2025-07-09 04:42:07 -03:00
],
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add the `border-inline-*` shorthand properties
2025-06-30 08:07:39 -03:00
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"border-left": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-left-width",
"border-left-style",
"border-left-color"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-left-color": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Make "currentcolor" lowercase in Properties.json It's technically case-insensitive, but the spec always defines it as "currentcolor" so it feels wrong to capitalise it differently there.
2021-09-16 16:59:45 -03:00
"initial": "currentcolor",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-left-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"line-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-left-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "medium",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
"border-radius": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "0",
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
"longhands": [
"border-top-left-radius",
"border-top-right-radius",
"border-bottom-left-radius",
"border-bottom-right-radius"
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
],
LibWeb/CSS: Don't allow negative values in `border-radius` property
2025-03-12 10:57:10 -03:00
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
],
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
"percentages-resolve-to": "length"
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"border-right": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-right-width",
"border-right-style",
"border-right-color"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-right-color": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Make "currentcolor" lowercase in Properties.json It's technically case-insensitive, but the spec always defines it as "currentcolor" so it feels wrong to capitalise it differently there.
2021-09-16 16:59:45 -03:00
"initial": "currentcolor",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-right-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"line-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-right-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "medium",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-spacing": {
LibWeb: Use correct animation type for `border-spacing` This follows the `css-tables` specification rather than the older CSS2 specification.
2025-07-31 11:11:20 -03:00
"_comment": "Follows the newer definition from: https://drafts.csswg.org/css-tables-3/#border-spacing-property",
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Correct initial values in Properties.json - `align-items`: `normal` is the initial value in the CSS-ALIGN spec, but `stretch` is in CSS-FLEXBOX. The FLEXBOX spec is the one we've actually implemented elsewhere, and ALIGN adds new values with special syntax, so it's not trivial to add it here. - `border-spacing`: `0` is equivalent to `0px 0px` and we don't yet parse the double-value syntax. - `text-decoration-thickness`: Had the wrong value.
2021-11-10 10:27:16 -03:00
"initial": "0",
LibWeb: Add CSS support for border-spacing property
2023-06-15 23:35:03 -03:00
"max-values": 2,
LibWeb: Fill in some missing property data and bodge extra types We don't yet have generic parsing support for `<filter-value-list>` or `<paint>`, so listing them here confuses the new StyleValue parsing code I'm working on. For now, let's skip `<filter-value-list>` since it's only used in one pkace which manually parses it, and list the parts of `<paint>` instead which are taken from here: https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint
2023-05-10 13:19:08 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [0,∞]"
LibWeb: Fill in some missing property data and bodge extra types We don't yet have generic parsing support for `<filter-value-list>` or `<paint>`, so listing them here confuses the new StyleValue parsing code I'm working on. For now, let's skip `<filter-value-list>` since it's only used in one pkace which manually parses it, and list the parts of `<paint>` instead which are taken from here: https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint
2023-05-10 13:19:08 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"border-start-end-radius": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-radius",
"mapping": "start-end"
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"max-values": 1
},
"border-start-start-radius": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "border-radius",
"mapping": "start-start"
},
LibWeb: Add `border-*-radius` logical properties
2025-06-30 16:33:17 -03:00
"max-values": 1
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-style": {
LibWeb: Correct some initial values and add missing ones - The `text-decoration-foo` values now match the spec. - Added values for `border-foo` since those are needed soon. - Make `color`'s initial value be `-libweb-palette-base-text`.
2021-09-17 13:18:06 -03:00
"initial": "none",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"border-top-style",
"border-right-style",
"border-bottom-style",
"border-left-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"line-style"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"border-top": {
"inherited": false,
"initial": "medium currentcolor none",
"longhands": [
"border-top-width",
"border-top-style",
"border-top-color"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-top-color": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Make "currentcolor" lowercase in Properties.json It's technically case-insensitive, but the spec always defines it as "currentcolor" so it feels wrong to capitalise it differently there.
2021-09-16 16:59:45 -03:00
"initial": "currentcolor",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Fill in some missing property data and bodge extra types We don't yet have generic parsing support for `<filter-value-list>` or `<paint>`, so listing them here confuses the new StyleValue parsing code I'm working on. For now, let's skip `<filter-value-list>` since it's only used in one pkace which manually parses it, and list the parts of `<paint>` instead which are taken from here: https://www.w3.org/TR/SVG2/painting.html#SpecifyingPaint
2023-05-10 13:19:08 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
"border-top-left-radius": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Quote all initial values in Properties.json This is in preparation for parsing these into StyleValues automatically. Having them all be Strings makes the generation code simpler.
2021-08-16 13:09:34 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
"max-values": 2,
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
},
"border-top-right-radius": {
LibWeb: Mark a bunch of CSS border-* properties as not affecting layout border*-width and border-collapse affect layout, but all the color, style and radius ones will only need a repaint if changed. :^)
2022-03-16 16:34:48 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Quote all initial values in Properties.json This is in preparation for parsing these into StyleValues automatically. Having them all be Strings makes the generation code simpler.
2021-08-16 13:09:34 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
"max-values": 2,
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add border-radius to the CSS-parser And resolve the shorthands.
2021-05-14 16:36:26 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"border-top-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"inherited": false,
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"line-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-top-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"initial": "medium",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"border-width": {
LibWeb: Correct some initial values and add missing ones - The `text-decoration-foo` values now match the spec. - Added values for `border-foo` since those are needed soon. - Make `color`'s initial value be `-libweb-palette-base-text`.
2021-09-17 13:18:06 -03:00
"initial": "medium",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"border-top-width",
"border-right-width",
"border-bottom-width",
"border-left-width"
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
],
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
]
},
"bottom": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
LibWeb: Parse `anchor()` function for inset properties
2025-08-03 09:58:13 -03:00
"percentage [-∞,∞]",
"anchor"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"box-shadow": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibWeb: Add box-shadow as a known ValueID
2021-07-23 16:21:39 -03:00
"inherited": false,
LibWeb: Parse "none" value for box-shadow property Previously, `box-shadow: none` would fail to parse, meaning that in this example: ```css p { box-shadow: 20px 10px 5px magenta; } p.foo { box-shadow: none; } ``` ... a `<p class="foo">` would still have a box-shadow, when it should not have one. Now, we handle the `none` value. :^)
2021-10-15 15:25:27 -03:00
"initial": "none",
"valid-identifiers": [
"none"
]
LibWeb: Add box-shadow as a known ValueID
2021-07-23 16:21:39 -03:00
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"box-sizing": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "content-box",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"box-sizing"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"caption-side": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "top",
LibWeb: Add support for table caption Adds layout support and the CSS caption-side property.
2023-06-06 23:10:55 -03:00
"valid-types": [
"caption-side"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Implement the `caret-color` property
2025-03-09 10:59:33 -03:00
"caret-color": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": true,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"color"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"clear": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"clear"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"clip": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb/CSS: Set "inherited" to false for "clip" property "clip" should not be inherited.
2023-08-23 08:48:57 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-identifiers": [
"auto"
],
LibWeb: Parse rect style value Add ability to parse a rect when it is used as the value of a style property.
2022-07-31 13:46:35 -03:00
"valid-types": [
"rect"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add the `clip-path` property and resolve it for SVG elements
2024-03-26 21:06:35 -03:00
"clip-path": {
LibWeb: Set `clip-path` animation type to `by-computed-value`
2025-04-09 02:09:19 -03:00
"animation-type": "by-computed-value",
LibWeb: Add the `clip-path` property and resolve it for SVG elements
2024-03-26 21:06:35 -03:00
"affects-layout": false,
"affects-stacking-context": true,
"inherited": false,
"valid-identifiers": [
"none"
],
"__comment": "FIXME: This should be a <clip-source> | [ <basic-shape> || <geometry-box> ]",
"valid-types": [
LibWeb: Resolve `basic-shape` clip-paths These will be ignored within SVGs (for now SVGs only support <clipPath> elements), but will allow clipping standard HTML elements.
2024-05-25 20:25:05 -03:00
"basic-shape",
LibWeb: Add the `clip-path` property and resolve it for SVG elements
2024-03-26 21:06:35 -03:00
"url"
],
"initial": "none"
},
LibWeb: Implement the SVG `clip-rule` attribute This controls the fill rule used when rasterizing `<clipPath>` elements.
2024-05-12 16:19:43 -03:00
"clip-rule": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
"initial": "nonzero",
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"valid-types": [
"fill-rule"
]
LibWeb: Implement the SVG `clip-rule` attribute This controls the fill rule used when rasterizing `<clipPath>` elements.
2024-05-12 16:19:43 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"color": {
LibWeb: Annotate which CSS properties may affect layout This patch adds CSS::property_affects_layout(PropertyID) which tells us whether a CSS property would affect layout if it were changed. This will be used to avoid unnecessary relayout work when something changes that really only requires us to repaint the page. To mark a property as not affecting layout, set "affects-layout" to false in the corresponding Properties.json entry. Note that all properties affect layout by default.
2022-03-16 13:46:24 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb/CSS: Set initial value of color property to `canvastext` Previously the non-standard value `-libweb-palette-base-text` was used.
2024-07-05 15:55:07 -03:00
"initial": "canvastext",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"hashless-hex-color"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Implement the `color-interpolation` property for SVG gradients This changes the operating color space for gradient `<linearGradient>` and `<radialGradient>` elements.
2025-08-15 19:53:15 -03:00
"color-interpolation": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
"initial": "srgb",
"valid-types": [
"color-interpolation"
]
},
LibWeb/CSS: Implement the color-scheme CSS property
2025-01-01 22:59:09 -03:00
"color-scheme": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"initial": "normal",
"valid-types": [
"custom-ident ![normal,light,dark,only]"
],
"valid-identifiers": [
"normal",
"light",
"dark"
]
LibWeb/CSS: Implement the color-scheme CSS property
2025-01-01 22:59:09 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"column-count": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"inherited": false,
"initial": "auto",
"valid-types": [
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"integer [1,∞]"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
],
"valid-identifiers": [
"auto"
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
]
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"column-gap": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Implement support for parsing CSS column-count property
2023-09-06 13:30:57 -03:00
"inherited": false,
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"initial": "normal",
LibWeb: Implement support for parsing CSS column-count property
2023-09-06 13:30:57 -03:00
"valid-types": [
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Implement support for parsing CSS column-count property
2023-09-06 13:30:57 -03:00
],
"valid-identifiers": [
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"normal"
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Implement support for parsing CSS column-count property
2023-09-06 13:30:57 -03:00
},
LibWeb: Add CSS column-height property
2025-09-04 16:50:06 -03:00
"column-height": {
"animation-type": "by-computed-value",
"inherited": false,
"initial": "auto",
"valid-types": [
"length [0,∞]"
],
"valid-identifiers": [
"auto"
]
},
LibWeb: Support parsing column-span
2024-08-20 21:23:55 -03:00
"column-span": {
"animation-type": "discrete",
"inherited": false,
"initial": "none",
"valid-types": [
"column-span"
]
},
LibWeb: Support parsing column-width
2024-08-20 20:58:14 -03:00
"column-width": {
"animation-type": "by-computed-value",
"inherited": false,
"initial": "auto",
"valid-types": [
"length [0,∞]"
],
"valid-identifiers": [
"auto"
]
},
LibWeb: Support parsing columns
2024-08-21 12:09:08 -03:00
"columns": {
"inherited": false,
LibWeb: Add CSS column-height property
2025-09-04 16:50:06 -03:00
"initial": "auto auto / auto",
LibWeb: Support parsing columns
2024-08-21 12:09:08 -03:00
"longhands": [
"column-width",
LibWeb: Add CSS column-height property
2025-09-04 16:50:06 -03:00
"column-count",
"column-height"
LibWeb: Support parsing columns
2024-08-21 12:09:08 -03:00
]
},
LibWeb: Implement CSS 'contain' property
2025-01-18 16:39:26 -03:00
"contain": {
"affects-stacking-context": true,
"animation-type": "none",
"inherited": false,
"initial": "none",
"valid-types": [
"contain"
]
},
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 16:56:25 -03:00
"content": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 16:56:25 -03:00
"inherited": false,
"initial": "normal",
"__comment": "FIXME: This accepts a whole lot of other types and identifiers!",
"valid-types": [
LibWeb: Implement CounterStyleValue This is `counter(name, style?)` or `counters(name, link, style?)`. The difference being, `counter()` matches only the nearest level (eg, "1"), and `counters()` combines all the levels in the tree (eg, "3.4.1").
2024-07-24 10:56:16 -03:00
"counter",
LibWeb: Support CSS content property images (and lists, too!) This patch expands our generated content support beyond single strings to lists of strings and/or images. Pseudo-elements like ::before and ::after can now use content:url(...) to insert anonymous image boxes into the layout tree. This is heavily used in Google Docs for UI elements.
2025-07-27 10:55:16 -03:00
"image",
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 16:56:25 -03:00
"string"
],
"valid-identifiers": [
"normal",
LibWeb: Support quotes in `content` values This adds initial support for `open-quote`, `close-quote`, `no-open-quote` and `no-close-quote`. We don't yet track the "nesting level" so we always use the first pair of quotes from the `quotes` property.
2023-09-12 10:22:46 -03:00
"none",
"open-quote",
"close-quote",
"no-open-quote",
"no-close-quote"
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 16:56:25 -03:00
]
},
LibWeb: Support content-visibility css
2024-06-23 09:52:56 -03:00
"content-visibility": {
LibWeb: Interpolate the `content-visibility` property correctly
2025-05-12 12:18:55 -03:00
"animation-type": "custom",
LibWeb: Support content-visibility css
2024-06-23 09:52:56 -03:00
"inherited": false,
"initial": "visible",
"valid-types": [
"content-visibility"
]
},
LibWeb: Implement counter-[increment,reset,set] properties These control the state of CSS counters. Parsing code for `reversed(counter-name)` is implemented, but disabled for now until we are able to resolve values for those.
2024-07-24 11:47:11 -03:00
"counter-increment": {
"animation-type": "by-computed-value",
"inherited": false,
"initial": "none",
"valid-types": [
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![none]",
LibWeb: Implement counter-[increment,reset,set] properties These control the state of CSS counters. Parsing code for `reversed(counter-name)` is implemented, but disabled for now until we are able to resolve values for those.
2024-07-24 11:47:11 -03:00
"integer [-∞,∞]"
],
"valid-identifiers": [
"none"
]
},
"counter-reset": {
"animation-type": "by-computed-value",
"inherited": false,
"initial": "none",
"valid-types": [
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![none]",
LibWeb: Implement counter-[increment,reset,set] properties These control the state of CSS counters. Parsing code for `reversed(counter-name)` is implemented, but disabled for now until we are able to resolve values for those.
2024-07-24 11:47:11 -03:00
"integer [-∞,∞]"
],
"valid-identifiers": [
"none"
]
},
"counter-set": {
"animation-type": "by-computed-value",
"inherited": false,
"initial": "none",
"valid-types": [
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![none]",
LibWeb: Implement counter-[increment,reset,set] properties These control the state of CSS counters. Parsing code for `reversed(counter-name)` is implemented, but disabled for now until we are able to resolve values for those.
2024-07-24 11:47:11 -03:00
"integer [-∞,∞]"
],
"valid-identifiers": [
"none"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"cursor": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "auto",
"valid-types": [
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"url",
LibWeb/CSS: Update definition for `cursor` property No functional changes. The main difference is renaming the cursor enum to match the spec term `<cursor-predefined>`, which is a bit more verbose but clearer in meaning. Corresponds to https://github.com/w3c/csswg-drafts/commit/1a57a4025c8778dab45ef8d5fbd482e4d6c4ebce
2025-07-09 06:39:22 -03:00
"cursor-predefined",
"number [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
"cx": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#CX.",
"animation-type": "by-computed-value",
"inherited": false,
"initial": "0",
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
"cy": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#CY.",
"animation-type": "by-computed-value",
"inherited": false,
"initial": "0",
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"direction": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "ltr",
LibWeb: Use reverse direction on flex containers with `rtl` direction If a flex container has `direction: rtl` set, reverse the row direction.
2024-08-10 19:13:26 -03:00
"valid-types": [
"direction"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"display": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "inline",
LibWeb: Set max-values for display CSS property
2023-04-26 14:49:02 -03:00
"max-values": 3,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-identifiers": [
LibWeb: Move `<display-foo>` definitions into Enums.json This eliminates a fair bit of boilerplate.
2023-09-04 13:39:15 -03:00
"list-item"
],
"valid-types": [
"display-outside",
"display-inside",
"display-internal",
"display-box",
"display-legacy"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Implement the `empty-cells` property This property sets whether table borders and backgrounds are painted if a given table cell has no visible content.
2025-06-18 08:28:18 -03:00
"empty-cells": {
"animation-type": "discrete",
"inherited": true,
"initial": "show",
"valid-types": [
"empty-cells"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"fill": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Use correct animation type for `fill` property This was incorrectly marked as `none` when it should be `by-computed-value`. Gains us 103 WPT tests.
2025-09-10 22:30:43 -03:00
"animation-type": "by-computed-value",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "black",
"valid-types": [
LibWeb: Add parsing for CSS `<paint>` values This gets rid of a couple of FIXMEs in Properties.json :^)
2023-06-15 12:37:36 -03:00
"paint"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"fill-opacity": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"inherited": true,
"initial": "1",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"number [-∞,∞]",
"percentage [-∞,∞]"
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
]
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
},
LibWeb: Implement SVG `fill-rule` attribute Previously, we did an evenodd fill for everything which while for most SVGs works, it is not correct default (it should be nonzero), and broke some SVGs. This fixes a few of the icons on https://shopify.com/.
2023-06-11 12:43:46 -03:00
"fill-rule": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Implement SVG `fill-rule` attribute Previously, we did an evenodd fill for everything which while for most SVGs works, it is not correct default (it should be nonzero), and broke some SVGs. This fixes a few of the icons on https://shopify.com/.
2023-06-11 12:43:46 -03:00
"inherited": true,
"initial": "nonzero",
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"valid-types": [
"fill-rule"
]
LibWeb: Implement SVG `fill-rule` attribute Previously, we did an evenodd fill for everything which while for most SVGs works, it is not correct default (it should be nonzero), and broke some SVGs. This fixes a few of the icons on https://shopify.com/.
2023-06-11 12:43:46 -03:00
},
LibWeb: Parse and store `filter` property This shares its implementation with `backdrop-filter`.
2024-10-25 06:00:22 -03:00
"filter": {
"affects-layout": false,
LibWeb: Mark CSS `filter` property as affecting stacking context tree
2025-08-19 06:29:09 -03:00
"affects-stacking-context": true,
LibWeb: Parse and store `filter` property This shares its implementation with `backdrop-filter`.
2024-10-25 06:00:22 -03:00
"animation-type": "custom",
"inherited": false,
"initial": "none",
"__comment": "FIXME: List `filter-value-list` as a valid-type once it's generically supported.",
"valid-identifiers": [
"none"
]
},
LibWeb: Parse and resolve flex: shorthand
2021-06-01 10:50:17 -03:00
"flex": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "0 1 auto",
LibWeb: Use new StyleValue parsing for flex To make this work, we also add `none` as a valid identifier for `flex`. (This is correct, we just didn't need it before.)
2023-05-18 12:21:10 -03:00
"valid-identifiers": [
"none"
],
LibWeb: Parse and resolve flex: shorthand
2021-06-01 10:50:17 -03:00
"longhands": [
"flex-grow",
"flex-shrink",
"flex-basis"
]
},
LibWeb: Parse flex-basis Flex-basis accepts either 'content' or a Length.
2021-05-30 09:23:43 -03:00
"flex-basis": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse flex-basis Flex-basis accepts either 'content' or a Length.
2021-05-30 09:23:43 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "auto",
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto",
LibWeb: Allow flex-basis: {min,max,fit}-content
2024-06-23 10:36:51 -03:00
"content",
"max-content",
"min-content"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Parse flex-basis Flex-basis accepts either 'content' or a Length.
2021-05-30 09:23:43 -03:00
},
LibWeb: Parse the CSS "flex-direction" property
2021-01-18 13:41:57 -03:00
"flex-direction": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse the CSS "flex-direction" property
2021-01-18 13:41:57 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "row",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"flex-direction"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Parse the CSS "flex-direction" property
2021-01-18 13:41:57 -03:00
},
LibWeb: Parse and resolve flex-flow property
2021-05-30 07:25:10 -03:00
"flex-flow": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "row nowrap",
LibWeb: Parse and resolve flex-flow property
2021-05-30 07:25:10 -03:00
"longhands": [
"flex-direction",
"flex-wrap"
]
},
LibWeb: Add flex-grow and flex-shrink They get parsed and are available to the programmer of Layouts :^)
2021-05-30 15:22:25 -03:00
"flex-grow": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add flex-grow and flex-shrink They get parsed and are available to the programmer of Layouts :^)
2021-05-30 15:22:25 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "0",
"valid-types": [
LibWeb: Reject negative values for `flex-grow` and `flex-shrink`
2022-07-18 16:52:30 -03:00
"number [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add flex-grow and flex-shrink They get parsed and are available to the programmer of Layouts :^)
2021-05-30 15:22:25 -03:00
},
"flex-shrink": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add flex-grow and flex-shrink They get parsed and are available to the programmer of Layouts :^)
2021-05-30 15:22:25 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "1",
"valid-types": [
LibWeb: Reject negative values for `flex-grow` and `flex-shrink`
2022-07-18 16:52:30 -03:00
"number [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add flex-grow and flex-shrink They get parsed and are available to the programmer of Layouts :^)
2021-05-30 15:22:25 -03:00
},
LibWeb: Add parsing for flex-wrap property
2021-05-30 07:11:32 -03:00
"flex-wrap": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add parsing for flex-wrap property
2021-05-30 07:11:32 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "nowrap",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"flex-wrap"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add parsing for flex-wrap property
2021-05-30 07:11:32 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"float": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"float"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/SVG: Add FEFloodElement
2025-07-06 16:48:55 -03:00
"flood-color": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "black",
"valid-types": [
"color"
]
},
"flood-opacity": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "1",
"valid-types": [
LibWeb: Handle `flood-opacity` in line with other opacity properties We now do the proper thing in terms of: - Allowing percentages - Returning the computed value in getComputedStyle - Handling values out of the [0,1] range Gains us 13 WPT passes in the imported tests.
2025-07-18 07:37:12 -03:00
"number [-∞,∞]",
"percentage [-∞,∞]"
LibWeb/SVG: Add FEFloodElement
2025-07-06 16:48:55 -03:00
]
},
LibWeb: Start parsing font property
2021-04-13 14:41:57 -03:00
"font": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": true,
LibWeb/CSS: Use `serif` for font and font-family initial property values These properties previously used sans-serif for their initial values.
2024-07-05 15:59:18 -03:00
"initial": "normal medium serif",
LibWeb/CSS: Parse and propagate the font-language-override property
2024-09-27 13:11:05 -03:00
"__comment": "FIXME: Handle properties that are reset implicitly. https://drafts.csswg.org/css-fonts/#reset-implicitly",
LibWeb: Start parsing font property
2021-04-13 14:41:57 -03:00
"longhands": [
"font-family",
"font-size",
LibWeb/CSS: Make font-stretch a legacy alias for new font-width CSS Fonts level 4 renames font-stretch to font-width, with font-stretch being left as a legacy alias. Unfortunately the other specs have not yet been updated, so both terms are used in different places.
2024-09-27 10:04:59 -03:00
"font-width",
LibWeb: Fill out `font` property data
2023-09-26 12:17:02 -03:00
"font-style",
LibWeb: Start parsing font property
2021-04-13 14:41:57 -03:00
"font-variant",
LibWeb: Fill out `font` property data
2023-09-26 12:17:02 -03:00
"font-weight",
"line-height"
LibWeb: Start parsing font property
2021-04-13 14:41:57 -03:00
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"font-family": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb/CSS: Use `serif` for font and font-family initial property values These properties previously used sans-serif for their initial values.
2024-07-05 15:59:18 -03:00
"initial": "serif",
LibWeb: Allow font-family names to start with `-` We achieve this by making properties that accept a custom-ident value skip the "someone else's vendor prefix" check for values that start with a `-` character. This fixes an issue where e.g `font-family: Arial, -apple-system` would be rejected by the parser completely. We now treat `-apple-system` like an identifier in such cases. Also add `valid-types` metadata for the `font-family` property so this actually works. :^)
2023-07-06 08:05:48 -03:00
"valid-types": [
"custom-ident",
"string"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Parse and propagate font-feature-settings property
2024-10-01 05:37:43 -03:00
"font-feature-settings": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"integer [0,∞]",
"opentype-tag"
],
"valid-identifiers": [
"normal",
"on",
"off"
]
},
LibWeb/CSS: Implement the `font-kerning` property This sets whether the kerning information stored on the current font is used.
2025-06-22 14:59:42 -03:00
"font-kerning": {
"animation-type": "discrete",
"inherited": true,
"initial": "auto",
"valid-types": [
"font-kerning"
]
},
LibWeb/CSS: Parse and propagate the font-language-override property
2024-09-27 13:11:05 -03:00
"font-language-override": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"string"
],
"valid-identifiers": [
"normal"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"font-size": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "medium",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"large",
"larger",
"medium",
"small",
"smaller",
"x-large",
"x-small",
"xx-large",
"xx-small",
LibWeb: Implement `font-size: math` This is a MathML extension, basically a big hack to make parts of equations smaller, such as sub/superscripts. The important thing is, it works. :^)
2023-09-07 13:39:07 -03:00
"xxx-large",
"math"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse font-stretch CSS property
2023-02-03 08:27:09 -03:00
"font-stretch": {
LibWeb/CSS: Make font-stretch a legacy alias for new font-width CSS Fonts level 4 renames font-stretch to font-width, with font-stretch being left as a legacy alias. Unfortunately the other specs have not yet been updated, so both terms are used in different places.
2024-09-27 10:04:59 -03:00
"legacy-alias-for": "font-width"
LibWeb: Parse font-stretch CSS property
2023-02-03 08:27:09 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"font-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "normal",
LibWeb: Parse oblique `font-style` with an angle value
2025-05-02 09:55:58 -03:00
"valid-types": [
"font-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"font-variant": {
LibWeb: Add font-variant-* css properties
2024-11-07 12:27:04 -03:00
"inherited": true,
"initial": "normal",
"longhands": [
"font-variant-alternates",
"font-variant-caps",
"font-variant-east-asian",
"font-variant-emoji",
"font-variant-ligatures",
"font-variant-numeric",
"font-variant-position"
],
"valid-types": [
"string"
]
},
"font-variant-alternates": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-alternates"
]
},
"font-variant-caps": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-caps"
]
},
"font-variant-east-asian": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-east-asian"
]
},
"font-variant-emoji": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-emoji"
]
},
"font-variant-ligatures": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-ligatures"
]
},
"font-variant-numeric": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-types": [
"font-variant-numeric"
]
},
"font-variant-position": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "normal",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
LibWeb: Add font-variant-* css properties
2024-11-07 12:27:04 -03:00
"font-variant-position"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Parse and propagate font-variation-settings property
2024-10-01 05:20:06 -03:00
"font-variation-settings": {
"animation-type": "custom",
"inherited": true,
"initial": "normal",
"valid-types": [
"number",
"opentype-tag"
],
"valid-identifiers": [
"normal"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"font-weight": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "normal",
"valid-types": [
LibWeb: Add range-checking to property_accepts_value() For `number` and `integer` types, you can add a range afterwards to add a range check, using similar syntax to that used in the CSS specs. For example: ```json "font-weight": { ... "valid-types": [ "number [1,1000]" ], ... } ``` This limits any numbers to the range `1 <= n <= 1000`.
2021-09-23 08:45:08 -03:00
"number [1,1000]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"bold",
"bolder",
"lighter",
"normal"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Make font-stretch a legacy alias for new font-width CSS Fonts level 4 renames font-stretch to font-width, with font-stretch being left as a legacy alias. Unfortunately the other specs have not yet been updated, so both terms are used in different places.
2024-09-27 10:04:59 -03:00
"font-width": {
"animation-type": "by-computed-value",
"inherited": true,
"initial": "normal",
"valid-types": [
"percentage [0,∞]",
"font-width"
]
},
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"gap": {
"inherited": false,
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"initial": "normal",
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
],
"valid-identifiers": [
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"normal"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"longhands": [
"row-gap",
"column-gap"
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"grid": {
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
],
"percentages-resolve-to": "length",
"longhands": [
LibWeb: Correct longhands for `grid` property These three are the ones that ShorthandStyleValue uses to serialize `grid`, so let's use them here. The spec also mentions `grid-auto-*` properties as being set by `grid`, but I'll leave that for someone who understands grid better.
2023-09-26 11:59:01 -03:00
"grid-template-areas",
"grid-template-rows",
"grid-template-columns"
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
]
},
LibWeb: Parse `grid-area` CSS property
2023-01-16 15:02:39 -03:00
"grid-area": {
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
],
"longhands": [
"grid-column-end",
"grid-column-start",
"grid-row-end",
"grid-row-start"
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"grid-auto-columns": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
],
"percentages-resolve-to": "length"
},
"grid-auto-flow": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
"initial": "row"
},
"grid-auto-rows": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
],
"percentages-resolve-to": "length"
},
LibWeb: Parse grid-column and grid-row CSS values
2022-08-23 15:00:16 -03:00
"grid-column": {
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
],
"longhands": [
"grid-column-end",
"grid-column-start"
]
},
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"grid-column-end": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
]
},
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"grid-column-gap": {
LibWeb/CSS: Mark grid-[gap, column-gap, row-gap] properties as aliases These are legacy name aliases for the properties without the 'grid-' prefix. See https://drafts.csswg.org/css-align-3/#gap-legacy
2024-10-14 07:24:48 -03:00
"legacy-alias-for": "column-gap"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
},
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"grid-column-start": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
]
},
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"grid-gap": {
LibWeb/CSS: Mark grid-[gap, column-gap, row-gap] properties as aliases These are legacy name aliases for the properties without the 'grid-' prefix. See https://drafts.csswg.org/css-align-3/#gap-legacy
2024-10-14 07:24:48 -03:00
"legacy-alias-for": "gap"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
},
LibWeb: Parse grid-column and grid-row CSS values
2022-08-23 15:00:16 -03:00
"grid-row": {
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
],
"longhands": [
"grid-row-end",
"grid-row-start"
]
},
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"grid-row-end": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
]
},
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"grid-row-gap": {
LibWeb/CSS: Mark grid-[gap, column-gap, row-gap] properties as aliases These are legacy name aliases for the properties without the 'grid-' prefix. See https://drafts.csswg.org/css-align-3/#gap-legacy
2024-10-14 07:24:48 -03:00
"legacy-alias-for": "row-gap"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
},
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"grid-row-start": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"inherited": false,
"initial": "auto",
LibWeb: Parse `grid-template-areas` CSS property
2023-01-16 14:17:05 -03:00
"valid-identifiers": [
"auto"
],
"valid-types": [
"string"
]
},
LibWeb: Parse `grid-template` property
2023-04-29 14:32:56 -03:00
"grid-template": {
"inherited": false,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Parse `grid-template` property
2023-04-29 14:32:56 -03:00
"longhands": [
"grid-template-areas",
"grid-template-rows",
"grid-template-columns"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibWeb: Parse `grid-template` property
2023-04-29 14:32:56 -03:00
},
LibWeb: Parse `grid-template-areas` CSS property
2023-01-16 14:17:05 -03:00
"grid-template-areas": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse `grid-template-areas` CSS property
2023-01-16 14:17:05 -03:00
"inherited": false,
LibWeb: Correct grid-template-areas definition The spec syntax is `none | <string>+` and `none` is the default.
2023-12-07 18:07:21 -03:00
"initial": "none",
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
"valid-identifiers": [
LibWeb: Correct grid-template-areas definition The spec syntax is `none | <string>+` and `none` is the default.
2023-12-07 18:07:21 -03:00
"none"
LibWeb: Parse grid-column-start and related CSS properties Parse grid-column-start, end, and the equivalent for rows.
2022-08-23 14:58:00 -03:00
],
"valid-types": [
"string"
]
},
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
"grid-template-columns": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
"inherited": false,
LibWeb: Use none as initial value for grid-template-column/rows This fixes the issue that currently we use "auto" as initial value for grid-template-column and grid-template-rows although spec says it should be "none". This makes a lot of difference for these properties because currently we represent "auto" as a list with one auto-sized track which means initial value for grid-template-column defines one "explicit" track while it should define none of them. This change makes grid-auto-columns/rows be applied to the correct tracks when initial values is used for grid-template-column/rows.
2023-06-07 07:04:06 -03:00
"initial": "none",
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
"max-values": 4,
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
},
"grid-template-rows": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
"inherited": false,
LibWeb: Use none as initial value for grid-template-column/rows This fixes the issue that currently we use "auto" as initial value for grid-template-column and grid-template-rows although spec says it should be "none". This makes a lot of difference for these properties because currently we represent "auto" as a list with one auto-sized track which means initial value for grid-template-column defines one "explicit" track while it should define none of them. This change makes grid-auto-columns/rows be applied to the correct tracks when initial values is used for grid-template-column/rows.
2023-06-07 07:04:06 -03:00
"initial": "none",
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
"max-values": 4,
"valid-identifiers": [
"auto"
],
"valid-types": [
"length",
"percentage",
"string"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 14:49:07 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"height": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Accept height: {min,max,fit}-content And treat them as "auto" for now, per CSS-SIZING-3, with a FIXME about supporting more layout directions. This fixes an issue on MDN where `height: max-content` was not overriding height from non-CSS presentational hints.
2023-08-20 13:25:54 -03:00
"auto",
"max-content",
"min-content"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add support for CSS image-rendering property Currently only "auto" and "pixelated" values are supported.
2022-02-18 08:21:27 -03:00
"image-rendering": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add support for CSS image-rendering property Currently only "auto" and "pixelated" values are supported.
2022-02-18 08:21:27 -03:00
"inherited": true,
"initial": "auto",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"image-rendering"
LibWeb: Add support for CSS image-rendering property Currently only "auto" and "pixelated" values are supported.
2022-02-18 08:21:27 -03:00
]
},
LibWeb: Add support for the inline-size CSS property
2024-03-06 11:12:09 -03:00
"inline-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "size",
"mapping": "inline-size"
},
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"initial": "auto",
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb: Add support for the inline-size CSS property
2024-03-06 11:12:09 -03:00
},
LibWeb: Add support for parsing 'inset' shorthand CSS property
2023-05-29 22:43:37 -03:00
"inset": {
"inherited": false,
"initial": "auto",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add support for parsing 'inset' shorthand CSS property
2023-05-29 22:43:37 -03:00
"longhands": [
"top",
"right",
"bottom",
"left"
],
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add support for parsing 'inset' shorthand CSS property
2023-05-29 22:43:37 -03:00
],
"valid-identifiers": [
"auto"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add support for parsing 'inset' shorthand CSS property
2023-05-29 22:43:37 -03:00
},
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
"inset-block": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "auto",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"inset-block-start",
"inset-block-end"
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
],
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"valid-identifiers": [
"auto"
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
"inset-block-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "inset",
"mapping": "block-end"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
"inset-block-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "inset",
"mapping": "block-start"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
"inset-inline": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "auto",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"inset-inline-start",
"inset-inline-end"
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
],
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"valid-identifiers": [
"auto"
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
"inset-inline-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "inset",
"mapping": "inline-end"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
"inset-inline-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "inset",
"mapping": "inline-start"
},
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"max-values": 1,
"needs-layout-for-getcomputedstyle": true
LibWeb: Add logical CSS properties for insets This patch adds the following properties: - inset-inline - inset-inline-start - inset-inline-end - inset-block - inset-block-start - inset-block-end
2023-07-13 15:52:36 -03:00
},
LibWeb: Implement CSS 'isolation' property
2025-01-10 21:34:47 -03:00
"isolation": {
LibWeb: Update animation type of compositing properties This updates `background-blend-mode`, `mix-blend-mode`, and `isolation` to be animation type `discrete` rather than `none`. This reflects https://github.com/w3c/fxtf-drafts/commit/169b0e1 but isn't reflected on the published spec as the published spec is out of date - see https://github.com/w3c/fxtf-drafts/issues/547 Gains us 26 WPT tests.
2025-09-10 10:30:47 -03:00
"animation-type": "discrete",
LibWeb: Implement CSS 'isolation' property
2025-01-10 21:34:47 -03:00
"inherited": false,
"initial": "auto",
"valid-types": [
"isolation"
]
},
LibWeb: Add parsing for the justify-content property
2021-07-16 13:38:26 -03:00
"justify-content": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add parsing for the justify-content property
2021-07-16 13:38:26 -03:00
"inherited": false,
LibWeb: Support "normal" and "stretch" justify-content in CSS parser
2024-01-04 04:16:06 -03:00
"initial": "normal",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"justify-content"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add parsing for the justify-content property
2021-07-16 13:38:26 -03:00
},
LibWeb: Add support for justify-items property in CSS parser
2023-07-14 15:49:22 -03:00
"justify-items": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add support for justify-items property in CSS parser
2023-07-14 15:49:22 -03:00
"inherited": false,
"initial": "legacy",
"valid-types": [
"justify-items"
]
},
LibWeb: Add support for justify-self property in CSS parser
2023-07-14 09:41:22 -03:00
"justify-self": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add support for justify-self property in CSS parser
2023-07-14 09:41:22 -03:00
"inherited": false,
"initial": "auto",
"valid-types": [
"justify-self"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"left": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
LibWeb: Parse `anchor()` function for inset properties
2025-08-03 09:58:13 -03:00
"percentage [-∞,∞]",
"anchor"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"letter-spacing": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "normal",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-identifiers": [
"normal"
],
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"line-height": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "normal",
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"number [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"normal"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"list-style": {
LibWeb: Replace is_inherited_property() with generated code We already include the inheritance for each property in Properties.json, so made sense to use that instead of a list in StyleResolver. Added `inherited: true` to a couple of properties to match the previous code's behavior. One of those had a FIXME which I've moved to the JSON file, which is hacky, but it works.
2021-08-16 12:07:13 -03:00
"inherited": true,
LibWeb/CSS: Specify `list-style` subproperties in canonical order
2025-04-06 19:35:40 -03:00
"initial": "outside none disc",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"list-style-position",
LibWeb/CSS: Specify `list-style` subproperties in canonical order
2025-04-06 19:35:40 -03:00
"list-style-image",
"list-style-type"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
]
},
"list-style-image": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
"valid-types": [
"image"
],
"valid-identifiers": [
"none"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"list-style-position": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "outside",
LibWeb: Support list-style-position This moves the ::marker inside of <summary> actually inside. :^)
2023-06-02 18:05:15 -03:00
"valid-types": [
"list-style-position"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"list-style-type": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "disc",
"valid-types": [
LibWeb: Support strings as list-style-types We've long claimed to support this, but then silently ignored string values, until 4cb20635771a54f59cdb36616dbdcbd402ef080e which would not-so-silently crash instead. (Oops) So, actually pass the string value along and use it in the list marker. As part of this, rename our `list-style-type` enum to `counter-style-name-keyword`. This is an awkward name, attempting to be spec-based. (The spec says `<counter-style>`, which is either a `<counter-style-name>` or a function, and the `<counter-style-name>` is a `<custom-ident>` that also has a few predefined values. So this is the best I could come up with.) Unfortunately only one WPT test for this passes - the others fail because we produce a different layout when text is in `::before` than when it's in `::marker`, and similar issues.
2025-02-10 09:48:40 -03:00
"counter-style-name-keyword",
"string"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"margin": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"margin-top",
"margin-right",
"margin-bottom",
"margin-left"
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
],
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
"margin-block": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"margin-block-start",
"margin-block-end"
],
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"valid-identifiers": [
"auto"
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"margin-block-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "margin",
"mapping": "block-end"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"margin-block-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "margin",
"mapping": "block-start"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"margin-bottom": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
"margin-inline": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"margin-inline-start",
"margin-inline-end"
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
],
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"valid-identifiers": [
"auto"
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"margin-inline-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "margin",
"mapping": "inline-end"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"margin-inline-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "margin",
"mapping": "inline-start"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"margin-left": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"margin-right": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"margin-top": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add CSS `mask` property and make it form a stacking context
2023-09-03 15:44:00 -03:00
"mask": {
LibWeb/CSS: Parse mask shorthand-property into longhands This commit regresses a couple tests related to the mask shorthand property. This is because we now parse the longhands but there are errors related to serialization. Some of the failures are fixed again in the next commit. However, for some animation tests this is not the case. Those failures were simply masked by the fact that we did not parse the property correctly.
2025-07-18 15:36:14 -03:00
"__comment": "FIXME: reset mask-border",
LibWeb: Add CSS `mask` property and make it form a stacking context
2023-09-03 15:44:00 -03:00
"inherited": false,
LibWeb/CSS: Parse mask shorthand-property into longhands This commit regresses a couple tests related to the mask shorthand property. This is because we now parse the longhands but there are errors related to serialization. Some of the failures are fixed again in the next commit. However, for some animation tests this is not the case. Those failures were simply masked by the fact that we did not parse the property correctly.
2025-07-18 15:36:14 -03:00
"affects-layout": false,
LibWeb/CSS: Treat 'mask' as a longhand property Before this change, an element masked with 'mask-image: url(...)' would show the mask, but 'mask: url(...)' would not. On e.g. dialogic.nl it would show white boxes instead of the actual images in the top navigation bar. We still do not support many of the other mask properties, but with this change at least the masks show up in both cases.
2025-03-01 07:27:55 -03:00
"initial": "none",
"longhands": [
LibWeb/CSS: Parse mask shorthand-property into longhands This commit regresses a couple tests related to the mask shorthand property. This is because we now parse the longhands but there are errors related to serialization. Some of the failures are fixed again in the next commit. However, for some animation tests this is not the case. Those failures were simply masked by the fact that we did not parse the property correctly.
2025-07-18 15:36:14 -03:00
"mask-clip",
"mask-composite",
"mask-image",
"mask-mode",
"mask-origin",
"mask-position",
"mask-repeat",
"mask-size"
LibWeb/CSS: Treat 'mask' as a longhand property Before this change, an element masked with 'mask-image: url(...)' would show the mask, but 'mask: url(...)' would not. On e.g. dialogic.nl it would show white boxes instead of the actual images in the top navigation bar. We still do not support many of the other mask properties, but with this change at least the masks show up in both cases.
2025-03-01 07:27:55 -03:00
]
LibWeb: Add CSS `mask` property and make it form a stacking context
2023-09-03 15:44:00 -03:00
},
LibWeb/CSS: Parse mask-clip property
2025-07-18 15:36:12 -03:00
"mask-clip": {
"animation-type": "discrete",
"inherited": false,
"affects-layout": false,
"valid-types": [
"coord-box"
],
"valid-identifiers": [
"no-clip"
],
"initial": "border-box"
},
LibWeb/CSS: Parse mask-composite property
2025-07-18 15:36:06 -03:00
"mask-composite": {
"animation-type": "discrete",
"inherited": false,
"affects-layout": false,
"valid-types": [
"compositing-operator"
],
"initial": "add"
},
LibWeb: Implement `mask-image` CSS property support Implemented by reusing AddMask display list item that was initially added for `background-clip` property. Progress on flashlight effect on https://null.com/games/athena-crisis
2024-11-15 21:25:48 -03:00
"mask-image": {
"animation-type": "discrete",
"inherited": false,
"affects-layout": false,
LibWeb/CSS: Treat 'mask' as a longhand property Before this change, an element masked with 'mask-image: url(...)' would show the mask, but 'mask: url(...)' would not. On e.g. dialogic.nl it would show white boxes instead of the actual images in the top navigation bar. We still do not support many of the other mask properties, but with this change at least the masks show up in both cases.
2025-03-01 07:27:55 -03:00
"affects-stacking-context": true,
LibWeb: Implement `mask-image` CSS property support Implemented by reusing AddMask display list item that was initially added for `background-clip` property. Progress on flashlight effect on https://null.com/games/athena-crisis
2024-11-15 21:25:48 -03:00
"valid-types": [
LibWeb/CSS: Treat 'mask' as a longhand property Before this change, an element masked with 'mask-image: url(...)' would show the mask, but 'mask: url(...)' would not. On e.g. dialogic.nl it would show white boxes instead of the actual images in the top navigation bar. We still do not support many of the other mask properties, but with this change at least the masks show up in both cases.
2025-03-01 07:27:55 -03:00
"image",
"url"
LibWeb: Implement `mask-image` CSS property support Implemented by reusing AddMask display list item that was initially added for `background-clip` property. Progress on flashlight effect on https://null.com/games/athena-crisis
2024-11-15 21:25:48 -03:00
],
"valid-identifiers": [
"none"
],
"initial": "none"
},
LibWeb/CSS: Parse mask-mode property
2025-07-18 15:36:07 -03:00
"mask-mode": {
"animation-type": "discrete",
"inherited": false,
"affects-layout": false,
"valid-types": [
"masking-mode"
],
"initial": "match-source"
},
LibWeb/CSS: Parse mask-origin property
2025-07-18 15:36:11 -03:00
"mask-origin": {
"animation-type": "discrete",
"inherited": false,
"affects-layout": false,
"valid-types": [
"coord-box"
],
"initial": "border-box"
},
LibWeb/CSS: Parse mask-position property
2025-07-18 15:36:08 -03:00
"mask-position": {
"animation-type": "repeatable-list",
"affects-layout": false,
"inherited": false,
"initial": "0% 0%",
"valid-types": [
"position"
],
"percentages-resolve-to": "length"
},
LibWeb/CSS: Parse mask-repeat property
2025-07-18 15:36:10 -03:00
"mask-repeat": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": false,
"initial": "repeat",
"max-values": 2,
"valid-types": [
"repetition"
],
"valid-identifiers": [
"repeat-x",
"repeat-y"
]
},
LibWeb/CSS: Parse mask-size property
2025-07-18 15:36:11 -03:00
"mask-size": {
"affects-layout": false,
"animation-type": "repeatable-list",
"inherited": false,
"initial": "auto",
"max-values": 2,
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
],
"valid-identifiers": [
"auto",
"cover",
"contain"
],
"percentages-resolve-to": "length"
},
LibWeb: Implement `mask-type` CSS property This property allows specifying if a mask is an alpha or luminance mask. See: https://drafts.fxtf.org/css-masking/#the-mask-type
2023-10-08 07:06:34 -03:00
"mask-type": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Implement `mask-type` CSS property This property allows specifying if a mask is an alpha or luminance mask. See: https://drafts.fxtf.org/css-masking/#the-mask-type
2023-10-08 07:06:34 -03:00
"inherited": false,
"affects-layout": false,
"valid-types": [
"mask-type"
],
"initial": "luminance"
},
LibWeb: Implement the `math-depth` CSS property This one is a bit fun because it can be `add(<integer>)` or `auto-add`, but children have to inherit the computed value not the specified one. We also have to compute it before computing the font-size, because of `font-size: math` which will be implemented later.
2023-09-07 11:29:54 -03:00
"math-depth": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Implement the `math-depth` CSS property This one is a bit fun because it can be `add(<integer>)` or `auto-add`, but children have to inherit the computed value not the specified one. We also have to compute it before computing the font-size, because of `font-size: math` which will be implemented later.
2023-09-07 11:29:54 -03:00
"inherited": true,
"initial": "0",
"__comment": "FIXME: `add(<integer>)` is also valid but we can't represent that here yet.",
"valid-types": [
"integer"
],
"valid-identifiers": [
"auto-add"
]
},
LibWeb: Parse the `math-shift` and `math-style` CSS properties Currently these have no effect, but they're simple, and `math-style` influences `math-depth` which is coming next.
2023-09-05 16:23:15 -03:00
"math-shift": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Parse the `math-shift` and `math-style` CSS properties Currently these have no effect, but they're simple, and `math-style` influences `math-depth` which is coming next.
2023-09-05 16:23:15 -03:00
"inherited": true,
"initial": "normal",
"valid-types": [
"math-shift"
]
},
"math-style": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Parse the `math-shift` and `math-style` CSS properties Currently these have no effect, but they're simple, and `math-style` influences `math-depth` which is coming next.
2023-09-05 16:23:15 -03:00
"inherited": true,
"initial": "normal",
"valid-types": [
"math-style"
]
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"max-block-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "max-size",
"mapping": "block-size"
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"initial": "none"
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"max-height": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Allow intrinsic size keywords for `min-height` and `max-height`
2024-10-27 14:28:10 -03:00
"max-content",
"min-content",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"none"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Support min-inline-size & max-inline-size Currently this assumes that writing-mode is horizontal, and therefore only affects the min-width/max-width
2023-05-23 04:29:01 -03:00
"max-inline-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "max-size",
"mapping": "inline-size"
},
LibWeb: Support min-inline-size & max-inline-size Currently this assumes that writing-mode is horizontal, and therefore only affects the min-width/max-width
2023-05-23 04:29:01 -03:00
"initial": "none"
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"max-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "none",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Support `max-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 13:18:34 -03:00
"max-content",
LibWeb: Support `min-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 13:24:55 -03:00
"min-content",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"none"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"min-block-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "min-size",
"mapping": "block-size"
},
LibWeb/CSS: Implement the ({min,max}-)block-size properties These are heavily used by morrisons.com, using them in place of the usual properties these map to.
2025-01-29 11:17:52 -03:00
"initial": "0"
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"min-height": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Allow intrinsic size keywords for `min-height` and `max-height`
2024-10-27 14:28:10 -03:00
"auto",
"max-content",
"min-content"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Support min-inline-size & max-inline-size Currently this assumes that writing-mode is horizontal, and therefore only affects the min-width/max-width
2023-05-23 04:29:01 -03:00
"min-inline-size": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "min-size",
"mapping": "inline-size"
},
LibWeb: Support min-inline-size & max-inline-size Currently this assumes that writing-mode is horizontal, and therefore only affects the min-width/max-width
2023-05-23 04:29:01 -03:00
"initial": "0"
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"min-width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Add missing "auto" identifiers for min-width/height Both of these have "auto" as their initial value, so the only reason they work currently is that "auto" is implicitly a Length.
2022-01-16 18:35:33 -03:00
"auto",
LibWeb: Support `max-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 13:18:34 -03:00
"max-content",
LibWeb: Disallow `none` for `min-width` and `min-height`
2024-10-27 14:26:28 -03:00
"min-content"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 05:50:49 -03:00
"mix-blend-mode": {
LibWeb: Update animation type of compositing properties This updates `background-blend-mode`, `mix-blend-mode`, and `isolation` to be animation type `discrete` rather than `none`. This reflects https://github.com/w3c/fxtf-drafts/commit/169b0e1 but isn't reflected on the published spec as the published spec is out of date - see https://github.com/w3c/fxtf-drafts/issues/547 Gains us 26 WPT tests.
2025-09-10 10:30:47 -03:00
"animation-type": "discrete",
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 05:50:49 -03:00
"inherited": false,
"initial": "normal",
"valid-types": [
"mix-blend-mode"
]
},
LibWeb: Add 'object-fit' property This patch adds support for the 'object-fit' CSS property. :^)
2023-08-01 15:06:50 -03:00
"object-fit": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add 'object-fit' property This patch adds support for the 'object-fit' CSS property. :^)
2023-08-01 15:06:50 -03:00
"inherited": false,
"initial": "fill",
"valid-types": [
"object-fit"
]
},
LibWeb: Add 'object-position' property and 'position' enum This patch adds the 'object-position' CSS property description to the json for code generation. Also the 'position' enum is added. The values of this enum are the valid inputs to the object-position property from CSS Values-4.
2023-10-16 08:49:52 -03:00
"object-position": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "repeatable-list",
LibWeb: Add 'object-position' property and 'position' enum This patch adds the 'object-position' CSS property description to the json for code generation. Also the 'position' enum is added. The values of this enum are the valid inputs to the object-position property from CSS Values-4.
2023-10-16 08:49:52 -03:00
"affects-layout": false,
"inherited": false,
"initial": "50% 50%",
"valid-types": [
"position"
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add 'object-position' property and 'position' enum This patch adds the 'object-position' CSS property description to the json for code generation. Also the 'position' enum is added. The values of this enum are the valid inputs to the object-position property from CSS Values-4.
2023-10-16 08:49:52 -03:00
},
LibWeb: Parse and store the opacity property
2021-07-23 07:18:09 -03:00
"opacity": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Only invalidate stacking context tree for opacity/z-index change I came across some websites that change an elements CSS "opacity" in their :hover selectors. That caused us to relayout on hover, which we'd like to avoid. With this patch, we now check if a property only affects the stacking context tree, and if nothing layout-affecting has changed, we only invalidate the stacking context tree, causing it to be rebuilt on next paint or hit test. This makes :hover { opacity: ... } rules much faster. :^)
2022-03-21 06:58:51 -03:00
"affects-layout": false,
"affects-stacking-context": true,
LibWeb: Parse and store the opacity property
2021-07-23 07:18:09 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "1",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"number [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
"__comment": "We don't have a percentages-resolve-to here because even though we're supposed to map percentages to [0,1], calc(10%) should resolve to 10% not 0.1."
LibWeb: Parse and store the opacity property
2021-07-23 07:18:09 -03:00
},
LibWeb: Fix order/formatting of Properties.json
2023-06-02 13:23:00 -03:00
"order": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Fix order/formatting of Properties.json
2023-06-02 13:23:00 -03:00
"inherited": false,
"initial": "0",
"valid-types": [
"integer [-∞,∞]"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"outline": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Implement the CSS `outline` property :^) ...along with `outline-color`, `outline-style`, and `outline-width`. This re-uses the existing border-painting code, which seems to work well enough! This replaces the previous code for drawing focus-outlines, with generic outline painting for any elements that want it. Focus outlines are now instead supported by this code in Default.css: ```css :focus-visible { outline: auto; } ```
2023-08-02 13:24:14 -03:00
"initial": "medium currentColor none",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"longhands": [
"outline-color",
"outline-style",
"outline-width"
]
},
"outline-color": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Implement the CSS `outline` property :^) ...along with `outline-color`, `outline-style`, and `outline-width`. This re-uses the existing border-painting code, which seems to work well enough! This replaces the previous code for drawing focus-outlines, with generic outline painting for any elements that want it. Focus outlines are now instead supported by this code in Default.css: ```css :focus-visible { outline: auto; } ```
2023-08-02 13:24:14 -03:00
"__comment": "FIXME: We don't yet support `invert`. Until we do, the spec directs us to use `currentColor` as the default instead, and reject `invert`",
"initial": "currentColor",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
"color"
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibWeb: Implement the CSS `outline-offset` property This allows you to push the outline a certain distance away from the border (or inside it, if the offset is negative).
2023-08-02 16:09:10 -03:00
"outline-offset": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Implement the CSS `outline-offset` property This allows you to push the outline a certain distance away from the border (or inside it, if the offset is negative).
2023-08-02 16:09:10 -03:00
"inherited": false,
"initial": "0",
"valid-types": [
"length [-∞,∞]"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"outline-style": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
LibWeb: Implement the CSS `outline` property :^) ...along with `outline-color`, `outline-style`, and `outline-width`. This re-uses the existing border-painting code, which seems to work well enough! This replaces the previous code for drawing focus-outlines, with generic outline painting for any elements that want it. Focus outlines are now instead supported by this code in Default.css: ```css :focus-visible { outline: auto; } ```
2023-08-02 13:24:14 -03:00
"outline-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
"outline-width": {
LibWeb: Annotate which CSS properties may affect layout This patch adds CSS::property_affects_layout(PropertyID) which tells us whether a CSS property would affect layout if it were changed. This will be used to avoid unnecessary relayout work when something changes that really only requires us to repaint the page. To mark a property as not affecting layout, set "affects-layout" to false in the corresponding Properties.json entry. Note that all properties affect layout by default.
2022-03-16 13:46:24 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "medium",
"valid-types": [
LibWeb: Create enum for <line-width> keywords
2025-07-09 07:32:40 -03:00
"length [0,∞]",
"line-width"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
"overflow": {
"longhands": [
"overflow-x",
"overflow-y"
],
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "visible",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"overflow"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
},
"overflow-x": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "visible",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"overflow"
LibWeb/CSS: Support `overlay` keyword as alias to `auto` in `overflow` We don't yet have a system for "legacy value aliases", but until we have a lot of them we can handle them manually. We also have to do this in two places because parse_css_value_for_property() doesn't call any property-specific parsing code.
2025-07-17 06:44:29 -03:00
],
"valid-identifiers": [
LibWeb/CSS: Implement "legacy value aliases" in generated code This uses a `foo>bar` notation in the `valid-identifiers` field of Properties.json, to say "replace `foo` with `bar`". The motivation here is to avoid calling `parse_css_value_for_property()` inside the per-property switch in `parse_css_value()`. Eventually we'll need to be able to call that switch from `parse_css_value_for_properties()` so that shorthands can make use of any bespoke parsing code to parse their longhands.
2025-07-21 08:22:18 -03:00
"overlay>auto"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
},
"overflow-y": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "visible",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"overflow"
LibWeb/CSS: Support `overlay` keyword as alias to `auto` in `overflow` We don't yet have a system for "legacy value aliases", but until we have a lot of them we can handle them manually. We also have to do this in two places because parse_css_value_for_property() doesn't call any property-specific parsing code.
2025-07-17 06:44:29 -03:00
],
"valid-identifiers": [
LibWeb/CSS: Implement "legacy value aliases" in generated code This uses a `foo>bar` notation in the `valid-identifiers` field of Properties.json, to say "replace `foo` with `bar`". The motivation here is to avoid calling `parse_css_value_for_property()` inside the per-property switch in `parse_css_value()`. Eventually we'll need to be able to call that switch from `parse_css_value_for_properties()` so that shorthands can make use of any bespoke parsing code to parse their longhands.
2025-07-21 08:22:18 -03:00
"overlay>auto"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 11:20:31 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"padding": {
LibWeb: Add initial values for all CSS properties It's a little verbose to repeat these in cases like the borders, but if everything has an initial value, we can guarantee that `property_initial_value()` will return something! :^)
2021-11-10 10:43:52 -03:00
"inherited": false,
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"longhands": [
"padding-top",
"padding-right",
"padding-bottom",
"padding-left"
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
],
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
"padding-block": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"padding-block-start",
"padding-block-end"
],
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"padding-block-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "padding",
"mapping": "block-end"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"padding-block-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "padding",
"mapping": "block-start"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"padding-bottom": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
"padding-inline": {
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"initial": "0",
LibWeb: Mark relevant properties as "positional-value-list-shorthands" Some shorthand properties work differently to normal in that mapping of provided values to longhands isn't necessarily 1-to-1 and depends on the number of values provided, for example `margin`, `border-width`, `gap`, etc. These properties have distinct behaviors in how they are parsed and serialized, having them marked allows us to implement theses behaviors in a generic way. No functionality changes.
2025-07-10 05:21:45 -03:00
"positional-value-list-shorthand": true,
LibWeb: Convert logical property shorthands to full-fledged shorthands No functionality changes. This is just prep work for later commits around moving logical alias mapping to cascade time
2025-06-15 01:14:28 -03:00
"longhands": [
"padding-inline-start",
"padding-inline-end"
],
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
],
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
"percentages-resolve-to": "length",
"needs-layout-for-getcomputedstyle": true
LibWeb: Add naive support for {margin,padding}-{block,inline} Like other logical properties, we just alias these to the LTR TB default properties for now.
2023-06-07 04:13:21 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"padding-inline-end": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "padding",
"mapping": "inline-end"
}
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"padding-inline-start": {
LibWeb: Generate logical property mappings To support this, how we declare logical property aliases has changed. Instead of `logical-alias-for` being a list of properties, it's now an object with a `group` and `mapping`. The group is the name of a logical property group in LogicalPropertyGroups.json. The mapping is which side/dimension/corner this property is. Hopefully it's self-explanatory enough. The generated code is very much a copy of what was previously in `StyleComputer::map_logical_alias_to_physical_property_id()`, so there should be no behaviour change.
2025-07-03 10:31:26 -03:00
"logical-alias-for": {
"group": "padding",
"mapping": "inline-start"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
},
"needs-layout-for-getcomputedstyle": true
LibWeb: Add CSS logical property aliases for margin and padding sides These just map to the LTR+TB defaults for now, as we don't yet resolve any of the inputs to the logical property selection algorithm.
2023-06-06 07:24:08 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"padding-left": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"padding-right": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"padding-top": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb/CSS: Parse the `paint-order` property
2025-08-24 11:00:53 -03:00
"paint-order": {
"animation-type": "discrete",
"inherited": true,
"initial": "normal",
"valid-identifiers": [
"normal"
],
"valid-types": [
"paint-order"
]
},
LibWeb: Add support for parsing place-content shorthand CSS property
2023-05-29 17:34:53 -03:00
"place-content": {
"inherited": false,
"initial": "normal",
"longhands": [
"align-content",
"justify-content"
]
},
LibWeb: Add support for "place-items" CSS property Adds support for place-items property which allows to specify both align-items and justify-items in a single declaration.
2023-07-17 11:34:12 -03:00
"place-items": {
"inherited": false,
"initial": "normal",
"longhands": [
"align-items",
"justify-items"
]
},
LibWeb: Add place-self css property support
2023-08-04 09:04:05 -03:00
"place-self": {
"inherited": false,
"initial": "normal",
"longhands": [
"align-self",
"justify-self"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"pointer-events": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": true,
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 15:47:13 -03:00
"initial": "auto",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"pointer-events"
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 15:47:13 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibHTML: Add the CSS "position" property to CSS/Properties.json
2019-11-19 14:20:54 -03:00
"position": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Add the CSS "position" property to CSS/Properties.json
2019-11-19 14:20:54 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "static",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
LibWeb: Rename "position" enum to "positioning" The postitioning enum values are used by the position CSS property. Unfortunately, the prior naming clashes with the CSS Values-4 type named position, which will be implemented in a later commit.
2023-10-27 10:17:36 -03:00
"positioning"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Add the CSS "position" property to CSS/Properties.json
2019-11-19 14:20:54 -03:00
},
LibWeb: Parse and compute CSS `quotes` property
2023-09-12 07:34:26 -03:00
"quotes": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse and compute CSS `quotes` property
2023-09-12 07:34:26 -03:00
"inherited": true,
"initial": "auto",
"valid-types": [
"string"
],
"valid-identifiers": [
"auto",
"none"
]
},
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
"r": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#R.",
"animation-type": "by-computed-value",
"inherited": false,
"initial": "0",
"valid-types": [
LibWeb/SVG: Disallow negative values for SVG radius properties
2025-06-27 17:05:40 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"right": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
LibWeb: Parse `anchor()` function for inset properties
2025-08-03 09:58:13 -03:00
"percentage [-∞,∞]",
"anchor"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse the rotate css property
2024-10-16 03:50:35 -03:00
"rotate": {
"animation-type": "custom",
"inherited": false,
"initial": "none",
"affects-layout": false,
"affects-stacking-context": true
},
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"row-gap": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"inherited": false,
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"initial": "normal",
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
"valid-types": [
"length [0,∞]",
"percentage [0,∞]"
],
"valid-identifiers": [
LibWeb: Restrict CSS gap properties to values allowed by the spec Gap values are now represented by Variant<LengthPercentage, NormalGap>. NormalGap is just an empty struct to represent the `normal` keyword. This fixes a long-standing issue where we were incorrectly storing gaps as CSS::Size, which led to us allowing a bunch of invalid gap values.
2024-11-09 13:38:09 -03:00
"normal"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 08:42:22 -03:00
},
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
"rx": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#RX.",
"animation-type": "by-computed-value",
"inherited": false,
"initial": "auto",
"valid-types": [
LibWeb/SVG: Disallow negative values for SVG radius properties
2025-06-27 17:05:40 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
],
"valid-identifiers": [
"auto"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
"ry": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#RY.",
"animation-type": "by-computed-value",
"inherited": false,
"initial": "auto",
"valid-types": [
LibWeb/SVG: Disallow negative values for SVG radius properties
2025-06-27 17:05:40 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Define the rest of the SVG geometry properties This defines all the (remaining) geometry properties from https://svgwg.org/svg2-draft/geometry.html#Sizing.
2023-02-25 06:31:00 -03:00
],
"valid-identifiers": [
"auto"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
LibWeb: Support individual `scale` CSS property
2024-11-22 14:07:16 -03:00
"scale": {
"animation-type": "custom",
"inherited": false,
"initial": "none",
"affects-layout": false,
"affects-stacking-context": true
},
LibWeb/CSS: Implement the `scrollbar-color` property This allows the user to set the scrollbar thumb and track colors.
2025-05-26 18:36:12 -03:00
"scrollbar-color": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": "yes",
"initial": "auto"
},
LibWeb: Implement support for scrollbar-gutter This property is now correctly parsed. Ladybird always uses overlay scrollbars so this property does nothing.
2024-06-26 19:19:38 -03:00
"scrollbar-gutter": {
"affects-layout": false,
"animation-type": "discrete",
"__comment": "This property should affect layout per-spec, but ladybird always uses overlay scrollbars so it doesn't in practice.",
"inherited": false,
"initial": "auto"
},
LibWeb: Parse the CSS scrollbar-width property
2024-02-27 05:37:18 -03:00
"scrollbar-width": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": false,
"initial": "auto",
LibWeb: Format Properties.json
2024-07-24 05:51:31 -03:00
"valid-types": [
"scrollbar-width"
],
LibWeb: Parse the CSS scrollbar-width property
2024-02-27 05:37:18 -03:00
"valid-identifiers": [
"auto",
"thin",
"none"
]
},
LibWeb: Parse the `shape-rendering` property
2025-08-16 13:48:30 -03:00
"shape-rendering": {
"affects-layout": true,
"animation-type": "discrete",
"inherited": true,
"initial": "auto",
"valid-types": [
"shape-rendering"
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"stop-color": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
"initial": "black",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"color"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add for CSS `fill/stroke/stroke-color` properties for SVG In the spec, `fill` and `stroke` are supposed to be a shorthands for various properties. But since the spec is still a working draft, and neither Firefox or Chrome support the `fill-color` or `stroke-color` properties, we'll stick with `fill` and `stroke` as simple colors for now. Also, note that SVG expects things in "user units", and we are assuming that 1px = 1 user unit for now.
2021-09-16 08:28:14 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"stop-opacity": {
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"initial": "1",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"number [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
"__comment": "We don't have a percentages-resolve-to here for the same reason as for opacity."
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"stroke": {
LibWeb: Add stop-color as a CSS property (This is to set the color of a stop for an SVG gradient)
2023-04-19 14:51:00 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": true,
"initial": "none",
LibWeb: Add stop-color as a CSS property (This is to set the color of a stop for an SVG gradient)
2023-04-19 14:51:00 -03:00
"valid-types": [
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"paint"
LibWeb: Add stop-color as a CSS property (This is to set the color of a stop for an SVG gradient)
2023-04-19 14:51:00 -03:00
]
},
LibWeb: Plumbing for svg stroke-dasharray
2024-11-20 21:23:10 -03:00
"stroke-dasharray": {
"animation-type": "custom",
"inherited": true,
"initial": "none",
"affects-layout": false
},
LibWeb: Plumbing for svg stroke-dashoffset
2024-11-18 23:21:22 -03:00
"stroke-dashoffset": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": true,
LibWeb: Set the initial value of `stroke-dashoffset` to 0px Previously, an initial value of 0 was being used.
2025-08-16 11:52:58 -03:00
"initial": "0px",
LibWeb: Plumbing for svg stroke-dashoffset
2024-11-18 23:21:22 -03:00
"valid-types": [
"length [0,∞]",
"number [0,∞]",
"percentage [0,∞]"
],
"percentages-resolve-to": "length"
},
LibWeb: Add stroke-linecap attribute and plumb it to SVGGraphicsElement SVGGraphicsElement then goes ahead and does nothing with it for now.
2024-10-10 11:15:49 -03:00
"stroke-linecap": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
"initial": "butt",
"valid-types": [
"stroke-linecap"
]
},
LibWeb: Parse stroke-{linejoin,miterlimit} attributes Similar to LadybirdBrowser/ladybird#1714. We don't implement the linejoin values `miter-clip` and `arcs`, because according to the SVG 2 spec: > The values miter-clip and arcs of the stroke-linejoin property are at > risk. There are no known browser implementations. See issue Github > issue w3c/svgwg#592. Nothing uses this yet. The next step is to change SVGPathPaintable::paint() to read `graphics_element.stroke_linejoin()` and `graphics_element.stroke_miterlimit()` when painting.
2024-10-28 21:51:16 -03:00
"stroke-linejoin": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
"initial": "miter",
"valid-types": [
"stroke-linejoin"
]
},
"stroke-miterlimit": {
"affects-layout": false,
"animation-type": "by-computed-value",
"inherited": true,
"initial": "4",
"valid-types": [
"number [0,∞]"
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"stroke-opacity": {
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": true,
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
"initial": "1",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"number [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
LibWeb/CSS: Correct "percentages-resolve-to" data for properties These were missing for properties that take a `<position>`, and were incorrectly present for opacity-related properties.
2025-01-31 08:46:18 -03:00
"__comment": "We don't have a percentages-resolve-to here for the same reason as for opacity."
LibWeb: Implement SVG opacity properties This implements the stop-opacity, fill-opacity, and stroke-opacity properties (in CSS). This replaces the existing more ad-hoc fill-opacity attribute handling.
2023-05-19 16:35:39 -03:00
},
LibWeb: Add for CSS `fill/stroke/stroke-color` properties for SVG In the spec, `fill` and `stroke` are supposed to be a shorthands for various properties. But since the spec is still a working draft, and neither Firefox or Chrome support the `fill-color` or `stroke-color` properties, we'll stick with `fill` and `stroke` as simple colors for now. Also, note that SVG expects things in "user units", and we are assuming that 1px = 1 user unit for now.
2021-09-16 08:28:14 -03:00
"stroke-width": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Add for CSS `fill/stroke/stroke-color` properties for SVG In the spec, `fill` and `stroke` are supposed to be a shorthands for various properties. But since the spec is still a working draft, and neither Firefox or Chrome support the `fill-color` or `stroke-color` properties, we'll stick with `fill` and `stroke` as simple colors for now. Also, note that SVG expects things in "user units", and we are assuming that 1px = 1 user unit for now.
2021-09-16 08:28:14 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "1px",
"valid-types": [
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"number [0,∞]",
"percentage [0,∞]"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Add for CSS `fill/stroke/stroke-color` properties for SVG In the spec, `fill` and `stroke` are supposed to be a shorthands for various properties. But since the spec is still a working draft, and neither Firefox or Chrome support the `fill-color` or `stroke-color` properties, we'll stick with `fill` and `stroke` as simple colors for now. Also, note that SVG expects things in "user units", and we are assuming that 1px = 1 user unit for now.
2021-09-16 08:28:14 -03:00
},
LibWeb/CSS: Parse the tab-size property
2024-10-01 09:07:06 -03:00
"tab-size": {
"animation-type": "by-computed-value",
"inherited": true,
"initial": "8",
"valid-types": [
"length [0,∞]",
"number [0,∞]"
]
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"table-layout": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": false,
"initial": "auto",
LibWeb: Add an initial implementation of SVG `text-anchor` This only handles very simple <text> elements, but this is enough (with the font-size changes) to improve the badges on the GitHub README a fair bit.
2023-07-19 15:12:00 -03:00
"valid-types": [
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"table-layout"
LibWeb: Add an initial implementation of SVG `text-anchor` This only handles very simple <text> elements, but this is enough (with the font-size changes) to improve the badges on the GitHub README a fair bit.
2023-07-19 15:12:00 -03:00
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"text-align": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add `start` and `end` values to `text-align` The `start` and `end` value set the text alignment based on the computed value of `direction`. The default value of `text-align` is now `start` instead of `left`.
2024-08-11 14:14:12 -03:00
"initial": "start",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"text-align"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"text-anchor": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"inherited": true,
"initial": "start",
"valid-types": [
"text-anchor"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"text-decoration": {
LibWeb: Mark all text-decoration* CSS properties as not affecting layout
2022-03-16 15:11:25 -03:00
"affects-layout": false,
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
"inherited": false,
"initial": "none",
"longhands": [
"text-decoration-color",
"text-decoration-line",
"text-decoration-style",
"text-decoration-thickness"
]
},
"text-decoration-color": {
LibWeb: Mark all text-decoration* CSS properties as not affecting layout
2022-03-16 15:11:25 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "currentcolor",
"valid-types": [
"color"
]
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
},
"text-decoration-line": {
LibWeb: Annotate which CSS properties may affect layout This patch adds CSS::property_affects_layout(PropertyID) which tells us whether a CSS property would affect layout if it were changed. This will be used to avoid unnecessary relayout work when something changes that really only requires us to repaint the page. To mark a property as not affecting layout, set "affects-layout" to false in the corresponding Properties.json entry. Note that all properties affect layout by default.
2022-03-16 13:46:24 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
"__comment": "FIXME: This property is not supposed to be inherited, but we currently rely on inheritance to propagate decorations into line boxes.",
LibWeb: Replace is_inherited_property() with generated code We already include the inheritance for each property in Properties.json, so made sense to use that instead of a list in StyleResolver. Added `inherited: true` to a couple of properties to match the previous code's behavior. One of those had a FIXME which I've moved to the JSON file, which is hacky, but it works.
2021-08-16 12:07:13 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"text-decoration-line"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
},
"text-decoration-style": {
LibWeb: Mark all text-decoration* CSS properties as not affecting layout
2022-03-16 15:11:25 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "solid",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"text-decoration-style"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 09:36:27 -03:00
},
"text-decoration-thickness": {
LibWeb: Mark all text-decoration* CSS properties as not affecting layout
2022-03-16 15:11:25 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Correct initial values in Properties.json - `align-items`: `normal` is the initial value in the CSS-ALIGN spec, but `stretch` is in CSS-FLEXBOX. The FLEXBOX spec is the one we've actually implemented elsewhere, and ALIGN adds new values with special syntax, so it's not trivial to add it here. - `border-spacing`: `0` is equivalent to `0px 0px` and we don't yet parse the double-value syntax. - `text-decoration-thickness`: Had the wrong value.
2021-11-10 10:27:16 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto",
"from-font"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
"text-indent": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "0",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add support for the text-justify property This commit adds the text-justify property as defined in: https://drafts.csswg.org/css-text/#propdef-text-justify
2022-03-12 16:31:32 -03:00
"text-justify": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add support for the text-justify property This commit adds the text-justify property as defined in: https://drafts.csswg.org/css-text/#propdef-text-justify
2022-03-12 16:31:32 -03:00
"inherited": true,
"initial": "auto",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"text-justify"
LibWeb/CSS: Support `text-justify: distribute` legacy value alias ...for `text-justify: inter-character`. We previously had this mapped in Enums.json, but the behaviour is different: `a=b` in Enums.json keeps `a` around but makes it behave the same as `b`. A legacy name alias is instead expected to replace `a` with `b`, so we have to do that separately.
2025-07-17 06:50:35 -03:00
],
"valid-identifiers": [
LibWeb/CSS: Implement "legacy value aliases" in generated code This uses a `foo>bar` notation in the `valid-identifiers` field of Properties.json, to say "replace `foo` with `bar`". The motivation here is to avoid calling `parse_css_value_for_property()` inside the per-property switch in `parse_css_value()`. Eventually we'll need to be able to call that switch from `parse_css_value_for_properties()` so that shorthands can make use of any bespoke parsing code to parse their longhands.
2025-07-21 08:22:18 -03:00
"distribute>inter-character"
LibWeb: Add support for the text-justify property This commit adds the text-justify property as defined in: https://drafts.csswg.org/css-text/#propdef-text-justify
2022-03-12 16:31:32 -03:00
]
},
LibWeb: Add "text-overflow" property to code generation The CSS property "text-overflow" as well as its valid identifiers are added to the relevant json files for code generation
2024-07-24 15:52:21 -03:00
"text-overflow": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": false,
"initial": "clip",
"valid-types": [
"text-overflow"
]
},
LibWeb/CSS: Add the `text-rendering` property
2025-06-27 03:03:05 -03:00
"text-rendering": {
"affects-layout": false,
"animation-type": "discrete",
"inherited": true,
"initial": "auto",
"valid-types": [
"text-rendering"
]
},
LibWeb: Parse and compute text-shadow property
2022-03-23 18:16:36 -03:00
"text-shadow": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibWeb: Parse and compute text-shadow property
2022-03-23 18:16:36 -03:00
"inherited": true,
"initial": "none",
"valid-identifiers": [
"none"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"text-transform": {
LibWeb: Update the layout tree when CSS text-transform changes Because we cache the transformed text string in text nodes affected by text-transform, we have to actually update the layout tree when this property value changes.
2025-03-08 13:54:04 -03:00
"__comment": "NOTE: This property has custom invalidation handling.",
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "none",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"text-transform"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse and compute `text-underline-offset` property
2025-09-11 07:00:19 -03:00
"text-underline-offset": {
"animation-type": "by-computed-value",
"inherited": true,
"initial": "auto",
"valid-identifiers": [
"auto"
],
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length"
},
LibWeb: Implement `text-wrap` CSS property This resolves an issue introduced in 94f5a51 with the tab-size-text-wrap test
2025-05-31 05:40:39 -03:00
"text-wrap": {
"inherited": true,
"initial": "wrap",
"longhands": [
"text-wrap-mode",
"text-wrap-style"
]
},
LibWeb: Parse and propagate `text-wrap-mode` CSS property
2025-05-17 09:49:25 -03:00
"text-wrap-mode": {
"animation-type": "discrete",
"inherited": true,
"initial": "wrap",
"valid-types": [
"text-wrap-mode"
]
},
LibWeb: Implement `text-wrap-style` CSS property
2025-05-31 05:31:07 -03:00
"text-wrap-style": {
"animation-type": "discrete",
"inherited": true,
"initial": "auto",
"valid-types": [
"text-wrap-style"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"top": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
LibWeb: Parse `anchor()` function for inset properties
2025-08-03 09:58:13 -03:00
"percentage [-∞,∞]",
"anchor"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse and propagate touch-action CSS property Co-authored-by: Sam Atkins <sam@ladybird.org>
2025-03-16 22:44:49 -03:00
"touch-action": {
"animation-type": "discrete",
"inherited": false,
"initial": "auto",
"max-values": 2,
"valid-types": [
"touch-action"
]
},
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 12:20:00 -03:00
"transform": {
LibWeb: Revert changing transform's animation-type to by-computed-value In the upcoming commits where we properly handle transformation interpolation, it actually becomes easier to change this back to custom, so lets do that since its more correct anyways.
2024-02-28 22:47:49 -03:00
"animation-type": "custom",
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 12:20:00 -03:00
"inherited": false,
LibWeb: Mark `transform` property as affecting stacking contexts
2022-07-19 12:05:58 -03:00
"initial": "none",
LibWeb: Don't relayout whenever a CSS transform changes Transforms are a paint-level concept for us, so we should be okay to only update the stacking context tree and repaint. This makes a lot of CSS animations use way less CPU.
2023-07-27 04:54:45 -03:00
"affects-layout": false,
LibWeb/CSS: Mark transform property as resolving percentages as lengths
2025-01-09 12:14:06 -03:00
"affects-stacking-context": true,
"percentages-resolve-to": "length"
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 12:20:00 -03:00
},
LibWeb: Parse the CSS transform-box property
2024-01-25 14:02:37 -03:00
"transform-box": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Parse the CSS transform-box property
2024-01-25 14:02:37 -03:00
"inherited": false,
"initial": "view-box",
"affects-layout": false,
"valid-types": [
"transform-box"
]
},
LibWeb: Parse the CSS transform-origin property This is almost a PositionStyleValue, but it's serialized differently, so let's use a StyleValueList with 2 length-percentage values.
2022-03-21 15:11:06 -03:00
"transform-origin": {
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Parse the CSS transform-origin property This is almost a PositionStyleValue, but it's serialized differently, so let's use a StyleValueList with 2 length-percentage values.
2022-03-21 15:11:06 -03:00
"inherited": false,
"initial": "50% 50%",
"max-values": 3,
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Parse the CSS transform-origin property This is almost a PositionStyleValue, but it's serialized differently, so let's use a StyleValueList with 2 length-percentage values.
2022-03-21 15:11:06 -03:00
],
"valid-identifiers": [
"bottom",
"center",
"left",
"right",
"top"
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
],
"percentages-resolve-to": "length"
LibWeb: Parse the CSS transform-origin property This is almost a PositionStyleValue, but it's serialized differently, so let's use a StyleValueList with 2 length-percentage values.
2022-03-21 15:11:06 -03:00
},
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"transition": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"inherited": false,
"initial": "none",
"longhands": [
"transition-property",
"transition-duration",
"transition-timing-function",
LibWeb: Implement the `transition-behavior` CSS property This specifies whether transitions should be started for transitions whose animation behavior is discrete.
2025-04-17 15:11:14 -03:00
"transition-delay",
"transition-behavior"
]
},
"transition-behavior": {
"affects-layout": false,
"animation-type": "none",
"inherited": false,
"initial": "normal",
"valid-types": [
"transition-behavior"
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
]
},
LibWeb: Resolve the `transition-delay` property
2023-05-27 17:05:48 -03:00
"transition-delay": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"animation-type": "none",
"inherited": false,
"initial": "0s",
"valid-types": [
"time"
]
},
"transition-duration": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "none",
LibWeb: Resolve the `transition-delay` property
2023-05-27 17:05:48 -03:00
"inherited": false,
"initial": "0s",
"valid-types": [
LibWeb/CSS: Disallow negative time values for `transition-duration`
2025-03-12 13:30:19 -03:00
"time [0,∞]"
LibWeb: Resolve the `transition-delay` property
2023-05-27 17:05:48 -03:00
]
},
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"transition-property": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"animation-type": "none",
"inherited": false,
"initial": "all",
"valid-types": [
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![all,none]"
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
],
"valid-identifiers": [
"all",
"none"
]
},
"transition-timing-function": {
LibWeb: Don't unconditionally relayout on animation/transition changes If a CSS animation or transition was being used to manipulate a property that itself does not affect layout, we were still doing a full relayout whenever any animation or transition related property was changed. As it turns out, we can just not do that, and we avoid a bunch of unnecessary layout work on many pages. When a layout-affecting property is being animated, the animation/transition update code takes care to invalidate layout as appropriate anyway! This was very noticeable on GitHub, where moving the mouse cursor between "Issues" and "Pull requests" would trigger a full relayout every time. Now that doesn't happen, and it's much more responsive. :^)
2025-03-08 11:50:08 -03:00
"affects-layout": false,
LibWeb: Add transition properties to Properties.json
2024-02-19 23:13:45 -03:00
"animation-type": "none",
"inherited": false,
"initial": "ease",
"valid-types": [
"easing-function"
]
},
LibWeb: Support individual `translate` CSS property
2024-11-22 12:42:20 -03:00
"translate": {
"animation-type": "custom",
"inherited": false,
"initial": "none",
"affects-layout": false,
LibWeb: Improve support for CalculatedStyleValue in `translate` - Omit calcs that are resolved to `0px` from the serialized value - Allow CSV to be the 'Z' component in interpolated value. - Allow calcs with mixed percentages in the first two arguments. To achieve the third item above the concept of a "special" value parsing context has been added - this will also be useful for instance for different arguments of color functions having different contexts. Gains us 23 WPT tests
2025-07-31 08:22:32 -03:00
"affects-stacking-context": true,
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length"
LibWeb: Support individual `translate` CSS property
2024-11-22 12:42:20 -03:00
},
LibWeb/CSS: Add support for `unicode-bidi` property
2024-10-03 16:09:29 -03:00
"unicode-bidi": {
"animation-type": "none",
"inherited": false,
"initial": "normal",
"valid-types": [
"unicode-bidi"
]
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"user-select": {
LibWeb: Mark more CSS properties as not affecting layout - background properties - box-shadow - cursor - SVG fill/stroke properties - image-rendering - outline properties - pointer-events - user-select This should be basically all of them. I skipped `opacity` and `transform` since establishing a stacking context feels like a layout-affecting thing, but I could be very wrong on that!
2022-03-18 12:34:26 -03:00
"affects-layout": false,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "auto",
LibWeb: Implement user-select This implements all values of user-select.
2025-01-07 21:51:29 -03:00
"valid-types": [
"user-select"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"vertical-align": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "baseline",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"vertical-align"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add CSS view-transition-name
2025-02-21 13:56:24 -03:00
"view-transition-name": {
"affects-layout": false,
"affects-stacking-context": true,
"animation-type": "discrete",
"inherited": false,
"initial": "none",
"valid-types": [
LibWeb/CSS: Add custom-ident blacklists to Properties.json These excluded values use a similar notation to the ranges for numeric types: `![foo,bar,baz]` to exclude `foo`, `bar`, and `baz`.
2025-02-24 11:59:03 -03:00
"custom-ident ![auto,none]"
LibWeb: Add CSS view-transition-name
2025-02-21 13:56:24 -03:00
],
"valid-identifiers": [
"none"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"visibility": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "custom",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "visible",
LibWeb: Use generated enum code for property value validation This has the nice benefit of removing a lot of duplicated lists of values from Properties.json. :^)
2022-04-14 07:23:23 -03:00
"valid-types": [
"visibility"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"white-space": {
LibWeb: Convert `white-space` CSS property to shorthand This exposed a few bugs which caused the following tests to behave incorrectly: - `tab-size-text-wrap.html`: This previously relied on a bug where we incorrectly treated `white-space: pre` as allowing text wrapping. The fix here is to implement the text-wrap CSS shorthand property. - `execCommand-preserveWhitespace.html`: We don't correctly serialize shorthand properties. This is covered by an existing FIXME in `CSSStyleProperties::serialized()` - `white-space-shorthand.html`: The last 5 subtests here fail as we don't correctly handle shorthand properties in `CSSStyleProperties::remove_property()`. This is covered by an existing FIXME in said function.
2025-05-21 09:31:24 -03:00
"inherited": false,
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
"initial": "normal",
"valid-types": [
"white-space"
LibWeb: Convert `white-space` CSS property to shorthand This exposed a few bugs which caused the following tests to behave incorrectly: - `tab-size-text-wrap.html`: This previously relied on a bug where we incorrectly treated `white-space: pre` as allowing text wrapping. The fix here is to implement the text-wrap CSS shorthand property. - `execCommand-preserveWhitespace.html`: We don't correctly serialize shorthand properties. This is covered by an existing FIXME in `CSSStyleProperties::serialized()` - `white-space-shorthand.html`: The last 5 subtests here fail as we don't correctly handle shorthand properties in `CSSStyleProperties::remove_property()`. This is covered by an existing FIXME in said function.
2025-05-21 09:31:24 -03:00
],
"longhands": [
"white-space-collapse",
"text-wrap-mode",
"white-space-trim"
LibWeb: Alphabetize property names in Properties.json And add a check to make sure it stays that way!
2023-09-08 16:20:17 -03:00
]
},
LibWeb: Parse and propagate `white-space-collapse` CSS property
2025-05-16 03:32:31 -03:00
"white-space-collapse": {
"animation-type": "discrete",
"inherited": true,
"initial": "collapse",
"valid-types": [
"white-space-collapse"
]
},
LibWeb: Parse and propagate `white-space-trim` CSS property
2025-05-17 11:21:42 -03:00
"white-space-trim": {
"animation-type": "discrete",
"inherited": false,
"initial": "none",
"valid-identifiers": [
"none",
"discard-before",
"discard-after",
"discard-inner"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"width": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "auto",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 14:16:36 -03:00
"fit-content",
LibWeb: Assign limits to CSS properties that cannot be negative I believe this is all of them, but I may have missed some. Several properties technically do not allow negative numbers but the description says to accept these as valid, and then clamp them afterwards to the desired range. As such, we don't reject them during parsing.
2022-03-26 12:00:49 -03:00
"length [0,∞]",
"percentage [0,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
LibWeb: Add fit-content as a valid size value for CSS width
2023-05-26 13:58:06 -03:00
"auto",
LibWeb: Support `min-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 13:24:55 -03:00
"max-content",
"min-content"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
LibWeb: Require layout update for less properties in getComputedStyle() Some properties like `justify-items`, `grid`, or `display` do affect layout, but their used values can be obtained without performing a layout calculation. This change introduces a new helper, `property_needs_layout_for_getcomputedstyle()`, specifically for use by `CSSStyleProperties::property()`. It returns true only for properties such as `width`, `height`, `margin`, `padding`, `top`, and `left`, where an up-to-date layout is required to return the correct used value.
2025-09-10 19:51:00 -03:00
],
"needs-layout-for-getcomputedstyle": true
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Parse the `will-change` property This property provides a hint to the rendering engine about properties that are likely to change in the near future, allowing for early optimizations to be applied.
2025-08-16 04:39:18 -03:00
"will-change": {
"affects-layout": false,
"affects-stacking-context": true,
"animation-type": "none",
"inherited": false,
"initial": "auto",
"valid-types": [
"custom-ident ![all,auto,contents,none,scroll-position,will-change]"
],
"valid-identifiers": [
"auto",
"scroll-position",
"contents"
]
},
LibWeb: Parse the word-break css property
2024-10-25 12:47:05 -03:00
"word-break": {
"animation-type": "discrete",
"initial": "normal",
"inherited": true,
"valid-identifiers": [
"normal",
"keep-all",
"break-all",
"break-word"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"word-spacing": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": true,
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"initial": "normal",
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"length [-∞,∞]",
"percentage [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"normal"
],
LibWeb: Generate function for what properties resolve percentages to This is required by "determine the type of a calculation". https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
2023-06-22 12:22:16 -03:00
"percentages-resolve-to": "length",
LibWeb: Add CSS quirks information to Properties.json Two CSS quirks are specced to only apply to specific properties: - The hashless hex color quirk https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk - The unitless length quirk https://quirks.spec.whatwg.org/#the-unitless-length-quirk These are now represented in `Properties.json` like so: ```json "property-name-here": { "quirks": [ "hashless-hex-color", "unitless-length" ] } ``` Every property that either of those two quirks applies to is included in `Properties.json` and now has their quirks listed. :^)
2021-09-10 17:43:03 -03:00
"quirks": [
"unitless-length"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
},
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"word-wrap": {
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "discrete",
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
"inherited": true,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "normal",
"valid-identifiers": [
"anywhere",
"break-word",
"normal"
]
LibWeb: Add handful of CSS properties and identifiers This is just to make the CSS parser stop whining when it encounters some very common properties and identifiers. More work will be required to actually support these things. :^)
2021-09-13 10:23:36 -03:00
},
LibWeb: Add `writing-mode` CSS property, and its values Introduce the `writing-mode` property, as specified in https://drafts.csswg.org/css-writing-modes/#block-flow
2024-10-27 19:12:54 -03:00
"writing-mode": {
"animation-type": "none",
"inherited": true,
"initial": "horizontal-tb",
LibWeb/CSS: Use writing-mode enum for writing-mode property
2024-11-04 09:12:27 -03:00
"valid-types": [
"writing-mode"
LibWeb: Add `writing-mode` CSS property, and its values Introduce the `writing-mode` property, as specified in https://drafts.csswg.org/css-writing-modes/#block-flow
2024-10-27 19:12:54 -03:00
]
},
LibWeb: Support `x` and `y` attributes on nested SVGs This allows positioning a child SVG relative to its parent SVG. Note: These have been implemented as CSS properties as in SVG 2, these are geometry properties that can be used in CSS (see https://www.w3.org/TR/SVG/geometry.html), but there is not much browser support for this. It is nicer to implement than the ad-hoc SVG attribute parsing though, so I feel it may make sense to port the rest of the attributes specified here (which should fix some issues with viewport relative sizes).
2024-01-28 14:48:59 -03:00
"x": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#X.",
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Support `x` and `y` attributes on nested SVGs This allows positioning a child SVG relative to its parent SVG. Note: These have been implemented as CSS properties as in SVG 2, these are geometry properties that can be used in CSS (see https://www.w3.org/TR/SVG/geometry.html), but there is not much browser support for this. It is nicer to implement than the ad-hoc SVG attribute parsing though, so I feel it may make sense to port the rest of the attributes specified here (which should fix some issues with viewport relative sizes).
2024-01-28 14:48:59 -03:00
"inherited": false,
"initial": "0",
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
"y": {
"__comment": "This is an SVG 2 geometry property, see: https://www.w3.org/TR/SVG/geometry.html#Y.",
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibWeb: Support `x` and `y` attributes on nested SVGs This allows positioning a child SVG relative to its parent SVG. Note: These have been implemented as CSS properties as in SVG 2, these are geometry properties that can be used in CSS (see https://www.w3.org/TR/SVG/geometry.html), but there is not much browser support for this. It is nicer to implement than the ad-hoc SVG attribute parsing though, so I feel it may make sense to port the rest of the attributes specified here (which should fix some issues with viewport relative sizes).
2024-01-28 14:48:59 -03:00
"inherited": false,
"initial": "0",
"valid-types": [
"length [-∞,∞]",
"percentage [-∞,∞]"
],
"percentages-resolve-to": "length",
"quirks": [
"unitless-length"
]
},
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"z-index": {
LibWeb: Only invalidate stacking context tree for opacity/z-index change I came across some websites that change an elements CSS "opacity" in their :hover selectors. That caused us to relayout on hover, which we'd like to avoid. With this patch, we now check if a property only affects the stacking context tree, and if nothing layout-affecting has changed, we only invalidate the stacking context tree, causing it to be rebuilt on next paint or hit test. This makes :hover { opacity: ... } rules much faster. :^)
2022-03-21 06:58:51 -03:00
"affects-layout": false,
"affects-stacking-context": true,
LibWeb: Add a way to test if a CSS::PropertyID is animatable
2023-10-31 23:33:58 -03:00
"animation-type": "by-computed-value",
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
"inherited": false,
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
"initial": "auto",
"valid-types": [
LibWeb: Add missing value ranges to CSS properties ...except those related to `grid`, because I can't figure out how the 17 different properties interact with each other, and what values apply to which ones. 😅 All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying that range does not change anything, but it does make it explicit that we've looked at what the range should be, instead of just not having added it.
2023-06-02 13:11:41 -03:00
"integer [-∞,∞]"
LibWeb: Add valid-value information to Properties.json
2021-09-22 16:10:01 -03:00
],
"valid-identifiers": [
"auto"
]
LibHTML: Start building a simple code generator for CSS properties Code for parsing and stringifying CSS properties is now generated based on LibHTML/CSS/Properties.json At the moment, the file tells us three things: - The name of a property - Its initial value - Whether it's inherited Also, for shorthand properties, it provides a list of all the longhand properties it may expand too. This is not actually used in the engine yet though. This *finally* makes layout tree dumps show the names of CSS properties in effect, instead of "CSS::PropertyID(32)" and such. :^)
2019-11-18 07:12:58 -03:00
}
}
Reference in a new issue Copy permalink