| 08:42 | <annevk> | TabAtkins: would it be easier if I don't update DOM while you convert it? I can probably wait another week or so |
| 10:17 | <annevk> | Does anyone happen to know for which HTML elements notification of end tag popping during parsing is important? |
| 10:17 | <annevk> | <script> is obviously one of them, are there any others? |
| 10:19 | <zcorpan> | </object> |
| 10:20 | <zcorpan> | </style> |
| 10:20 | <zcorpan> | </video> </audio> |
| 10:23 | <zcorpan> | i think that's it, but impls might have more. i think blink did something for </input> |
| 10:24 | <annevk> | there's no such thing in the spec |
| 10:24 | <zcorpan> | for </input> no |
| 10:25 | <annevk> | it's weird that the contract for the others isn't quite as explicit as it could be either |
| 10:27 | <zcorpan> | media elements tried to avoid it, but <track> screwed it over |
| 10:27 | <Ms2ger> | How about picture? |
| 10:27 | <Ms2ger> | link? |
| 10:27 | <zcorpan> | nope |
| 10:28 | <zcorpan> | not per spec at least |
| 10:30 | <zcorpan> | (picture doesn't do anything at all, it's the img that looks at its parent and previous siblings when it is inserted) |
| 12:13 | <gsnedders> | SimonSapin: should I be using tinycss2 or is there something better? |
| 12:24 | <SimonSapin> | gsnedders: I haven’t made a tinycss3, if that’s your question :) |
| 12:26 | <gsnedders> | SimonSapin: "is this what I should be using to parse CSS in Python?" |
| 12:26 | <SimonSapin> | yes |
| 12:28 | <SimonSapin> | gsnedders: let me know if you find something that could be improved or added |
| 12:36 | <gsnedders> | SimonSapin: Will do. Though I scarcely need more than parse_color. Some nice way to serialise stuff would be nice, though. |
| 12:36 | <gsnedders> | But rather out of scope, I suspect. |
| 12:37 | <SimonSapin> | gsnedders: https://pythonhosted.org/tinycss2/#tinycss2.ast.Node.serialize |
| 12:38 | <gsnedders> | SimonSapin: I was more thinking about serialising color3.RGBA |
| 12:38 | <SimonSapin> | though the RGBA type is not a Node |
| 12:38 | <gsnedders> | Exactly. |
| 12:38 | <gsnedders> | Also one can bikeshed format endlessly :) |
| 12:39 | <gsnedders> | A dict of (str) keyword -> RGBA would be nice, too. |
| 12:39 | <SimonSapin> | I don’t think it needs to be more complicated than a string interpolation one-liner |
| 12:40 | <gsnedders> | Oh, it's not that complex. The only fun thing is multiplying it so you have either a 0–255 int or percentage |
| 12:40 | <zcorpan> | serializing the alpha isn't obvious (see www-style) |
| 12:40 | <SimonSapin> | that dict is tinycss2.color3._COLOR_KEYWORDS |
| 12:41 | <SimonSapin> | https://github.com/SimonSapin/tinycss2/blob/a64d0a64057fa3b73146b8bc7759a882d53550ed/tinycss2/color3.py#L180 |
| 12:41 | <gsnedders> | Ah, cheers. I hadn't bothered digging into that yet. |
| 12:41 | <gsnedders> | zcorpan: is there a tl;dr of that? |
| 12:42 | <SimonSapin> | it’s undocumented, but unlikely to change |
| 12:42 | <gsnedders> | This is a script I'm likely not gonna touch after today, so not really an issue. |
| 12:55 | <zcorpan> | gsnedders: how do you roundtrip rgba(1,1,1,0.5) when storing alpha in 8 bits? |
| 12:56 | <gsnedders> | zcorpan: Ah, but tinycss2 stores it as a double. Then you just go for the shortest unique representation. |
| 12:57 | <zcorpan> | gsnedders: ah ok |
| 15:22 | <ondras> | when using registerElement with the "extends" feature, one has to use is= to instantiate? <x-stuff> cannot be used then? |
| 15:23 | <caitp> | that doesn't sound right |
| 15:24 | <ondras> | I vaguely recall asking about this some time ago, receiving response approximately compatible with what I wrote |
| 15:24 | <ondras> | but I am not sure |
| 15:24 | <ondras> | (and my poor english might be also the cause) |
| 15:25 | <caitp> | is= was supposed to be, if I understand, a way to work around the dumb aspects of the parser, and a way to ensure hard-to-polyfill features work well (although I'm not positive about that last one) |
| 15:46 | <annevk> | Domenic: did you get any further writing up how ARIA bindings would work? |
| 15:46 | <annevk> | Domenic: I'm wondering if we can reuse that to explain title="", contenteditable="", etc. |
| 16:11 | <Domenic> | annevk: no further than https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md. I can turn the strawmen there into something more concrete maybe, if there is implementer interest. |
| 16:11 | <Domenic> | Why does title="" need explaining? |
| 16:11 | <annevk> | Domenic: e.g. you might want to overwrite the default behavior |
| 16:12 | <Domenic> | Mehhh just use a different attribute then |
| 16:12 | <Domenic> | If I were to say "explain title" I would mean "add `window.showOSTooltip("string", { x, y })" |
| 16:13 | <Domenic> | then I could explain title as some sort of global mutation observer + mouseover hooks |
| 16:13 | <Domenic> | + I think it impacts accessible name calculation |
| 16:14 | <Domenic> | but that is already explained at the bottom of the above link |
| 16:14 | <annevk> | Domenic: see https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/thread.html#msg324 |
| 16:14 | <annevk> | Domenic: if you want to allow <my-element someattr> we need to account for the fact that some day "someattr" might be a global attribute |
| 16:14 | <Domenic> | Sure. How is that related? |
| 16:15 | <annevk> | Domenic: it's the same scenario, except "title" is already a global attribute |
| 16:15 | <Domenic> | You can already use <div someattr>; how are we accounting for that? |
| 16:16 | <annevk> | We tell people to please use data-* or they might have a problem going forward |
| 16:16 | <Domenic> | I still don't understand the problem. Maybe jump to a strawman solution and tell me what new capabilities I will have when it is implemented? |
| 16:18 | <annevk> | The problem is clashes and I don't really have a good solution |
| 16:19 | <Domenic> | Well, what new capabilities will I have if we solve the clashes solution? |
| 16:21 | <annevk> | You can use any attribute name (including builtins) without future repercussions |
| 16:22 | <Domenic> | I guess I pretty much agree with Hixie's arguments in that thread that this isn't a big deal. But if you wanted to solve it maybe the custom element definition should blacklist or whitelist attributes. |
| 16:22 | <annevk> | Domenic: see. e.g. https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0440.html from that thread |
| 16:23 | <Domenic> | E.g. registerElement(..., { ..., attrs: ['title', 'somefutureattr'] }) => 'title' and 'somefutureattr' won't get special treatment from the browser |
| 16:23 | <annevk> | Yeah maybe |
| 16:23 | <Domenic> | https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0440.html doesn't make much sense... you can use setters .osc2 for the attribute data-osc2 |
| 16:50 | <annevk> | true |
| 17:54 | <annevk> | So annoying that GitHub doesn't search through commit messages |
| 17:54 | <annevk> | Does anyone know what resulted in IDL adding back the [[HasInstance]] override? |
| 17:54 | <Ms2ger> | Maybe bz |
| 17:55 | <hasather_> | annevk: search locally? |
| 18:15 | <TabAtkins> | annevk: That would be a little easier, yeah, but not strictly necessary. But I plan to finish up this weekend, so if you're okay with waiting a little bit, that'd be cool. |
| 18:16 | <annevk> | TabAtkins: sure thing |
| 22:41 | <Domenic> | "Don't expose GC behavior" strikes again! https://github.com/yutakahirano/fetch-with-streams/issues/15#issuecomment-72119046 |