| 04:02 | <Domenic> | jmdyck: I'll defer to annevk on that. He's been the one who loves that particular bit of consistency. |
| 08:36 | <annevk> | jmdyck: I would r+ it. What might be tricky is not violating the wrapping rules at the same time. And there's also some cases where we don't want it. E.g., "Otherwise, if ..., bar" should not be "then bar". |
| 08:37 | <Ms2ger> | Y'all don't make it easy :) |
| 09:33 | <annevk> | denschub: you're now a mod as well. Feel free to ban people using this channel as their personal epic poem blog in the future. |
| 09:34 | <denschub> | I seriously hope this never happens again 🙃 |
| 09:37 | <denschub> | but thanks - I hope to never use the mod permissions. :) at least his @mozilla.org matrix account will remain suspended, though. |
| 12:31 | <jmdyck> | annevk: Hm, not familiar with "r+". |
| 12:32 | <jmdyck> | Re "What might be tricky is not violating the wrapping rules at the same time." Isn't the solution just to re-wrap? |
| 12:33 | <jmdyck> | Re "And there's also some cases where we don't want it. E.g., "Otherwise, if ..., bar" should not be "then bar"." Why don't you want it there? |
| 12:33 | <Ms2ger> | "r+" means "I approve" |
| 12:33 | <jmdyck> | thx |
| 12:33 | <jmdyck> | where does it come from? |
| 12:39 | <annevk> | jmdyck: maybe Bugzilla reviewing culture? Could predate that. I don't actually know. |
| 12:40 | <annevk> | For "Otherwise, if ..." it reads weird (to me). But we omit it for "Otherwise" in general so it's somewhat consistent. |
| 12:40 | <jmdyck> | (Looks like "r+" means "rated up" at reddit) |
| 12:40 | <annevk> | We also started omitting "then" when it precedes substeps. |
| 12:41 | <annevk> | I should fix that case in Infra I guess. |
| 12:45 | <jmdyck> | I'm thinking about it from the viewpoint of parsing algorithms. Having the "then" keyword makes it easier (possible) to detect the end of the condition. But if there are cases like "Otherwise, if" where it's not going to be there, then the parser needs to be able to detect the end of the condition without "then" anyway, so inserting "then"s is less valuable to me. |
| 12:48 | <annevk> | There's not a lot of "Otherwise, if" since we prefer early returns, but there are some. If that's your goal you might get more mileage out of rewriting algorithms that use labels and goto and typically use a much older editorial style. |
| 12:50 | <jmdyck> | labels and goto are easy-ish to parse though. |
| 12:52 | <jmdyck> | grep -c 'Otherwise, if' source says 196, btw |
| 12:53 | <jmdyck> | (and a good fraction of them have "then" too) |
| 12:56 | <annevk> | Hmm, maybe it should be okay? I guess I could be persuaded. It doesn't read too bad in the hidden setter steps for instance. |
| 13:03 | <Ms2ger> | "r+" dates back to when people reviewed on bugzilla by changing the "review" field from "?" to "+" or "-", hence "r(eview)+" and "r(eview)-" |
| 13:19 | <jmdyck> | Looks like ~80% of "Otherwise, if" have "then" or a colon after the condition. |
| 13:27 | <annevk> | jmdyck: fair enough. Let's settle on that then. |
| 13:29 | <annevk> | Which I guess makes the rule that an if statement is terminated by ", then" or ":", which seems pretty good. |
| 13:31 | <jmdyck> | ok, thanks. |
| 13:35 | <jmdyck> | I've also got some questions about (meta-) terminology. E.g., consider a navigable. The spec doesn't say what kind of thing it is. Is it reasonable to consider it a 'struct' in the Infra sense? |
| 13:37 | <jmdyck> | Or do you think of it as a different kind of thing? |
| 13:38 | <Ms2ger> | Do structs have identity? |
| 13:38 | <jmdyck> | Hm, Infra doesn't talk about identity. |
| 13:45 | <jmdyck> | Infra doen't mention the possibility of changing the value of an item, so maybe it thinks of structs as immutable values. On the other hand, it says that the name of an item is immutable, so maybe the fact that it doesn't say the same for the value suggests that the value is mutable. |
| 13:46 | <jmdyck> | How do Infra-users treat structs? |
| 13:48 | <jmdyck> | HTML says 'close watcher manager' is a struct, and its item-values change. |
| 13:57 | <jmdyck> | Similar for 'opener policy enforcement result' |
| 14:31 | <annevk> | jmdyck: yeah, I think most concepts are probably structs. I actually made this explicit for URLs in the URL standard, but overall we haven't really tried to make much progress on that. |
| 14:32 | <annevk> | And yeah, struct values can change. |
| 15:12 | <jmdyck> | next q: When you scroll down and see "A navigable's active document" and "A navigable's active browsing context", what's the general term for those? |
| 15:37 | <Noam Rosenthal> | I've created a WICG for the async CSS discussion we had at WHATNOT, whoever is interested: https://github.com/WICG/proposals/issues/195, with some use cases and ideas. zcorpan FYI |
| 15:39 | <zcorpan> | Noam Rosenthal: Would links in a hidden="until-ready" subtree not block the parser? |
| 15:39 | <Noam Rosenthal> | Correct! But they'll have to be scoped somehow |
| 15:40 | <Noam Rosenthal> | as in all the rules inside that stylesheet would be nested inside that element |
| 15:40 | <zcorpan> | Maybe that could be mentioned in the proposal |
| 15:40 | <Noam Rosenthal> | I mentioned it in the proposal |
| 15:40 | <Noam Rosenthal> | I'll try to make it clearer |
| 15:42 | <annevk> | jmdyck: I guess I generally say member, but it's not defined formally. |
| 15:43 | <annevk> | (Which is why they should probably become a struct or some such, so it all flows from there.) |
| 16:05 | <jmdyck> | I'm not necessarily suggesting a change to the spec. It's just that my code needs to call these things something, so I figured if you already had a (meta-)term for them, it would cause less confusion down the road if I called them that too. |