- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Jan 2019 00:02:33 +0000
- To: public-css-archive@w3.org
@fantasai Okay, so that's two additional syntaxes, for three alternatives so far. So people can really compare, here's what they look like for the font properties I used in my [comment above](https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757), along with my summary of pros and cons: ## Attribute notation - font-size: `<absolute-size> | <relative-size> | <length-percentage min=0>` - font-weight: `[normal | bold | <number min=1 max=1000>] | bolder | lighter` - font-stretch: `normal | <percentage min=0%> | <font-stretch-keyword>` - font-style: `normal | italic | oblique <angle min=-90deg max=90deg>?` Pros - familiar syntax - easy to read - extensible to other types of constraints Cons - verbose ## Bracket range notation - font-size: `<absolute-size> | <relative-size> | <length-percentage [0,]>` - font-weight: `[normal | bold | <number [1,1000]>] | bolder | lighter` - font-stretch: `normal | <percentage [0%,]> | <font-stretch-keyword>` - font-style: `normal | italic | oblique <angle [-90deg, 90deg]>?` Pros - compact - uses a recognized syntax for people with a mathematical background - similar to the [syntax used for describing a number of repeated tokens](https://drafts.csswg.org/css-values/#component-multipliers) Cons - similar to the syntax used for describing a number of repeated tokens - the single-sided bounds syntax (`[0,]` for zero and up) may be confusing for those not familiar with mathematical range notation ## Human-readable range notation - font-size: `<absolute-size> | <relative-size> | <length-percentage 0+>` - font-weight: `[normal | bold | <number 1 to 1000>] | bolder | lighter` - font-stretch: `normal | <percentage 0%+> | <font-stretch-keyword>` - font-style: `normal | italic | oblique <angle -90deg to 90deg>?` Pro - compact - written the way you would read it Cons - The `+` notation can get lost among % signs or units. - No syntax for a maximum bound without a minimum bound (but I don't think we have any use case for this). > (Maybe replace "to" with a proper n-dash. ;) Nope. The whole idea is to make a grammar that is easier to auto-parse! Subtle typographic niceties not allowed! Especially because I want to eventually use the chosen syntax within author-supplied values to Houdini APIs. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458352263 using your GitHub account
Received on Tuesday, 29 January 2019 00:02:35 UTC