07:14
<annevk>
Jake Archibald: did an editorial pass. Will let someone else verify the logic.
07:17
<Jake Archibald>
@annevk:matrix.org: are you happy with it landing without someone from WebKit verifying the logic?
07:34
<annevk>
Yeah, that seems okay. If we hit issues when implementing we can always raise those at that point, but that is hopefully unlikely given the amount of vetting it will have had by then. (Assuming people still actually read the specification.)
08:25
<annevk>
foolip: seems like a long shot, but do you perhaps remember how the muted attribute of media elements is supposed to work? The description is essentially prose, which isn't great. It kinda suggests that script mutations should not work, but we don't really distinguish those from the parser setting attributes in the specification.
08:27
<foolip>
The content attribute is reflected as defaultMuted and only affects the real muted IDL attribute at one point.
08:27
<Jake Archibald>
(independent folks like @lwarlow:igalia.com are looking at it) (edit: this was in relation to popover=hint but I hadn't received the other messages at the time)
08:30
<annevk>
foolip: I think specifically the problem is this sentence: "When a media element is created, if the element has a muted content attribute specified, then the muted IDL attribute should be set to true"
08:33
<annevk>
foolip: for instance, when cloning we'd first create the element and then copy the attributes, but the tests assume that .muted returns true for that case.
08:34
<annevk>
foolip: and the parser also does not create an element with all of the attributes at once.
08:35
<annevk>
I guess I'll file a specification issue.
08:35
<foolip>
OK, so the issue is exactly when the content attribute is supposed to be read.
08:36
<annevk>
Ah, https://github.com/whatwg/html/issues/5013
08:37
<foolip>
Looks like Blink only respects the content attribute if set by the parser
08:40
<foolip>
annevk: is there establish spec language for special-casing the parser but not cloning?
08:41
<annevk>
foolip: https://wpt.fyi/results/html/semantics/embedded-content/media-elements/user-interface/muted.html suggests otherwise.
08:42
<annevk>
And no, none of those subtleties are supposed to be available. But engines had them for optimizations maybe and it got never cleaned up and then features started to depend on it.
08:43
<foolip>
OK, a proper code search also finds that cloning is handled
08:44
<foolip>
Those are the two places the attribute is read in addition to the defaultMuted generated bindings.
08:47
<annevk>
Thanks for checking! I've agenda+'d it with some added context.
08:49
<foolip>
I linked the code in a comment. Does WebKit not do the cloning bits?
10:11
<Jake Archibald>
annevk: https://github.com/whatwg/infra/pull/706 https://github.com/whatwg/infra/pull/707 - slice & reverse for infra
10:18
<zcorpan>
Jake Archibald: we should have "flip and reverse" also :)
10:21
<Jake Archibald>
annevk I see you're correcting "If [condition], then:" to "If [condition]:" - the former used to be the convention right?
14:51
<Luke Warlow>
Do we have the joint taskforce meeting today? I can see it on the calendar but can't find an agenda
14:59
<Noam Rosenthal>
https://github.com/whatwg/html/issues/12291
15:13
<annevk>
Jake Archibald: yeah, we decided that when followed by : you don't need it and it's nicer when it's shorter
15:14
<annevk>
foolip: WebKit doesn't have the creation-time semantic
15:14
<annevk>
(Will try to review slice & reverse tomorrow. Others are welcome to that as well of course.)
16:04
<Usama Nadeem>
annevk: do you have any idea about the timeline? I mean, how long does it usually take for someone to review my PR?
https://github.com/whatwg/fs/pull/182
And who is the person responsible for reviewing the PR?
16:50
<zcorpan>
Luke Warlow: re "appearance:none still exposes some OS stuff I think", is there anything that's not "top layer"?
16:50
<zcorpan>
I guess file
16:53
<Luke Warlow>
The range input's thumb is an odd one that I think might still be OS dependent
16:54
<Luke Warlow>
But yeah also stuff like Safari file input which has image preview. Perhaps we should define an appearance:none for file input anyway though? Seeing as we're defining appearance to apply to it for base mode
16:55
<zcorpan>
Luke Warlow: we probably can't change what appearance: none does for file for web compat
16:56
<zcorpan>
At least I expect making the button "appearance: none" fugly will result in user complaints for real sites
16:56
<Luke Warlow>
We could define it to render the button in appearance:auto and the label and not allow for stuff like the file image preview. Which is probably far less breaking?
16:56
<Luke Warlow>
But probably not worth it
16:56
<zcorpan>
Maybe
17:00
<annevk>
I've given up on making "none" good. I've not given up on making it well-defined and interoperable.
17:02
<smaug>
cwilso: was that your last WHATNOT? If so, thank you 🙂