| 02:44 | <domfarolino> | annevk: This would be less of an issue if *only* cross-origin iframes were deferred, right? (Not sure if it would be a non-issue though, and probably doesn't exactly solve the real issue) |
| 05:02 | <annevk> | domfarolino: no, sandboxing also matters here |
| 07:55 | <JakeA> | Is there a valid way in IDL to inherit/union enums? |
| 08:39 | <annevk> | JakeA: don't think so and I don't think we should add it necessarily, the whole partial thing is already messy (reposting now the netsplit is over) |
| 08:39 | <JakeA> | Fair enough. Yeah I missed that message in the split |
| 14:52 | <bkardell> | Domenic: it seems that we have some comments on the original issue from mozilla and chrome folks that generally unweirding the IDL for math elements would be good, which is really what we're looking for - it seems there is some discussion about where that should happen - move into element, or in the existing (new) HTMLOrSVGElement mixin or a new one... because of that I'm unsure where to take this... |
| 14:52 | <bkardell> | https://github.com/mathml-refresh/mathml/issues/83#issuecomment-509713648 for recent comments |
| 14:54 | <bkardell> | I think the thing is that there's definitely a change to HTML idl, we're just unsure where - we'd suggested just chaning the name of one interface, but I guess there are options -- how to pursue? advice? thoughts? |
| 14:56 | <Domenic> | bkardell: I feel like I've stated this before, but I'll try to be even more clear: I'm not interested in changing the name of HTMLOrSVGElement for a long time. I want to see some serious stability and usage of it in MathML before we make an editorial change in that regard. You should proceed with the current name, and gather interest in implementing *observable, testable changes*, not editorial renamings. |
| 14:57 | <Domenic> | For example, it would be very premature to rename it if, as it sounds like from that thread, people are interested in moving things to Element instead. |
| 14:58 | <Domenic> | As for how to make such observable, testable changes happen, I think the usual process: posting a PR, posting tests, getting implementer agreement, seeing some intent-to-ships... |
| 15:02 | <annevk> | Domenic: "for a long time"? |
| 15:02 | <bkardell> | posting tests seems pretty straightforward as observably it shouldn't matter how you achieve this, but posting a PR of what exactly? |
| 15:03 | <annevk> | bkardell: presumably there's some spec change on the Math side at least to make objects implement this interface? |
| 15:03 | <bkardell> | yes |
| 15:03 | <annevk> | bkardell: or if you move things to Element you'd need changes to both HTML and Math |
| 15:03 | <annevk> | bkardell: sounds like a PR to me |
| 15:04 | <annevk> | bkardell: but in general, assuming https://whatwg.org/working-mode#changes is followed changes can be discussed |
| 15:05 | <annevk> | bkardell: I mean, assuming that's followed I'd expect changes to be incorporated |
| 19:07 | <innovati> | Is there anything for <link> or <style> tags like what the media="" attribute does for the stylesheet contained inside for CSS feature queries, which in CSS use @supports and in JS can be tested with CSS.supports()? Does something like a supports="" attribute exist? |
| 20:36 | <smaug____> | I guess it was left unclear who could perhaps ask for space for the web components meeting @tpac. hober? |
| 21:25 | <Krinkle> | innovati: not that I'm aware of. It's also tricky to do, I imagine, because it wouldn't be backward-compatible. |
| 21:25 | <Krinkle> | the CSS syntax makes so that older agents ignore the whole of @supports { .. } |
| 21:25 | <Krinkle> | but HTML wouldn't behave that way |
| 21:26 | <TabAtkins> | innovati: There's not. It wouldn't make a ton of sense to add such, as @supports is rarely a single test for the whole stylesheet; those rules belong in the sheet itself. |
| 21:30 | <innovati> | people were asking, I think with the hope of not having to load the stylesheet in a browser they they know won't need it. Would the best approach for this to use JS and CSS.supports to conditionally link in only the needed stylesheets instead? |
| 21:33 | <hober> | smaug____: oh, umm, maybe? i'll ask. |
| 21:35 | <smaug____> | hober: rniwa pinged here, and then we realized webcomponents isn't anymore part of Web Apps WG (or Web Plat, can't recall its current name) |
| 21:50 | <TabAtkins> | innovati: Hm. I'm still on the side of "you won't normally wrap a whole stylesheet in a single @supports test", and if you're breaking up your stylesheets small enough that you *would* wrap the whole thing in one, you're probably paying way more in latency than you would be in transfer. |
| 21:50 | <TabAtkins> | innovati: Anyway, <style>@import("foo") all and supports(...);</style> should work. |
| 21:53 | <innovati> | TIL you can use media query list with @import, I've never seen anything like this before. What browsers support this kind of syntax? |
| 22:02 | <TabAtkins> | None, I think. ^_^ |
| 22:02 | <TabAtkins> | Well, you can use MQs in all of them, I think. |
| 22:02 | <TabAtkins> | but not support queries. |