| 00:46 | <sideshowbarker> | * Linkedin says Alex Mogilevsky is back at Google now. Would be wonderful if he’s on the Chrome team, but it looks more likely that he might be working on AI stuff. And unsurprising, if so. “Renowned engineer joins AI team at company X” → more of a “Dog bites man” story these days. |
| 00:46 | <sideshowbarker> | * Linkedin says Alex Mogilevsky is back at Google now. Would be wonderful if he’s on the Chrome team, but it looks more likely that he might be working on AI stuff. And unsurprising, if so. These days: “Renowned engineer joins AI team at company X” → more of a “Dog bites man” story |
| 00:47 | <sideshowbarker> | * Linkedin says Alex Mogilevsky is back at Google now. Would be wonderful if he’s on the Chrome team, but it looks more likely that he might be working on AI stuff. And unsurprising, if so. These days: “Renowned engineer joins AI team at company X” → more of a “Dog bites man” story |
| 00:47 | <sideshowbarker> | * Linkedin says Alex Mogilevsky is back at Google now. Would be wonderful if he’s on the Chrome team, but it looks more likely that he might be working on AI stuff. And unsurprising, if so. These days: “Renowned engineer joins AI team at company X” → more of a “Dog bites man” news story |
| 00:47 | <sideshowbarker> | * Linkedin says Alex Mogilevsky is back at Google now. Would be wonderful if he’s on the Chrome team, but it looks more likely that he might be working on AI stuff. And unsurprising, if so. These days: “Renowned engineer joins AI team at company X” → more of a “Dog bites man!” news story |
| 06:11 | <annevk> | Luke Warlow: it might be nice to allow for cleaner diffs, but also remember that implementation IDL is allowed to diverge. What's important is that the observable behavior of the APIs matches. Whether that happens through IDL or something else is completely up to the implementation. Now having written that I think it might be better to not allow it as specifications don't really need cleaner diffs or extended attributes all that much. |
| 11:06 | <Luke Warlow> | I guess my only counter to that is if you're building certain WebIDL tooling (e.g. IDE plugins) you can't rely on the specs grammar to do processing, I know browsers expand the extended attribute list syntax but I've yet to find any the permissive grammar didn't account for. Where as with this trailing comma you do have to make a change not in the spec to support it. Idm too much either way just thought I'd raise query it. I agree it's not going to be useful for actual specification text. |
| 14:17 | <annevk> | Luke Warlow: I guess I wouldn't mind allowing it, but I'd want specifications to use some sort of canonical style |
| 14:17 | <annevk> | Luke Warlow: unrelated, where's type=image in https://drafts.csswg.org/css-forms-1/ ? |
| 14:18 | <Luke Warlow> | https://github.com/w3c/csswg-drafts/issues/12910 - in an issue. |
| 14:19 | <Luke Warlow> | Need someone to propose what styles it should get. I don't know the uses of it well enough to meaningfully propose anything (like I said on the issue I'd be just as happy with display: none; 😅) |
| 14:21 | <annevk> | Yeah, maybe it should just say a replaced element like it is today and only get fairly minimal styling. |
| 14:25 | <Luke Warlow> | Like it gets cursor: pointer which surprised me. Maybe we just need to give it that + some of the other very minimal button styles (maybe we can still ensure a minimum size?) We probably could standardise it's shadow dom to contain an img element that gets it's src and alt set from the input? |
| 14:25 | <Luke Warlow> | Probably the sort of control that will benefit from implementation experience. |
| 14:27 | <Luke Warlow> | If we allow styling the failed load state of an img element I suspect we probably want to do the same for the image input? But maybe not if its barely used in modern sites. |
| 15:39 | <cwilso> | Hey, gang - I'm out on vacation still. Is anyone available to chair tomorrow's meeting? |
| 18:18 | <annevk> | Luke Warlow: I think we'd just want implementations to treat it like <img> maybe? return createRenderer<RenderImage> suggests to me that's what WebKit does anyway and in this case I don't really see a point in letting people override the renderer. And yeah, some similar API surface could be nice, but doesn't have to be v1. Just need something minimal. |
| 18:19 | <Noam Rosenthal> | I think I'll be able to do that |
| 22:01 | <sideshowbarker> | https://github.com/w3c/pointerevents/issues/636 ← Pointer Events working group looking for feedback |