-
Notifications
You must be signed in to change notification settings - Fork 639
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
[css-values] Add <number-optional-number> type #385
Comments
That's silly. You want a +# multiplier, not a new type. We can add one, sure. |
Or just change the grammar to Sebastian |
Expressing comma-wsp is the problematic part, since there's no equivalent that allows either comma or whitespace. The clearest equivalent currently seems to be I think this might be what @fantasai is suggesting, but maybe we could make a new token for a comma-wsp list? E.g. '&' This would improve the |
I don't know if we want to canonicalize the SVG "commas wherever you want" behavior in the grammar; making it slightly more annoying to type might help keep this from spreading to new things, so we can standardize on normal CSS behavior over time. (For If we were to standardize "comma or not whatever lol", I'd prefer hitting it directly. We already have |
That is already what it indicates, unless there's some new comma-specific grammar magic that overrides it. |
SVG 2 has already gotten rid of
As you've all noted, there are lots of ways to express this syntax in standard CSS notation. I'm pretty sure For arbitrary-length lists of items separated by comma or whitespace, that's another matter. SVG has them all over the place, and the syntax we're currently using for SVG 2 is If you then allow numerical qualifications on the |
Besides the discussion about the type or multiplier, shouldn't SVG rather start discouraging mixed separator syntaxes? E.g. it doesn't make sense to allow As I understand it, in CSS commas are normally used to separate list items, where an item is a coherent chunk of data. According to that the only valid syntax for Sebastian |
@SebastianZ I do agree with the general move to a more logical & consistent approach to punctuation, even if I myself prefer the x,y syntax for coordinate pairs (with multiple coordinate pairs separated by spaces), as do many other people who come from a mathematical/scientific background. When we CSS-ify |
CSSWG resolved today to formalize this "list with optional commas" pattern with the grammar form It would be great if SVG could standardize on this grammar form as well. |
OK, so you'd prefer if we standardize to have What about the cases where there are a fixed number of values, like the SVG 1.1 Aside: I just realized this is going to be a pain in the behind for spec-ing layered strokes, because when it comes to stroke-dasharray, we actually would want a comma-separated list of space-separated lists, but we're not going to be able to do that for backwards compatibility reasons. |
Probably either way would work for SVG2; CSS tends to use [ + ]# because for many properties, commas are a higher-level separator. I agree the viewBox example above is pretty clear. |
Filter Effects Module Level 1 relies on the
<number-optional-number>
type definition from SVG 1.1. For the sake of consistency, I would introduce this type in CSS Values spec and make Filter Effects spec reference it instead of SVG 1.1.The text was updated successfully, but these errors were encountered: