| 03:07 | <Domenic> | Seems like it's being changed into something not like the original, so we'll need to keep copying the domintro styles around |
| 07:41 | <annevk> | Domenic: thanks for the SAB review. I'll try to understand that type nuance a bit better. Are you are the existing typedefs work though? It seems they would not allow for resizable or shared buffers in a number of places, for instance. |
| 07:43 | <Domenic> | annevk: yeah the existing typedefs might not work well. It's more that using "an X object" or "an X" where X is an IDL typedef is known-good phrasing. |
| 07:45 | <annevk> | canadahonk: you prodding me about other schemes made me realize what I might have been missing in my WebKit patch; maybe I'll finally manage to get all the tests to pass now 🤞 |
| 07:46 | <Domenic> | I was honestly a bit surprised that we were rigorous about using "string types" and "numeric types" and so on, to only refer to the types and not to instances. But since we are, I figured we should probably stick to it |
| 07:47 | <annevk> | Yeah, maybe we shouldn't export them then though. I guess that's another thing to look at, if there are any callers. |
| 07:48 | <Domenic> | Hmm yeah, good point |
| 08:39 | <sideshowbarker> | zcorpan: FYI It seems my recent parser change regressed the handling of ampersands in URLs https://github.com/validator/validator/issues/1595. I guess I shouldn’t be surprised. So I’ll need to revert the change — and then I suppose I rightly should go back to the parser code and try to re-figure-out how to get the parser error-reporting behavior conforming for all cases. Which is not a lot of fun without proper test cases with the right coverage, and a working test harness for checking the error-reporting behavior |
| 08:42 | <zcorpan> | sideshowbarker: ouch. I wonder if we should revisit the decision to allow "&" at all tho |
| 08:42 | <zcorpan> | The current rules are basically impossible to explain |
| 08:44 | <sideshowbarker> | Yeah, I don’t even remember now at a high level how the logic in the spec change distinguished between the usage in, e.g., a URL vs. the usage that we wanted to continue to disallow |
| 08:45 | <sideshowbarker> | As far as revisiting the decision, I do still think the use case for allowing it in URLs is valid and we should still allow that |
| 08:46 | <zcorpan> | IIRC Ian Hickson allowed ampersands based on feedback within google that there was no harm from using unescaped & in e.g. urls. But it only "works" for urls in attributes, so it's still brittle. Also the same argument would allow font or omitting </div>s |
| 08:47 | <sideshowbarker> | yeah I guess the possible long-term costs of some of these decisions were hard to foresee at the time |
| 08:54 | <sideshowbarker> | And incidentally other characteristic of this part of the parser code that makes this really “fun” is that the fact that the state machine in the parser code doesn’t really map very clearly to the state machine in the spec algorithm. Of course the resulting behavior of the parser state machine is intended to be workalike conforming to the spec algorithm — but, in practice, working with that parser code, needing to mentally re-construct the code-to-spec mapping there every time I need to touch that code is not something I look forward to. |
| 08:55 | <sideshowbarker> | Anyway, I really wish we had someone else with time and interest in working on the parser maintenance |
| 08:55 | <zcorpan> | sideshowbarker: just rewrite the spec |
| 08:55 | <sideshowbarker> | snort |
| 08:56 | <sideshowbarker> | That would definitely help to make the spec algorithm even less maintainable too |
| 08:56 | <sideshowbarker> | Maybe that’s what we want in the end — we want everybody to be afraid to touch that part of the spec ever again |
| 08:57 | <zcorpan> | hehe |
| 08:58 | <zcorpan> | But do you want to file a spec issue about disallowing &? |
| 09:03 | <Noam Rosenthal> | smaug: hi! trying the understand the concern around https://github.com/whatwg/html/issues/9315. I don't see how it interferes with BFCache snapshots but perhaps I'm missing something |
| 09:04 | <smaug> | concern is to postpone when the first paint could happen |
| 09:04 | <smaug> | If handling the new event takes lots of time, what would UA paint instead? |
| 09:05 | <Noam Rosenthal> | smaug: if there are no view transitions, it can still paint the snapshot |
| 09:05 | <smaug> | what if there are transitions? |
| 09:05 | <Noam Rosenthal> | view-transitions are same origin, have a timeout, and in this case it would be the feature :) |
| 09:06 | <Noam Rosenthal> | if there is a same-origin view transition, it would show the old document until you're done with that event etc |
| 09:06 | <smaug> | view-transitions are same origin right now, in Google's proposal, but will they always be? |
| 09:07 | <Noam Rosenthal> | smaug: might make them same-site at some point, in which case we'll need to make sure the opt-ins hold water |
| 09:08 | <Noam Rosenthal> | but in any case view-transitions reveal a lot about the old document to the new one |
| 09:08 | <Noam Rosenthal> | which we'll have to deal with if we ever go to same-site |
| 09:09 | <Noam Rosenthal> | (cross-site is a non-goal) |
| 09:12 | <Noam Rosenthal> | smaug: we're careful not to make choices that would bind us to staying constrained to same-origin. For example we don't expose anything to the old document. But I don't see how this event is one of those features - by the time you get it both documents have opted in |
| 09:13 | <smaug> | If the behavior would be very different when ViewTransitions are around, should the event be dispatched only in that case |
| 09:13 | <smaug> | otherwise it would be rather error prone |
| 09:13 | <Noam Rosenthal> | that was the original behavior, but in the case of newly-initialized document it's useful also without view transitions |
| 09:13 | <smaug> | without VT one would have a paint (painting using the cache) before first rAF when coming out of bfcache |
| 09:13 | <Noam Rosenthal> | I mean the original proposal |
| 09:14 | <Noam Rosenthal> | "without VT one would have a paint (painting using the cache) before first rAF when coming out of bfcache" - is that specified anywhere? |
| 09:15 | <smaug> | no, but I wouldn't want to let web page to postpone painting when coming out of bfcache |
| 09:15 | <smaug> | that would make bfcache feel slower |
| 09:16 | <Noam Rosenthal> | yea but it's not a web-exposed feature. it's like showing a splash screen of the previous contents in a way |
| 09:17 | <Noam Rosenthal> | like in a page that has a clock you'll show some previous time |
| 09:17 | <smaug> | yes, and you want to remove that |
| 09:17 | <smaug> | for VT at least |
| 09:18 | <Noam Rosenthal> | right, but that's unrelated to the event |
| 09:18 | <smaug> | I'm confused |
| 09:19 | <smaug> | You want a new event which fires before first paint after activation. How is the event not related to the first paint? |
| 09:19 | <Noam Rosenthal> | think of it as:
|
| 09:20 | <Noam Rosenthal> | the main "novelty" of this event is how it behaves on initial load. As far as reactivating is concerned, it's the same as pageshow |
| 09:20 | <smaug> | I guess pageshow is confusing here, since this is also about page load, and pageshow may fire way after the initial paint |
| 09:20 | <Noam Rosenthal> | I don't see showing the stale snapshot as a "paint" |
| 09:20 | <Noam Rosenthal> | it's not a paint in web-standards term |
| 09:21 | <smaug> | it is from the user's point of view. |
| 09:21 | <Noam Rosenthal> | hmm we can call it the first rendering update |
| 09:22 | <Noam Rosenthal> | the first non-stale paint |
| 09:24 | <smaug> | So for VT case how is reveal event different to having a rAF callback? |
| 09:25 | <Noam Rosenthal> | it's not too different from putting a rAF callback in the head + pageshow, but it fires before "update the rendering" phase |
| 09:25 | <smaug> | and why is that important? |
| 09:25 | <Noam Rosenthal> | it's more equivalent to putting onload on all your render-blocking scripts and styles + pageshow |
| 09:25 | <smaug> | er, why pageshow |
| 09:26 | <Noam Rosenthal> | this is "your page's rendering is about to be displayed for the first time" |
| 09:26 | <smaug> | yes |
| 09:26 | <smaug> | so you add a rAF callback |
| 09:28 | <smaug> | Why you need a new event to fire just before first "update the rendering", and not use the existing mechanism to get callbacks called during "update the rendering"? |
| 09:29 | <Noam Rosenthal> | but then you need to add that rAF callback also on page show |
| 09:29 | <Noam Rosenthal> | it's easy to miss that. you build your webpage in a way that works on first load, and then it breaks on BFCache restore |
| 09:29 | <smaug> | And how is adding a raf callback different to adding an event listener? |
| 09:30 | <Noam Rosenthal> | it's about doing it once vs doing it twice |
| 09:31 | <Noam Rosenthal> | in the VT case, it allows us to put a VT object reference in the event object. so this would be the only time where you can, for example, skip an incoming VT or listen to when it's finished. |
| 09:33 | <Noam Rosenthal> | I mean, we could have a VT-specific event for this and use the first rAF for other cases, but we thought it might be a useful event regardless of VT. Yoav Weiss you said something about having another use case for this? |
| 09:33 | <smaug> | VT object reference in the event, that is not something proposed in the issue |
| 09:34 | <Noam Rosenthal> | Yea when I proposed it I was thinking of having a document.pendingTransition instead. I will update the proposal |
| 09:37 | <Noam Rosenthal> | smaug: the cross-document view transition spec is in the making, and we noticed that this lifecycle event is somewhat missing (you have to register it twice, as first rAF+pageshow) so we wanted to discuss it as a general benefit rather than just in the context of VT. Trying to avoid having an event-per-CSS-feature, but if that's what we end up with it's also OK |
| 09:38 | <smaug> | Well, better to understand the context here, and I wasn't aware that something might be added to the event itself |
| 09:39 | <smaug> | Since that might make the event more useful |
| 09:39 | <smaug> | right now it feels more like minor helper event for things which can be done easily without making the platform even more complicated |
| 09:41 | <Noam Rosenthal> | smaug: good point |
| 09:44 | <Noam Rosenthal> | ... updated the OP |
| 11:18 | <canadahonk> | is a *full* name required for the participant agreement? I don't feel exactly comfortable having my full name public atm (but is somewhat understandable) |
| 11:27 | <annevk> | canadahonk: unfortunately, yes: https://github.com/whatwg/sg/issues/93#issuecomment-1120799691 |
| 11:28 | <annevk> | canadahonk: now having said that, if you happen to work for an entity that is already part of the WHATWG that doesn't apply |
| 11:28 | <annevk> | canadahonk: as your contributions would be on behalf of that entity, but I'm not sure if that applies to you or not |
| 11:32 | <Dominic Farolino> | WebIDL's "upon fulfillment" queues a microtask for you, right? (It seems to call into TC39 land which call the host enqueue promise job algo). Only reason I'm not sure is because I see some specs explicitly queue a microtask themselves: https://w3c.github.io/ServiceWorker/#ref-for-upon-fulfillment |
| 11:41 | <Andreu Botella> | WebIDL's "upon fulfillment" queues a microtask for you, right? (It seems to call into TC39 land which call the host enqueue promise job algo). Only reason I'm not sure is because I see some specs explicitly queue a microtask themselves: https://w3c.github.io/ServiceWorker/#ref-for-upon-fulfillment |
| 11:42 | <Dominic Farolino> | 👍️ I'll get a PR together |
| 11:42 | <Andreu Botella> | I was gonna do it myself, but sure |
| 11:43 | <Andreu Botella> | That said, there might be observable behavior differences if you didn't queue a microtask in those specs |
| 11:45 | <Andreu Botella> | since the microtask queue is FIFO and any microtasks enqueued between the time the promise resolves and the time the "upon fulfillment" steps run would run before the microtask that actually does the reaction work |
| 11:48 | <canadahonk> | canadahonk: as your contributions would be on behalf of that entity, but I'm not sure if that applies to you or not |
| 23:09 | <canadahonk> | is there any kind of "mapping" for safari TPs -> stable releases? (for referencing/etc) |
| 23:34 | <Sam Sneddon [:gsnedders]> | is there any kind of "mapping" for safari TPs -> stable releases? (for referencing/etc) |