| 07:25 | <annevk> | Domenic: the one small downside from this .pr-preview.json change is that all PRs will need rebasing I think |
| 07:34 | <annevk> | Domenic: all is ready to go now, I suggest we do it when you and I have some time in case of fallout |
| 11:52 | <Krinkle> | FYI, one trick to make GH rebase the merge commit against latest master for webhooks etc is to close/reopen any PR (so long there is no conflict). |
| 14:11 | <Domenic> | annevk: now is a good time for me |
| 14:12 | <annevk> | Domenic: okay, so first Tab's PR, then whatwg.org, then the .pr-preview.json ones? |
| 14:12 | <Domenic> | Yeah, I think that's it! |
| 14:17 | <annevk> | Domenic: can you do https://github.com/whatwg/streams/pull/1034? |
| 14:18 | <Domenic> | Will do |
| 14:20 | <annevk> | Given https://travis-ci.org/github/whatwg/compat/builds/671502607 I guess it takes some time for api.csswg to update |
| 14:22 | <annevk> | I also see that we're getting a shellcheck warning for not using H1 anymore |
| 14:23 | <Domenic> | Uh oh |
| 14:23 | <annevk> | I'll clean that up now |
| 14:23 | <Domenic> | I'm worried about the bikeshed update. Is it still stuck on Python 2? |
| 14:24 | <annevk> | That's a good question sigh |
| 14:24 | annevk | wonders if TabAtkins is awake |
| 14:27 | <TabAtkins> | Yeah what up |
| 14:28 | <TabAtkins> | The server is on py3 now and receiving webhook notifications, so should be picking up updates now |
| 14:28 | <annevk> | Thanks! It does indeed seem to be working now |
| 14:28 | <annevk> | That is, whatwg/compat just went successfully |
| 14:29 | <annevk> | whatwg/dom looks good too |
| 14:29 | <Domenic> | Phew! |
| 14:30 | <annevk> | Auto-deletion of branches is really nice |
| 17:58 | <MassDebates> | Why can't we add multiple IDs to elements? |
| 20:39 | <shu> | microtasks queues are 1:1 with event loops, right? |
| 20:55 | <Domenic> | shu: correct in specs. I hear Chromium is not quite like that. |
| 20:57 | <shu> | Domenic: i see |
| 20:57 | <shu> | Domenic: the intended state we want is agent:event loop:microtask queue 1:1:1? |
| 20:57 | <Domenic> | shu: yes. That is also the state in specs currently. |
| 20:57 | <shu> | cool, thanks |
| 20:59 | <shu> | Domenic: to make sure i understand, that'd mean since same-origin iframes are never their own agents, they never have their own microtask queues |
| 20:59 | <Domenic> | shu: right. |
| 21:00 | <Domenic> | Otherwise order would be unpredictable between same-origin iframes, which is undesirable, since they can sync script each other already. |
| 21:00 | <shu> | yeah |
| 21:00 | <MassDebates> | We should be able to assign multiple IDs to an element. I don't know why we cannot, aside from "it's been that way". |
| 21:01 | <shu> | there's (as always) weirdness in detached iframes, but... that'll get sorted out whenever detached iframes in general get sorted out, i guess |
| 21:01 | <MassDebates> | I understand that browsers will try to act as a coverall for ID attributes containing whitespace, and will consider it as a part of the ID itself. |
| 21:01 | <MassDebates> | But really, this happens because of the spec saying that there is only ever one value. Why can there only ever be one value? |
| 21:02 | <MassDebates> | an ID can be used for many things, but one of the most common is for CSS selection. It is also used for other things, like various form controls to be hit with a <label> element |
| 21:03 | <Domenic> | MassDebates: use classes, not IDs. |
| 21:04 | <MassDebates> | classes can be space separated lists of names, and I don't see why IDs can't be the same. I understand that classes can be used for various CSS styling, but sometimes an ID is required. |
| 21:09 | <MassDebates> | As is normal in many HTML attributes (like class), a space-separated pair of values inside of an <element attr=""></element> or <element attr="" /> indicates multiple values are to be interpreted. Why do we make a special exception for IDs? Is there a purpose for this, or is this just "How its always been" ? |
| 21:09 | <MassDebates> | Note: this isn't a query asking for alternatives to how something can be done without multiple IDs. This is a query asking why can't we have multiple IDs. |
| 21:45 | <Domenic> | The reason is because there are good alternatives, namely classes. |
| 21:45 | <Domenic> | If you remove the distinction between classes and IDs then there is no point in having both |
| 21:45 | <Domenic> | The unique feature of IDs is that each element only has one |
| 21:46 | <Domenic> | If you remove that then you make them the same as classes and then we have two features that are redundant. |
| 22:08 | <TabAtkins> | I disagree; the unique feature of IDs is that only element has it (in a valid page), thus it's an identifier for that element; the fact that an element can have only one is accidental and not part of the core semantic. |
| 22:09 | <TabAtkins> | *only one element |
| 23:33 | <TabAtkins> | (I don't think it's *worth* messing with IDs at this point, but them being limited to a single value has always been annoying. An element can be "the one X" for multiple roles; the fact that you can't do this has led me to generally just not use IDs at all, and exclusively use classes.) |