WIP: Add ability to parse a Style struct from a CSS string#393
WIP: Add ability to parse a Style struct from a CSS string#393nicoburns wants to merge 7 commits intoDioxusLabs:mainfrom
Style struct from a CSS string#393Conversation
|
CI is complaining about duplicate dependencies. I've submitted a PR upstream to lightningcss which ought to resolve this. |
I agree that we should avoid panicking here. I'd be fine with panicking if it only were limited to the "startup of the application" but we have no such control, and we'd want to be able to have the user parse new CSS whenever they want. I'd prefer that we give some feedback to the user whenever possible about not supported or erroneous styles but I'm not fully certain of how much complexity that would be to implement or how to best deliver this feedback to the user.
Thinking about it further, adding the above checks might be a good form of self-documentation of both the capabilities of Taffy and of current state of flexbox / grid specification. It could be a good thing to pursue regardless of the CSS parsing feature. |
This, though agreed there is the complexity about how to best surface this to API consumers and therefore users. I would say there is an expectation with CSS that it it's fault tolerant and best effort, so I'd expect even terribly invalid CSS to "pass" even if it's effectively non-functional. Ideally there's best effort errors however! |
nicoburns
force-pushed
the
css-parsing
branch
5 times, most recently
from
403d6c5 to
01632cf
Compare
nicoburns
force-pushed
the
css-parsing
branch
from
420581d to
4222016
Compare
|
Closing this as it isn't under active development. It could be revived in future. |
3 participants
Objective
Given how closely Taffy hews to CSS style properties, it seems like an obvious feature allow the
Stylestruct 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
cssfeature from default featuresContext
This code is adapted from this code in Dioxus. It uses Parcel's
lightningcssas a CSS parsing library, which uses the MPL licensedcssparsercrate. 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?