| 11:56 | <JakeA> | annevk: ah, sorry, irccloud had logged me out and I hadn't noticed |
| 11:58 | <annevk> | JakeA: wb 🙂 |
| 11:58 | <annevk> | JakeA: so for that WPT PR I'm mainly looking for ideas |
| 11:59 | <annevk> | JakeA: one thing that came to mind is that I could create a Python file per scenario that imports the wav file somehow for the majority of the logic, if we don't want to put everything in the wav file, but none of it seems particularly elegant |
| 12:00 | <annevk> | JakeA: I'm also having trouble determining what state the media element should end up in once things fail or succeed, but perhaps observing the network traffic is sufficient for now... |
| 12:00 | <JakeA> | annevk: I've usually used query params to handle a lot of that stuff, but I don't know how that'd fit in this case |
| 12:01 | <annevk> | JakeA: so the problem with query params is that I need the URL to remain mostly static (unless I explicitly want to change it) as we (plan to) compare the URL in the spec |
| 12:01 | <annevk> | JakeA: one thought I had was to base64 a JSON object that encodes scenarios and put that in a param though |
| 12:02 | <annevk> | JakeA: that would work as it'd be the same as the token, just a static unchanging thing |
| 12:03 | <annevk> | But maybe I should just write some tests with a switch/case in the wav file and try to abstract things later... |
| 12:32 | <rigid> | hi |
| 12:33 | <rigid> | When linking to a HTML5 <video> with https://video.mp4#t=10,15 it works fine in recent popular browsers, but only when the video is not already playing. |
| 12:33 | <rigid> | Does anyone know if there's a standard emerging/planned to do this with videos already playing to do seek jumps? Something like href="#my-video-element-id?t=10,15" would be awesome. I couldn't find anything (just solutions that require javascript). |
| 12:36 | <annevk> | rigid: not aware of anything, you could propose it to https://wicg.io/ |
| 12:37 | <rigid> | ehrm, i'm no expert. i'll probably do it wrong :) |
| 12:37 | <rigid> | annevk: but i'll try. thank you. |
| 12:38 | <annevk> | rigid: https://whatwg.org/faq#adding-new-features has tips |
| 12:38 | <rigid> | ah, was just about to search for that. awesome! |
| 12:40 | <JakeA> | rigid: The tricky part is figuring out how this would work without JavaScript. You'd need some kind of input/link that targets a particular media element. |
| 12:43 | <rigid> | JakeA: naively i'd think it would be quite easy to implement. with javascript, one just sets the "currentTime" attribute to "HH:MM:SS.MMM" of the <video> element. If a browser could replicate this by parsing href="#video_element?t=HH:MM:SS.MMM", it's done. |
| 12:44 | <rigid> | i could imagine that in practice it'd be _much_ more complex :) |
| 12:45 | <rigid> | and probably needs more parsing. Like als calling the "play()" method of the video element (or not) if the the video is paused. Not everyone would want to seek and play. Some might just want to seek and keep the video paused. Etc. |
| 12:46 | <JakeA> | yeah, maybe targeting the media by id is enough |
| 12:46 | <rigid> | in this case, something like href="#video_element?t=00:00:05.500&play=true" (or false) would be needed |
| 12:47 | <rigid> | also that would deviate from the current "t=X,Y" standard. Lots of issues. But i'll try to RFC anyway |
| 12:48 | <JakeA> | can't have something that works around current autoplay restrictions |
| 12:48 | <rigid> | JakeA: i think it'd be enough since targeting elements by id is already done for normal #section links |
| 12:50 | <rigid> | hm, javascript seems to work around against autoplay restrictions aswell? like: "var video = $('#myvideo').get(0); video.play()" |
| 12:50 | <rigid> | this in <a onclick=...> plays on click |
| 12:50 | <rigid> | ah, but it doesn't work around on external links |
| 12:51 | <rigid> | i think I get what you're saying |
| 12:51 | <JakeA> | rigid: `video.play()` only works if it was called after a user interaction |
| 12:51 | <JakeA> | (although in some cases muted videos can play) |
| 12:51 | <annevk> | JakeA: how did you test whether the user agent stopped doing requests for the media element? |
| 12:53 | <JakeA> | annevk: I think I assumed requests wouldn't happen after an error event on the media element |
| 12:53 | <rigid> | hm, clicking a link would also be a user interaction. I suppose links from external sites would be the issue. like <a href="//notmysite.com/#video?play=true">; would work around that restriction. |
| 12:54 | <JakeA> | rigid: right, or indeed links from a native app etc etc |
| 12:56 | <annevk> | JakeA: so I can't always get error to fire in Chrome, but it does stop doing requests... |
| 18:04 | <domfarolino> | annevk: Just for a sanity check, do you agree with https://github.com/w3c/webappsec-referrer-policy/pull/148#issuecomment-765590123 ? |
| 18:48 | <rigid> | just reading the FAQ for proposals annevk pasted. It mentions https://github.com/whatwg/html/issues ... where's the difference to https://wicg.io ? |
| 19:31 | <annevk> | domfarolino: that goes for all policies |
| 19:32 | <annevk> | rigid: the former is for stuff that’s a bit further along, we should prolly update the FAQ |
| 19:34 | <rigid> | oh, i just started writing the github issue :) |
| 19:34 | <domfarolino> | Ok just checking |
| 19:35 | <domfarolino> | Except srcdocs shouldn’t inherit the CSP of the initiator of a backwards history traversal I guess? But that’s not really considered a navigation I think. |
| 19:38 | <domfarolino> | Or I guess more generally policies shouldn’t be inherited from history traversal since they’re aren’t navigations... |
| 19:38 | <domfarolino> | Sorry, trying to page this all in my head 😅 |
| 19:43 | <annevk> | domfarolino: good question how that would work without bfcache, might have to be stored in history, hmm |
| 19:43 | <annevk> | rigid: that’s fine as a starting point, you’ll get redirected if needed |
| 19:49 | <domfarolino> | annevk: Yeah so without bfcache my understanding is the document would have to be reloaded, and you're saying reloading it might not be enough to resurrect the same policy container that the original document would've had (that inherits policies from its container doc)? That is, we might need to store the container in history or something? |
| 20:15 | <annevk> | domfarolino: yeah maybe, not sure where else it would go if the entry was about:blank or some such |