- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Mar 2022 17:47:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `modular/distributed grammar definitions`. <details><summary>The full IRC log of that discussion</summary> <fantasai> topic: modular/distributed grammar definitions<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6744<br> <fantasai> lea: This is about cases where certain tokens are defined as union of other tokens<br> <fantasai> lea: in some cases we want to expand these tokesn in different specs<br> <fantasai> lea: and right now it gets quite difficult to maintain<br> <fantasai> lea: happened multiple times in color-4 and color-5<br> <fantasai> lea: don't imagine we'll keep adding color spaces, but when lab and lch were added, were added in some places and not others<br> <fantasai> lea: some happened also in some of the color colorspaces<br> <fantasai> lea: basically every time we added colorspace, it was added in some places and not others<br> <fantasai> lea: because right now we don't have a DRY way to do it<br> <chris> q+<br> <fantasai> lea: multiple different places need to be updated to ad a colorspace<br> <fantasai> lea: I was wondering if we could define some new grammar operators<br> <fantasai> lea: that extends a token with whatever it already has from other specs plus these tokens<br> <fantasai> lea: they could be in different specs, different modules<br> <fantasai> lea: argument against this is that it adds clarity to have a centralized definition<br> <fantasai> lea: in usability we say if humans keep making the same error with your interface, then it's a problem with your interface<br> <astearns> ack chris<br> <TabAtkins> q+<br> <fantasai> chris: I agree with lea that this problem does occur<br> <fantasai> chris: e.g. we added <number> | <percentage> | none<br> <fantasai> chris: and we have out of sync with prose<br> <fantasai> chris: which assumed percent<br> <fantasai> chris: I don't want to see too much indirection in the actual spec, though<br> <lea> q+ to say indirection is better resolved by machines rather than humans<br> <fantasai> chris: but we already have this indirection because we have bikeshed source and generated HTML<br> <fantasai> chris: so if editors have partial addition like this, if Bikeshed to expand that out and have the complete list in each spec<br> <fantasai> chris: that would let us see everything in one place<br> <fantasai> chris: but then I don't know if that's complicated to implement<br> <astearns> ack dbaron<br> <fantasai> astearns: Bikeshed automatically expanding makes it *more* likely to have mismatch between grammar and prose<br> <fantasai> dbaron: I sympathasize with the problem here<br> <fantasai> dbaron: there are multiple possible results depending on tooling to fix this<br> <fantasai> dbaron: one possible result that I would be very unhappy with is that you end up in situation where readers of the spec can't figure out what a production expands to<br> <fantasai> dbaron: because other specs are extending it from other places, and you can't figure out what the list of things that extend it *is*<br> <fantasai> dbaron: bzbarsky used to call those "come from" statements instead of 'goto' statements, and they're worse<br> <astearns> ack TabAtkins<br> <fantasai> dbaron: If we solve through better tooling, great, but I don't want to end up in a situation where you can't figure out what a production means by looking at a spec<br> <fantasai> TabAtkins: Few points<br> <fantasai> TabAtkins: Earlier, chris had given an example of prose falling out of sync with grammar<br> <fantasai> TabAtkins: Alan pointed out if distrubuted, easier for that to happen<br> <fantasai> TabAtkins: In general, prose falling out of sync has nothing to do with grammar definitions. Has to be manually maintained anyway.<br> <fantasai> TabAtkins: if you have to keep prose in sync, might as well keep grammar in sync<br> <fantasai> TabAtkins: I agree with Lea's usability principle, but we mostly get it right<br> <fantasai> TabAtkins: .... automatically tooled<br> <fantasai> TabAtkins: Chris asked if this was done in Bikeshed, would this be simple or complicated to implement<br> <fantasai> TabAtkins: Answer is, substantially more complicated<br> <lea> +q to say that at least if grammar and prose are inconsistent, it's more obvious there is a problem. If prose and grammar are in sync between them but out of sync with other parts of a spec or other specs, it's easier for an implementer to miss this<br> <fantasai> TabAtkins: you might have noticed that you can see what a production expands to by hovering<br> <fantasai> TabAtkins: Process is not very smart, it goes through the database and links things together with vars<br> <fantasai> TabAtkins: it doesn't read text, it reads the definitions<br> <fantasai> TabAtkins: to make it work smarter, it would be a brand-new project to parse our grammar definitions<br> <fantasai> TabAtkins: I do want to do that at some point to link our defintions, to help catch mistakes<br> <chris> Yeah I saw that give bad results (complete list of color keywords, for example)<br> <fantasai> TabAtkins: but it's not done now, and would be a major project<br> <fantasai> TabAtkins: so definitely not in the near future<br> <fantasai> TabAtkins: If having tooling is necesary, we can't do it now<br> <fantasai> TabAtkins: finally, just generally, I agree with dbaron and bzbarsky's older points, that having this sort of come-from definition where you can look at the canonical definition of something and not know that something else is modifying it<br> <fantasai> TabAtkins: we do do this sometimes, in WebIDL and partial propdefs, but we don't do it very often<br> <fantasai> TabAtkins: So absent tooling that can indicate to readers that there is more to this definition that listed here<br> <fantasai> TabAtkins: I'm opposed to this<br> <astearns> ack lea<br> <Zakim> lea, you wanted to say indirection is better resolved by machines rather than humans and to say that at least if grammar and prose are inconsistent, it's more obvious there is a<br> <Zakim> ... problem. If prose and grammar are in sync between them but out of sync with other parts of a spec or other specs, it's easier for an implementer to miss this<br> <fantasai> lea: Originally was going to respond to Chris, that better solved by tooling than humans for centralization<br> <dbaron> I have proposed (in the TAG) that `partial` should be considered a bad practice for mature specs, although I couldn't quite get consensus on the point.<br> <fantasai> lea: agree that without tooling, could introduce more problems than it solves<br> <fantasai> lea: In this discussion seems to be a confusion of extensibility vs monkey-patching<br> <fantasai> lea: That wouldn't fix prose that's inconsistent to grammar, but implementer can more easily spot that error<br> <fantasai> lea: whereas if the grammar and prose are consistent with each other, but not with another spec or another part of the spec<br> <fantasai> lea: that's more likely to create incompatibility<br> <astearns> q?<br> <astearns> ack fantasai<br> <dholbert> fantasai: I wanted to comment on the automated tooling aspect<br> <dholbert> fantasai: we have lots of specs in different states of being finished<br> <dholbert> fantasai: if we had a single spec and this was it, and we split it across multiple modules and automated tooling copied things from here to there, that'd be fine<br> <dholbert> fantasai: if we have things in rec that automatically expanded into people's editor's drafts [...]<br> <lea> q+ different specs at different maturity levels is actually part of the motivation for this :/ When you maintain centralized definitions it's hard to judge *what* to include in said centralized definition<br> <dholbert> fantasai: I think having an automated approach would modify things that we don't expect to modify<br> <lea> q?<br> <lea> q+<br> <dholbert> fantasai: e.g. if someone fixes a typo, it might cause changes to other specs<br> <astearns> ack lea<br> <dholbert> astearns: the automation would have to deal with that concern<br> <fantasai> lea: The fact that there are different specs at different maturity levels extending the token is actually a motivation for it<br> <fantasai> lea: do I inclued this early-stage draft, or not?<br> <fantasai> lea: The grammars that tooling generate, could have different levels/states<br> <dholbert> fantasai: let me put it this way; I'm fine with us having centralized definitions and needing to update them manually<br> <dholbert> fantasai: if we want to have a new or-equals operator that extends an existing token, that's also fine since it's relatively straightforward<br> <dholbert> fantasai: if you combine specs, you get the union of those tokens<br> <lea> +1 to fantasai<br> <dholbert> fantasai: I'm not fine with having an automated system that *decides for you* whether this thing gets extended or not<br> <dholbert> fantasai: If it's automated, it happens magically and you might not notice<br> <dholbert> fantasai: don't' want the tooling to change the prose of the spec such that something gets magically expanded. that'll happen in unexpected ways<br> <fantasai> astearns: Anything more to discuss on this?<br> <tantek> +1 fantasai, keep things more manual until there’s experience with it, rather than "automate all the things"<br> <fantasai> astearns: I see 2 ways of going forward with this<br> <fantasai> astearns: that don't necessarily conflict<br> <TabAtkins> (Note that the "random ideas are automatically merged into the definition" happens today with the production title="" attribute, but it's also a less-obvious and less-official source of data.)<br> <fantasai> astearns: 1. Come up with a distributed scheme that we can agree is the right way to develop specs with these issues<br> <fantasai> astearns: 2. Work on tooling that isn't going to create more problems than it solves<br> <lea> That sounds like a huge undertaking for what was essentially a proposal for |=<br> <fantasai> astearns: Tab, you mentioned tooling from you would take a long time.<br> <fantasai> astearns: would you be OK with someone taking a branch of bikeshed source and fiddling around it?<br> <fantasai> TabAtkins: yeah, that's fine<br> <fantasai> chris: It also doesn't have to be bikeshed at all. We have a database of properties and values, potentially a separate tool could run over that and identify problems<br> <lea> q+<br> <fantasai> astearns: That tool could be something spec authors could use to figure out what they need to put in their source<br> <fantasai> astearns: instead of an automated expansion<br> <astearns> ack lea<br> <fantasai> lea: This makes it sound like a huge undertaking of coming up with an extension something<br> <fantasai> lea: whereas the main thing that's needed here is |= or &= or osmething<br> <fantasai> lea: I've seen this thing being done manually , but can't remember which specs<br> <fantasai> lea: but I've basically seen prose that's done this, so would be good to have a formalized way to do it<br> <fantasai> TabAtkins: we do do it sometimes, but I think it's good that it's clumsy and awkward, because encourages people to update the centralized definition<br> <fantasai> lea: if awkward, fix it<br> <fantasai> TabAtkins: sometimes it makes sense to make the bad thing hard, so that people avoid doing it<br> <fantasai> lea: I think calling it a bad thing is a value judgement<br> <fantasai> lea: it's a spectrum<br> <fantasai> lea: sometimes centralized defiintions are a worse thing<br> <fantasai> astearns: I think we've spent enough time for today<br> <fantasai> astearns: we can go back to the issue and come up with specific proposals on grammar productions and what they would solves and possible tools for spec authors to make things easier<br> <lea> (+1 that we've spent too long on this today)<br> <astearns> ack fantasai<br> <fantasai> astearns: let's come up with things<br> <dholbert> fantasai: because we need a canonical order for things, the *only* operator that we can do in this manner is the "or" operator<br> <lea> fantasai: && doesn't impose a specific order either, does it?<br> <fantasai> astearns: ok, next issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6744#issuecomment-1063193625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 March 2022 17:47:42 UTC