Skip to content

No way to get TokenSerializationType directly #266

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
makotokato opened this issue Nov 18, 2019 · 0 comments · Fixed by #369
Closed

No way to get TokenSerializationType directly #266

makotokato opened this issue Nov 18, 2019 · 0 comments · Fixed by #369

Comments

@makotokato
Copy link

From https://bugzilla.mozilla.org/show_bug.cgi?id=1503656

Actually there is no way to get TokenSerializationType directly from Token type. If it is TokenSerializationTypeVariants::Nothing, it has nothing() function to get it.

Even parsing CSS that is hardcoded value such as 0px, to get type, we have to create Token object like the following.

let token =
    Token::Dimension {
        has_sign: false, value: 0.0, int_value: Some(0), unit: CowRcStr::from("px")
    };
let token_type = token.serialization_type();

I am happy if cssparser has a function to get TokenSerializationType without creating object like TokenSerializationType::nothing().

zrhoffman added a commit to zrhoffman/rust-cssparser that referenced this issue Nov 9, 2023
Fixes servo#266

Making TokenSerializationType public is useful to describe the start and
end of a CSS string that is already known to be valid in cases when the
TokenSerializationTypes of the start and end of the CSS string is
needed, but Tokens are not.

This helps with creating a custom_properties::VariableValue from the CSS
string of a computed value for CSS Properties and Values, see Mozilla
bug 1858305 [1].

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1858305
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant