| 01:10 | <gsnedders> | astearns: but plenty of software projects do this all the time with multiple branches |
| 01:10 | <gsnedders> | like, I don't buy the argument that it's too hard. |
| 01:14 | <gsnedders> | IMO, what we need is a continious master branch and occasional stability branches where we push things to REC by dropping at-risk content |
| 01:25 | <gsnedders> | and we should look at how other software projects deal with long-term maintainence branches |
| 01:25 | <gsnedders> | Because like them ultimately we're just dealing with large text files. |
| 01:28 | <astearns> | gsnedders: I did briefly consider a branching strategy for next-level drafts today. I think the main concern would be how we host the various branches. People will want a single place to see foo-3 and foo-4 drafts, and argue that outsiders shouldn't need to understand our branching strategy to see the latest ideas for each level. |
| 01:37 | <gsnedders> | astearns: for the git repo or for drafts.csswg.org? |
| 01:37 | <gsnedders> | I mean all the git tooling for applying patches to multiple branches rely on actual git branches not just copy/pasted folders, which means we can't use any standard tooling |
| 01:38 | <gsnedders> | and that hsas a very real cost, IMO, |
| 01:50 | <MikeSmith> | jyasskin: yeah building HTML with Bikeshed would make a number of things easier as far a maintenance, but we not going to be moving HTML to Bikeshed any time soon |
| 03:34 | <astearns> | gsnedders: for drafts.csswg.org. If we can flatten out relevant git branches to a single web host, I think we could do away with diff specs |
| 06:21 | <xfq> | tobie: in specref, how to fetch Unicode UAXes automatically? |
| 06:21 | <xfq> | (maybe also UTSes and UTRs) |
| 06:21 | <xfq> | I'll see if I can write a script for that, if you'd like to point me in the right direction |
| 06:21 | <xfq> | thanks |
| 06:37 | <jochen__> | annevk, thx! |
| 06:42 | <tobie> | xfq: you can look at the scripts folder. There's a bunch of helpers in there. |
| 06:43 | <tobie> | xfq: a good example is W3C.js for a rather complex case |
| 06:45 | <tobie> | xfq: If you already have json as a src, then look at the examples inside of the scripts/fetch-helpers |
| 06:46 | <tobie> | xfq: all scripts then end up being called by the update-all bash script which runs hourly. |
| 06:47 | <tobie> | xfq: iirc, for Unicode, you'll have to fetch the web page and parse the table. |
| 06:56 | <xfq> | tobie: Thank you. I'll look into it. |
| 07:58 | <freesamael> | annevk: Do you have any plan on how we can push the session history issue forward? https://github.com/whatwg/html/issues/1454 |
| 08:06 | <annevk> | freesamael: not really, it's a rather daunting task |
| 08:08 | <annevk> | freesamael: I also haven't studied history enough to know if we could do it in small chunks |
| 08:08 | <annevk> | freesamael: I'd actually expect you to know much better than I how to tackle this |
| 08:10 | <freesamael> | annevk: I'm actually willing to work on it. Just that there still something hasn't been clarified and I don't know how (process-wise) I can push this forward. |
| 08:11 | <freesamael> | annevk: Do you know if we're toward Servo's proposal and maybe do something based on that? |
| 08:13 | <annevk> | freesamael: I see |
| 08:13 | <annevk> | freesamael: https://whatwg.org/working-mode#changes has some high-level notes on the process |
| 08:14 | <annevk> | freesamael: I think it's already demonstrated that we don't match implementations so we have to change |
| 08:14 | <annevk> | freesamael: so that then leaves tests, implementation bugs, and a PR that changes the text |
| 08:15 | <annevk> | freesamael: I don't know how close Servo gets to more widely deployed browsers |
| 08:15 | <annevk> | freesamael: I would expect a change to more closely align the spec with Chrome/Edge/Firefox/Safari primarily, and Servo secondarily |
| 08:16 | <annevk> | freesamael: unless for some reasons the Chrome/Edge/Firefox/Safari all have weird cases that Servo somehow smoothed out and everyone is willing to align with Servo |
| 08:17 | <annevk> | freesamael: so concretely, I would expect a high-level description of a new model given that the current model is flawed, then tests against that new model to make sure it doesn't stray too far from implementations, and then find agreement on the new model and refine it along the way |
| 08:18 | <annevk> | freesamael: and then probably write a change to the specification and get that reviewed, then file browser bugs and land all the tests in web-platform-tests |
| 08:18 | <annevk> | freesamael: does that seem reasonable? |
| 08:19 | <annevk> | (I would be extremely happy to see you pull this off btw; and I'm sure many other people would be too) |
| 08:21 | <freesamael> | annevk: Yes. That roughly points how long the path will be :) |
| 08:21 | <freesamael> | About the model, what I was thinking is either we could be based on the servo paper's "joint session past / future" model, and try to align that with browser behavior, or we could start from scratch to made a tree structure model. |
| 08:21 | <freesamael> | One main blocker is probably that browsers have quite different implementation on iframe histories |
| 08:23 | <annevk> | freesamael: yeah, I don't know how much Servo's model is based on what implementations do |
| 08:23 | <annevk> | freesamael: ajeffrey_ can probably help clarify that, but I'm not sure when he's around |
| 08:24 | <annevk> | https://github.com/asajeffrey says Chicago so I guess not now |
| 08:25 | <annevk> | freesamael: if Servo is a reasonable approximation of what Firefox does that might be a good start |
| 08:26 | <annevk> | freesamael: it does seem like the proposed model from the paper would at least be better than what we have today 😊 |
| 08:27 | <freesamael> | annevk: That's what I think. I'm not sure if it will be easier to align browsers' behaviors than a re-designed tree structure, tho. |
| 08:28 | <annevk> | freesamael: is the Servo model not a tree? |
| 08:29 | <annevk> | freesamael: because then I suspect it would be hard to get it adopted by others |
| 08:35 | <freesamael> | annevk: Servo's paper was more like an improvement on the current joint session history concept, so it's still "browsing contexts have distinct session history" rather than Firefox's "root browsing context hold a tree of session history which include the entries for nested browsing contexts". I somewhat feel there are pros and cons for both concepts, even if |
| 08:35 | <freesamael> | we eventually model the same behavior. |
| 08:36 | <freesamael> | annevk: The downside of joint session history is that we need to describe how a discarded nested browsing context's session history is kept by the root browsing context, and how we can map that back to nested browsing contexts when it's recreated on history navigation. |
| 08:37 | <annevk> | freesamael: okay, from what I know (which isn't much) what Firefox has as model is also something which other browsers have, modulo bugs and minor differences, so I'd expect that to be easier to align on, but you probably know the details better |
| 08:38 | <freesamael> | annevk: Humm.. I'll think about it. I'm also trying to understand Chromium's current history implementation "PlzNavigate" |
| 08:39 | <annevk> | freesamael: maybe as a first step you could write a brief description of both models and the tradeoffs and email smaug____ / ajeffrey_ and some of the Chrome folks involved with PlzNavigate (and Domenic for good measure) for feedback? |
| 08:39 | <annevk> | freesamael: or maybe just add it as a comment in the issue |
| 08:39 | <annevk> | freesamael: and I'll try to help out to get everyone to give feedback |
| 08:40 | <annevk> | freesamael: I would expect that given an explicit choice like that they all might remember some additional things why things are the way they are |
| 08:41 | <smaug____> | (last time I looked at the paper, it was missing all the interesting edge cases which make session history so hard) |
| 08:48 | <freesamael> | smaug____: Yes. But on the other hand I'm not sure if describing things like RemoveDynEntries and RemoveDuplicate is easy in the spec. I'm just not sure which is harder - rewritting in a tree structure or trying to add these missing tricky iframe cases in that joint session future / past concept. |
| 08:49 | <smaug____> | For some reason all the browser engines have the tree model |
| 08:50 | <smaug____> | (not talking about Servo) |
| 08:50 | <smaug____> | and given that session history is very regression prone, changing the model might be hard |
| 08:52 | <annevk> | It also seems unlikely that browsers would rewrite it unless there's some very solid advantages |
| 08:52 | <freesamael> | that's true |
| 09:06 | <freesamael> | I guess the easiest way for me to start with is probably making a clear documentation on whatever Firefox implements, and ask for feedbacks from other browser vendors to see how different they handle these cases. Hopefully that helps us to push the discussion forward. |
| 09:09 | <annevk> | freesamael: yeah, you could even tackle the question part yourself by writing tests |
| 09:10 | <annevk> | freesamael: though that might be tricky if you still expect many changes |
| 09:10 | <annevk> | freesamael: but it will help you identify the parts of the model that are solid and those that probably need more work |
| 11:03 | <kochi> | annevk: re https://github.com/whatwg/dom/pull/513 my intern is working on WPT side but still needs work, hopefully complete next week. |
| 11:16 | <beverloo> | do we still have irc logs for this channel? somebody pinged me, but I can't see who/why |
| 11:18 | <beverloo> | (found it on the wiki) |
| 11:18 | <beverloo> | MikeSmith (hi again!) - re: file:// URLs, I think it must've broken around Chrome 40-45ish when we aligned with the common permission infrastructure in Chrome, that hasn't dealt with file:// URLs well at all |
| 11:19 | <beverloo> | I think we have an exception for Flash right now, for which it does work |
| 11:31 | <smaug____> | Does anyone recall some github issue which has lots of comments? |
| 11:31 | smaug____ | needs one for testing |
| 11:37 | <annevk> | smaug____: https://github.com/whatwg/fetch/issues/27 |
| 11:37 | <annevk> | smaug____: and its successor might also qualify: https://github.com/whatwg/fetch/issues/447 |
| 11:37 | <smaug____> | thanks |
| 11:38 | <annevk> | kochi: great! |
| 11:42 | <MikeSmith> | howdy beverloo |
| 11:42 | <MikeSmith> | thanks |
| 13:08 | <annevk> | JakeA: any closer to getting AppCache removed? |
| 13:14 | <JakeA> | annevk: the implementation work is wait for a new owner :( https://bugs.chromium.org/p/chromium/issues/detail?id=588931 |
| 13:15 | <mkwst> | JakeA: That was work to deprecate it over plaintext. We don't have anyone working on removing it entirely (that I know of). |
| 13:15 | <mkwst> | It seems like a good thing to do, though! |
| 13:15 | <JakeA> | Yeah, removing it over HTTP would be a good first step |
| 13:15 | <mkwst> | annevk: Is anyone at Mozilla looking into it? There was an announcement quite some time ago that it was to be deprecated. |
| 13:16 | <mkwst> | JakeA: I'm not actually sure it's any less work than removing it entirely. Folks were concerned about data loss, as I recall, and I don't think we found good answers for them. |
| 13:16 | <mkwst> | But our cultural knowledge of that discussion left with Joel. So. |
| 13:17 | <JakeA> | I can't think of a data-loss case. I think the issue suggested stubbing out the API but never returning something from the service worker cache. That could work if sites are expecting the API, but I don't know if that's the case. |
| 13:19 | <mkwst> | There was a long thread on blink-dev. rbyers might remember details. |
| 13:19 | <mkwst> | If not, Michael Nordman, maybe? |
| 13:21 | <annevk> | mkwst: I'm not aware of anything recent |
| 13:21 | <annevk> | mkwst: I just worry I end up having to define it properly, though maybe I can get JakeA to do that 😛 |
| 13:22 | <mkwst> | Removing features from the platform to save yourself some work sounds like a wonderful idea! |
| 13:22 | <mkwst> | Can I add some things to the list? :P |
| 13:23 | <annevk> | We should just preemptively add all new ideas |
| 13:40 | JakeA | runs away |
| 14:13 | <Domenic> | freesamael: I am very happy to help with the session history work. It's on my "things I definitely want to do but never manage to get high enough on my to do list to actually happen" list. Which effectively means it's probably not going to happen if I have to do the work, but I can still help review/guide etc. |
| 14:40 | <Domenic> | annevk: is https://github.com/whatwg/html/issues/333 fixed? |
| 14:41 | <annevk> | Domenic: no |
| 14:41 | <Domenic> | Aww |
| 14:42 | <annevk> | Domenic: it seems like we have enough infrastructure to solve it |
| 14:42 | <annevk> | Domenic: maybe |
| 14:42 | <annevk> | Domenic: because we have serialization/deserialization today |
| 14:46 | <Domenic> | Yeah, I thought maybe we would have fixed it while doing all that, but I guess not yet |
| 14:58 | <annevk> | Domenic: https://github.com/whatwg/html/pull/2277 was the last attempt at fixing it, I think that's before the serialize/deserialize thing happened |
| 14:58 | <annevk> | Domenic: maybe I'll give this a go tomorrow |
| 17:28 | <wanderview> | JakeA: are you still open for questions today or are you already at the pub? |
| 17:34 | <JakeA> | wanderview: I wish. Walking home from the station though. Can answer whatever I can from my phone |
| 17:35 | <wanderview> | JakeA: I'm putting it in an issue... another range request thing to add to the pile |
| 17:38 | <wanderview> | JakeA: https://github.com/w3c/ServiceWorker/issues/1201 |
| 20:18 | <rbyers> | annevk, mkwst: Yeah I had some discussion with Joel and have some context. Personally I'm fairly skeptical that we can remove AppCache anytime soon. It seems like we really need service worker to be supported everywhere before we can reasonably expect usage to drop enough. |
| 20:19 | <rbyers> | ... As one example (which I believe is representative, but one that I'd certainly avoid relying on as a specific case given it's a google property) mobile GMail's primary client is iOS. It makes little sense for them to shift to a ServiceWorker model until iOS supports it. |
| 20:19 | <rbyers> | ... And AppCache is still absolutely critical for good performance of mobile GMail. |
| 20:22 | <rbyers> | [aside: whoa, why the heck am I using W3C-scribe style on #whatwg IRC? Perhaps my brain is preparing itself to be sitting in CSSWG meetings in TPAC <grin>] |
| 20:24 | <rbyers> | Anyway I've heard a few other anecdotes of sites that feel they really don't have the choice to drop AppCache yet that make me think there's a general problem here still, but I don't think anyone has done the analysis. I could be convinced by data that (outside mobile/offline GMail) there's really no good reason people should still be relying on AppCache and hence we should be more aggressive about removal in chromium. |
| 20:25 | <rbyers> | Either way with SW finally in progress in WebKit it does feel like just a matter of time to me, hardly seems worth investing in improving the spec. Shouldn't be long before nobody in their right mind would write any new code depending on it... |
| 20:44 | <annevk> | rbyers: there was a similar story for mutation events; we still have those |
| 21:07 | <Domenic> | ;_; |