5 commits

Author	SHA1	Message	Date
Callum Law	f49cf75d44	LibWeb: Don't pass unnecessary PropertyComputationDependencies struct ... Since we now have access to the `AbstractElement` through the `ComputationContext` we can just set the flag that this element relies on tree counting functions directly, no need to pass this struct around.	2025-10-22 00:01:30 +02:00
Callum Law	5b9a36b172	LibWeb: Pass AbstractElement in ComputationContext ... Passing the `AbstractElement` rather than the `TreeCountingFunctionResolutionContext` allows us to only compute the resolution context when necessary (i.e. when we actually need to resolve a tree counting function)	2025-10-22 00:01:30 +02:00
Callum Law	2404f95e03	LibWeb: Invalidate style for tree counting functions when required ... We mark any element that relies on tree counting functions as needing a style update when a sibling is inserted/removed.	2025-10-20 16:12:08 +01:00
Callum Law	e9036c7c75	LibWeb: Support tree counting functions within calc()	2025-10-20 16:12:08 +01:00
Callum Law	831e471444	LibWeb: Support top-level tree counting functions ... Adds support for `sibling-index()` and `sibling-count()` when parsing `<number>` and `<integer>`. This is achieved by a new `TreeCountingFunctionStyleValue` class which is converted within `absolutized` to `NumberStyleValue` and `IntegerStyleValue` respectively There are still a few kinks to work out in order to support these everywhere, namely: - There are some `StyleValue`s which aren't absolutized (i.e. those which are stored within another `StyleValue` without an `absolutize()` method. - We don't have a way to represent this new `StyleValue` within `{Number,Integer}OrCalculated`. This would be fixed if we were to instead just use the `StyleValue` classes until style computation at which time they would be absolutized into their respective primitives (double, i64, etc) bypassing the need for *OrCalculated entirely.	2025-10-20 16:12:08 +01:00