| 04:09 | <jmdyck> | In the HTML spec (and maybe others, I don't know), there are steps roughly likePerform Foo on the Bar of X, given Ywhere it isn't grammatically obvious whether given Y is supplying an argument to Foo or to Bar. (Foo(Bar(X), Y) vs Foo(Bar(X, Y)))In practice, you can presumably disambiguate by looking at the definition of Foo and Bar to see which one takes the given Y, though I imagine the presence of optional parameters would complicate that.Anyway, I'm just wondering if there's an editorial stance on these. (Like, they're fine, or they're to be avoided.) |
| 07:13 | <annevk> | jmdyck: I think Perform Foo given X’s Bar and Y would be an improvement |
| 07:14 | <annevk> | X of Y is kinda Hixian and new prose almost always goes for Y’s X |
| 11:54 | <jmdyck> | sorry, my example was poorly chosen. I meant that Bar is an algorithm being invoked on X (and possibly Y), not a possession of X. Change of in the example to for or from or on or using etc. |
| 11:55 | <jmdyck> | (but your response is also interesting, that answers a different question I would have asked eventually) |
| 12:03 | <Ms2ger> | Let Z be Bar of X. Perform Foo on Z, given Y. |
| 12:53 | <jmdyck> | Yup, that (or Let Z be Bar of X, given Y. Perform Foo on Z.) would be a way to disambiguate. |
| 13:03 | <annevk> | jmdyck: I guess the more general rule is that if (reasonable) people find something ambiguous, we should fix it. |
| 13:31 | <jmdyck> | Okay. Not a criterion I can apply programmatically, then. |
| 13:33 | <annevk> | jmdyck: perhaps open an issue with concrete cases and then we can figure out the better wording and then perhaps you can abstract from that? |
| 13:33 | <jmdyck> | Okay, thanks. |
| 17:15 | <julienw> | hey folks, I use an form-associated input element inside a shadow root, therefore calling its form's reset() method doesn't reset the fact the user has interacted with it (so user-invalid applies). Any idea about how to reset this input element? here is a playground with this issue |