| 09:19 | <Ms2ger> | ecobos, don't reply to all@ |
| 09:22 | <ecobos> | Ms2ger: yeah... Should've known it :). Still don't regret it this time |
| 09:23 | <Ms2ger> | khuey's ghost will haunt you |
| 09:24 | <ecobos> | Hah |
| 09:33 | <annevk> | Ms2ger: turns out khuey is pleased: https://twitter.com/khuey_/status/954138271692410880 |
| 09:34 | <Ms2ger> | Hell froze over, huh |
| 10:04 | <annevk> | foolip: I think we need to go back to the "flow content excluding main" construct |
| 10:05 | <annevk> | foolip: the current setup doesn't work |
| 10:05 | <annevk> | foolip: since now <body><article><div><main> ends up being conforming |
| 10:05 | <annevk> | foolip: as <main> can be a child of <div> |
| 10:18 | <foolip> | annevk: hmm, right, the difference between allowed children and disallowed descendants in those contructs... |
| 10:19 | <annevk> | foolip: yup, kinda glad we're taking our time so I managed to catch this |
| 10:20 | <annevk> | foolip: so what I want from you is either saying "an abstraction is fine" or saying I need to list it explicitly everywhere for each element with a flow content content model |
| 10:20 | <foolip> | annevk: I would still be quite content with just disallowing <main> in a few specific cases, but something that has the effect of just allowing it in body and and body div+ WFM |
| 10:20 | <annevk> | foolip: I want to allow it with only html/body/div/form as ancestors, basically |
| 10:21 | <annevk> | foolip: my "flow content excluding main" construct works for that, if consistently applied |
| 10:21 | <annevk> | foolip: expanding that construct works too |
| 10:21 | <annevk> | foolip: I don't see what else can work |
| 10:22 | <foolip> | annevk: I can't either, but give me a sec to see how flow content is defined again |
| 10:23 | <annevk> | foolip: one alternative might be that we define it in prose in the <main> element section, but that kinda goes against precedent I think |
| 10:23 | <foolip> | annevk: I was just thinking that, could we just say something about the ancestor elements? |
| 10:24 | <foolip> | you're right that it's backwards compared to the way that content models flow only "downwards" though |
| 10:24 | <annevk> | foolip: maybe it's okay, I found some precedent |
| 10:24 | <annevk> | foolip: "An area element with a parent node must have a map element ancestor." |
| 10:24 | <annevk> | foolip: this would be that, except some kind of negation |
| 10:25 | <annevk> | foolip: "A main element must only have html, body, div, and form element ancestors." |
| 10:25 | <foolip> | annevk: yeah, that'd work for me. |
| 10:25 | <foolip> | what about custom elements? |
| 10:26 | <foolip> | how do they work with validity generally? |
| 10:26 | <foolip> | MikeSmith: ^ |
| 10:27 | <annevk> | foolip: currently they can only be used where phrasing content is expected |
| 10:27 | <annevk> | foolip: that kinda seems like a bug though, maybe? |
| 10:27 | <foolip> | annevk: yeah, seems like they should be transparent, rather? |
| 10:28 | <annevk> | Hmm, I'm probably misunderstanding how that works, since one of the categories is "flow content" and the content model is "transparent" |
| 10:29 | <foolip> | annevk: ah, so the definition of flow content actually includes autonomous custom elements |
| 10:30 | <foolip> | and they're transparent, so it all seems fine |
| 10:31 | <MikeSmith> | foolip: For custom elements, as far as the checker behavior goes, the custom elements and their subtrees are ignored |
| 10:31 | <MikeSmith> | skipped |
| 10:32 | <annevk> | MikeSmith: wow, that goes a little bit against the spec |
| 10:32 | <annevk> | MikeSmith: if you use <a> inside <whatever-yo> you'd still want it checked I think |
| 10:33 | <MikeSmith> | I guess I overrated things. the actual behavior conforms to whatever the spec says |
| 10:33 | <MikeSmith> | Ah no |
| 10:34 | <MikeSmith> | as far as the case you mention there |
| 10:34 | <MikeSmith> | I'm not sure that <a> will get checked |
| 10:35 | <MikeSmith> | not sure from memory |
| 10:35 | <MikeSmith> | would need to look back at the code |
| 10:35 | <MikeSmith> | well, or just test it |
| 10:36 | <MikeSmith> | maybe I made the behavior be that it's transparent |
| 12:03 | <annevk> | Transparent would be correct per the content model of the spec |
| 12:15 | <MikeSmith> | annevk: OK yeah I misspoke before. Just tested and found that it does check the <a> |
| 12:15 | <MikeSmith> | so I think we’re all good there |
| 12:19 | <foolip> | tobie: in https://whatpr.org/html/3354/dom.html#kinds-of-content an image doesn't work because of the URL. a problem for all pr preview stuff? |
| 12:20 | <tobie> | yes |
| 12:30 | <foolip> | annevk: before https://github.com/whatwg/html/pull/3354 is merged, do you think we should write down somewhere why it's changing? |
| 12:45 | <annevk> | foolip: at least the commit body should |
| 12:46 | <foolip> | annevk: right. so what would we say has changed here, except that we spent some time on it? |
| 12:46 | <tobie> | foolip: the way I would go about that is to have all assets on the gh-branch if that's how you're setup, and just change the src attribute to point to the new asset. |
| 12:46 | <foolip> | for me, the main thing is that at least Chromium treats <header> and <footer> like generic containers in some contexts, but <main> always maps to main |
| 12:47 | <foolip> | and the (unverified) claim that this is true elsewhere too |
| 12:48 | <annevk> | foolip: what has changed is that we finally made an effort to close the issue |
| 12:49 | <annevk> | foolip: and as I said elsewhere I regret not doing so much sooner |
| 12:49 | <foolip> | annevk: I think that's true, yeah |
| 12:49 | <foolip> | annevk: but at least the last time around it was not salient to me that <header>, <footer> and <main> had different mappings in implementations, or maybe I ignored it |
| 12:49 | <foolip> | (or it wasn't true then) |
| 12:50 | <annevk> | foolip: if we do a blog post it should contain an apology of sorts since plenty of folks have let us know it was important to them |
| 12:50 | <foolip> | FWIW, it seems like these mappings should be pretty easy to test with wpt using the computedRole API here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/WToTEn4lveY/0DDozNNQqE8J |
| 12:55 | <foolip> | annevk: maybe, I think I'd want to nitpick the wording there, but a blog post would be nice |
| 12:55 | <foolip> | on to the bloody data: URL thing |
| 18:47 | <annevk> | Getting close though on data: URLs |