WIP: Add ability to parse a Style
struct from a CSS string
#393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
Given how closely Taffy hews to CSS style properties, it seems like an obvious feature allow the
Style
struct to be parsed directly from a CSS string. Combined with #155, this would allow for a two-way serialization/deserialization to and from a much more human-friendly format than the existing serde feature. It could also be useful for exposing Taffy over FFI without the boilerplate of exposing a style builder for each language. This could be particularly natural in dynamic languages like JavaScript where stringly typed APIs may be idiomatic.Tasks
css
feature from default featuresContext
This code is adapted from this code in Dioxus. It uses Parcel's
lightningcss
as a CSS parsing library, which uses the MPL licensedcssparser
crate. This seems fine to me as it doesn't require us our users to relicense our code.Feedback wanted
What are people's thought on how best to handle errors? The current code sometimes panics when it encounters unknown/invalid styles, and sometime ignores them without feedback. There are 3 options we could pick:
Personally, I'm inclined to think we ought to offer both options 2 and 3 (as separate functions) but never panic. For further context, there are technically two error cases here:
Not sure if we need to make a distinction here, but it might be useful for diagnostic purposes?