Open nicoburns opened 4 months ago
This seems like an interesting idea and pretty useful. This is the sort of change that should be developed upstream in Gecko and then gradually make its way to downstream stylo.
This doesn't stick to the letter of the spec: it will parse unsupported properties. But it should be functionally equivalent.
This is exposed via @supports
, CSS.parse
, getComputedStyle
, etc. It would break websites, Gecko won't accept this at all, and we can't have it in Servo either if we expect it to be a serious browser some day. It would need to be a different feature.
A few points:
It has occurred to me that Stylo already has a mechanism for runtime enabling/disabling style properties. Specifically the flags in the style_config
crate. It seems to me that this could be a good fit for enabling things like CSS Grid properties in (the Servo build of) Stylo while still disabling them in Servo itself until such time as they are implemented.
This could also be a really good way of landing changes in Stylo while the corresponding Servo changes are still in progress (meaning that e.g. a PR to implement CSS Grid or the gap
property could run against Stylo main
rather than having to maintain a long-running PR against Stylo.
While it's true that Servo will eventually need accurate support for @supports
etc in order to be considered a serious browser, there are also a whole bunch of style properties that Servo will need to actually support in order to be considered a serious browser. We could perhaps be a little loose with enabling parsing of some of those ahead of time where we plan to implement them relatively soon.
This would reduce the maintenance overhead of implementing these features and would allow other projects depending on Stylo (e.g. stylo-dioxus) to take advantage of support for those styles in the meantime. It is also already the case that we have poor or partial support for a bunch of enabled properties (e.g. column-gap
is enabled for multi-column support but not implemented in Flexbox. flex-direction
is enabled but not actually implemented).
My disposition is basically that "accurately advertising poor css support" isn't a state worth putting effort into maintaining. We should optimise for "actually implementing good css support" ASAP. And not having to maintain our own copies of style parsing when there is a production grade implementation available would help with that.
@nicoburns Are you interested in these properties in the context of Servo? Perhaps the solution here is to create a third configuration option that exposes all CSS features.
Motivation
Enable OSS (non-gecko, non-servo) users of
stylo
to use all style properties thatstylo
supports.Background
The set of style properties that Stylo supports are currently conditionally compiled using a python script to generate them. There are two sets of styles: Gecko and Servo. The Servo style set only enables styles properties (and values of style properties) that Servo supports. For example, the Servo version of the
justify-content
property does not support thestart
andend
values (although it does supportflex-start
andflex-end
which are similar but ultimately different).It is presumably set up like this partly for efficiency (don't compile or run code that isn't being used) and partly because the CSS specification specifies that style property values that are not understood should not be parsed (to ensure future compatibility if/when support is added).
Proposal
JustifiedContent
enum that Gecko is using)Notes