Re: [csswg-drafts] [css-values] Define value syntax that limits <integer>, <number>, <length>, etc. to ranges (#355)

The CSS Working Group just discussed `Adding min/max constraints`, and agreed to the following:

* `RESOLVED: We will use the bracket range notation`

<details><summary>The full IRC log of that discussion</summary>
&lt;gregwhitworth> Topic: Adding min/max constraints<br>
&lt;gregwhitworth> AmeliaBR: currently we have something like length-percent and in the prose it says negative values are invalid<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757<br>
&lt;gregwhitworth> AmeliaBR: the idea is to get that into the actual syntax grammar<br>
&lt;gregwhitworth> AmeliaBR: especially with various houdini APIs we're providing authors with access to the syntax<br>
&lt;gregwhitworth> AmeliaBR: the issue is to discuss what this syntax looks like<br>
&lt;gregwhitworth> AmeliaBR: my proposal was to look like something like sgml attributes, we're using angle brackets for data types<br>
&lt;gregwhitworth> AmeliaBR: fantasai concern is that that can get verbose<br>
&lt;gregwhitworth> AmeliaBR: if you go down to the second to last issue I have the different options with 4 real world examples<br>
&lt;gregwhitworth> AmeliaBR: Any pros/cons - I've listed mine but would like to hear peopl'es feedback<br>
&lt;gregwhitworth> fantasai: I like my proposal<br>
&lt;gregwhitworth> fantasai: I really don't want to make things too verbose, the more the grammar has to wrap the harder it is to read<br>
&lt;gregwhitworth> fantasai: I<br>
&lt;gregwhitworth> fantasai: I prefer the more human readible version<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757<br>
&lt;gregwhitworth> TabAtkins: shows options on screen<br>
&lt;gregwhitworth> TabAtkins: explains the various proposals in the link above<br>
&lt;gregwhitworth> fantasai: a min in human readible could be 0+<br>
&lt;gregwhitworth> TabAtkins: I'm most a fan of the bracket range syntax<br>
&lt;gregwhitworth> fantasai: if you're going to use multipliers it uses similiar syntax<br>
&lt;gregwhitworth> TabAtkins: this is already in the syntax<br>
&lt;gregwhitworth> TabAtkins: I agree with the idea in general<br>
&lt;gregwhitworth> TabAtkins: I agree with AmeliaBR that with Houdini we need to provide access to this<br>
&lt;gregwhitworth> heycam: A non syntax question<br>
&lt;gregwhitworth> heycam: when we have prose that restricts these values, when we have calc expressions, when we have negative inside the calc - would a change to this syntax make some values invalid earlier?<br>
&lt;gregwhitworth> TabAtkins: This shouldn't change anything this is just moving the prose into the grammar<br>
&lt;gregwhitworth> TabAtkins: calcs are still valid and clamp to the range<br>
&lt;gregwhitworth> heycam: if you have a property number 1-1000<br>
&lt;gregwhitworth> heycam: and you use any calc inside that<br>
&lt;gregwhitworth> TabAtkins: yep, that should work<br>
&lt;gregwhitworth> astearns: does anyone have any objections to bracket notation<br>
&lt;gregwhitworth> astearns: I would prefer to have explicit rather than empty<br>
&lt;gregwhitworth> TabAtkins: what about writing infinity rather than the symbol<br>
&lt;gregwhitworth> fantasai: no<br>
&lt;gregwhitworth> iank_: are we allowing the word infinity?<br>
&lt;gregwhitworth> iank_: I'm biased to the Javascript<br>
&lt;gregwhitworth> TabAtkins: what about both?<br>
&lt;gregwhitworth> iank_: I'm fine with both<br>
&lt;gregwhitworth> AmeliaBR: that sounds the best for me<br>
&lt;gregwhitworth> AmeliaBR: the infinity symbol is nice in a spec but not necessarily for typing in code<br>
&lt;myles_> +1 to what AmeliaBR said<br>
&lt;gregwhitworth> heycam: rather than brackets and commas you can use ..<br>
&lt;gregwhitworth> TabAtkins: some languages include two dots others use three dots<br>
&lt;gregwhitworth> gregwhitworth: I would prefer no on that<br>
&lt;TabAtkins> s/TabAtkins/heycam/<br>
&lt;gregwhitworth> AmeliaBR: as fantasai noted the brackets are known in CSS in the grammar<br>
&lt;gregwhitworth> iank_: also the ... may get confused with the destructioring in JS<br>
&lt;gregwhitworth> TabAtkins: we will go with the bracket version and allow Infinity and the infinity symbol<br>
&lt;gregwhitworth> TabAtkins: I would never propose the inifinty symbol for CSS itself, this is for syntax<br>
&lt;gregwhitworth> florian: Bikeshed feature request, convert infinity word to symbol<br>
&lt;gregwhitworth> fantasai: there is an infinity code and ampersand version<br>
&lt;TabAtkins> &amp;infin;<br>
&lt;gregwhitworth> fantasai: what's the case sensitivity of the inifnity keyword?<br>
&lt;gregwhitworth> TabAtkins: in JS it's Infinity<br>
&lt;gregwhitworth> fantasai: as a string?<br>
&lt;gregwhitworth> TabAtkins: it would be number [1, Infinity]<br>
&lt;AmeliaBR> Proposal: Use the bracket range notation (from the issue), but with infinite ranges (no max/min) represented by either `Infinity` or &amp;infin; (or negative thereof)<br>
&lt;gregwhitworth> AmeliaBR: it's not a string it's a token within the syntax<br>
&lt;gregwhitworth> fantasai: question, is our sytax types case sensitive<br>
&lt;gregwhitworth> TabAtkins: the Houdini syntax cares<br>
&lt;gregwhitworth> fantasai: yeah we're consistent in our specs but I was curious<br>
&lt;gregwhitworth> astearns: any objections to the proposal<br>
&lt;TabAtkins> `syntax: "big | BIGGER"` in registerProperty() is already case-sensitive<br>
&lt;gregwhitworth> RESOLVED: We will use the bracket range notation<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/355#issuecomment-467104675 using your GitHub account

Received on Monday, 25 February 2019 17:37:29 UTC