- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Apr 2018 23:19:53 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types`, and agreed to the following resolutions: * `RESOLVED: Extend value definition syntax to handle value ranges and possibly other syntactic restrictions, syntax TBD` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/355<br> <dael> AmeliaBR: A couple years ago there was discussion and it got lost in bikeshedding syntax. I wanted to at least get a clear opinion from the group if the idea is good.<br> <dael> AmeliaBR: I'd like to see if that when we have properties with constraints enforced by the parser, most common is no negative values, there is a way to explain that in the grammar rather then only prose.<br> <dael> AmeliaBR: It would be convenient for people impl parsers if the grammar covered everything esp now that Houdini is exposing the value syntax. Might be time to be more strict about value definition language.<br> <florian> +1, makes total sense to me<br> <dael> AmeliaBR: I was hoping to get a resolution that it would be a good idea to extend value definition lang to cover all constraints from the parser.<br> <dbaron> "all constraints that can be enforced by the parser" sounds like it might be a little much<br> <dael> AmeliaBR: I had a second question on narrowing down approaches.<br> <astearns> +1 from me as well<br> <dael> fantasai: I don't think we'll be able to put in all parsing restrictions because I remember there are restrictions not in the grammar that aren't just about limiting range of numbers. We won't get to 100% but it should be possible to put range restrictions. If this is author exposed syntax that might be important.<br> <TabAtkins> positive-int, and gez-int and gez-number seem very fine, along with gez-length/etc<br> <astearns> define gez?<br> <dael> florian: I think we could take somewhere between...in V&U we define non-negative ranges and houdini relies on that. If it's not the case already in indiviual specs we have something that looks like int but with constraints we deinfe anew type. Doesn't have to be shared in V&U. That's not actionable, that's how to write. The actionable part I'm all for it.<br> <TabAtkins> greater-equal-zero<br> <TabAtkins> p-integer, nn-integer<br> <dael> astearns: I'm all for having this defined in the grammar and not lost in the prose. I don't care what names we use particularly.<br> <dael> fantasai: I'd like the syntax to be reasonably readable and not so long that the grammar is hard to read. non-negative-integrer is really long.<br> <dael> fantasai: Every time we throw in one of these it wraps and it's hard to read. It seems like a great idea but I haven't seen a proposal for yes we should do it this way. If this is exposed in Houdini we should put thought in understandable and usable like we do for other property values we define.<br> <fantasai> s/one/one or four/<br> <dael> astearns: I think consensus is this is a good direction to take. Second question?<br> <fantasai> s/wraps/gets long and maybe wraps/<br> <dael> AmeliaBR: My initial idea was new name types but in the discussion there was a suggestion of introducing it more as a modifying constraint within the type. Syntax that looked readable was make it look like a HTML attribute.<br> <dael> AmeliaBR: It's very nice and readable. Other aspect is it's open ended. Could be a benefit, could be a negative. Do people like the idea of adding a general way of adding constraints or is it something we want to keep to named types?<br> <dael> TabAtkins: I hadn't seen that comment, I'll have to think about that.<br> <florian> I am not sure, but I am intrigued<br> <dael_> astearns: prop: we will add more terms tot he grammar to describe value ranges and such, but approach is in the air.<br> <dael_> astearns: Objections?<br> <fantasai> proposed resolution: Extend value definition syntax to handle value ranges and possibly other syntactic restrictions, syntax TBD<br> <dael_> RESOLVED: Extend value definition syntax to handle value ranges and possibly other syntactic restrictions, syntax TBD<br> <dbaron> I need to head out now, but I'll see you next week...<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-378774960 using your GitHub account
Received on Wednesday, 4 April 2018 23:20:19 UTC