| 05:25 | <leonardus> | What's the difference between http://example.org/dir and http://example.org/dir/ |
| 05:26 | <leonardus> | (the trailing slash) |
| 05:45 | <annevk> | leonardus: different path |
| 05:45 | <annevk> | leonardus: per spec the latter has an empty path segment at the end |
| 10:40 | <MikeSmith> | nice Stack Overflow success story: |
| 10:40 | <MikeSmith> | https://stackoverflow.com/questions/56877116/flask-logs-duplicate-xhr-cors-requests-from-safari |
| 10:41 | <MikeSmith> | question posted to SO on July 3, with detailed repro steps |
| 10:42 | <MikeSmith> | ...in fact, a github repo with the repro dependencies and instructions https://github.com/karls/flask-safari-troubleshoot |
| 10:42 | <MikeSmith> | then https://bugs.webkit.org/show_bug.cgi?id=199492 raised on July 4 |
| 10:43 | <MikeSmith> | then Youenn lands a fix only July 9 https://trac.webkit.org/changeset/247276 |
| 12:31 | <ato> | Apparently Chrome appends / to the URL when browsing a directory over file://. |
| 12:31 | <ato> | Is the behaviour of file:// covered by a standard, or is this intentionally out of scope? |
| 12:34 | <Ms2ger> | "For now, unfortunate as it is, file URLs are left as an exercise for the reader. " |
| 12:35 | <annevk> | I should maybe start using "implementation-defined" for things like that |
| 12:42 | <ato> | Ms2ger: Thanks. |
| 12:42 | <ato> | Ms2ger: Is this from URL? |
| 12:43 | <Ms2ger> | Fetch |
| 12:43 | <ato> | Ah. |
| 12:47 | <annevk> | ato: parsing is defined, fetching is not |
| 12:47 | <annevk> | ato: it's origin isn't either |
| 12:47 | <annevk> | its |
| 12:47 | <annevk> | ouch |
| 12:48 | <ato> | Great, thanks. |
| 12:48 | <ato> | Well not great, but now I see. |
| 12:53 | <Dari> | Chrome bug: closed because behaviour matches the spec https://bugs.chromium.org/p/chromium/issues/detail?id=20574 W3C bug: closed because "<ericwilligers_> dbaron: it is a little late to change that." "<ericwilligers_> dirk: confirm WebKit behaves same as Edge and Chrome and Firefox in creating a containing block." |
| 12:53 | <Dari> | Originally only Chrome had this behaviour, IE/FF/Opera all changed to match the spec. Instead of Chrome talking about what the spec says, and W3C talking about current browser behaviour, why don't people talk about what makes sense? |
| 12:54 | <Dari> | The purpose of position fixed is to make sure an element is always relative to the viewport, if under certain conditions it's basically just position: absolute/relative what purpose does it serve? No one can be confident in using if it only does what you expect it to under certain conditions. |
| 12:54 | <Dari> | Oh, this is the "3C bug btw https://github.com/w3c/csswg-drafts/issues/913 |
| 12:57 | <Dari> | Someone on the W3C bug mentions that there's some complexity with changing this behaviour, but IE/FF/Opera did have this behaviour originally, and in it's current state it's effectively useless IMO, I don't think 'it would be hard' is a good excuse for closing the bug |
| 13:05 | <annevk> | This isn't the place to escalate |
| 13:06 | <annevk> | And if you want to overturn such a decision you'll have to justify the engineering cost involved somehow, relative to other work |
| 13:07 | <annevk> | As well as take into consideration the compatibility fallout if it goes entrenched behavior |
| 13:09 | <Dari> | What is the correct place? |
| 13:12 | <annevk> | Dari: leaving a comment on that issue, potentially filing a new issue given it's been almost a year (given it's almost a year, it seems even harder to overturn and you'll need even better justification; definitely more than what you wrote above) |
| 13:30 | <Dari> | Hmm, well it's hard to justify given factors you've mentioned. The only justification I have is that the proposed behaviour makes more sense, and I think that position fixed won't be used by people who've found out about the current behaviour (from discussion and resources I've seen online it feels like most people are still unaware of how it actua |
| 13:30 | <Dari> | lly works) |
| 13:32 | <Dari> | It's always going to be easier to leave it half broken than try and fix it |
| 13:34 | <annevk> | Dari: yeah, engineering tradeoffs are hard |
| 13:34 | <annevk> | Dari: note though that even if this is entrenched for whatever reason, offering some opt-out might still be a reasonable request |
| 13:35 | <annevk> | Dari: and worth doing if there are compelling use cases |
| 13:35 | <annevk> | Dari: and perhaps this will also motive you to get involved earlier and review other discussions going on 😊 |
| 13:36 | <annevk> | motivate* |
| 13:37 | <Dari> | Thanks for your time, you've given me some things to think about |
| 15:55 | <Domenic> | annevk: do you have time for the navigation refactor (https://github.com/whatwg/html/pull/4664) today? |
| 15:58 | <annevk> | Domenic: no, hopefully tomorrow |
| 15:58 | <Domenic> | OK cool, thanks for letting me know. Just very excited to land that :) |
| 16:18 | <annevk> | Yeah, totally fair, and it'll probably help with COOP/COEP too so I should get to it |
| 16:31 | <Domenic> | The only really broken thing left with navigation after that is source browsing context, I think. |
| 16:31 | <annevk> | Oh my and multipart from a quick skim I did earlier |
| 16:32 | <Domenic> | Yeah true |
| 16:33 | <annevk> | I think we're quite close with source browsing context, esp. if navigation always happens synchronously (because then it can be a "source document" as it should be quite easily) |
| 16:33 | <Domenic> | Oh yeah I forgot we're making a lot of progress on sync vs. async navigation |
| 16:34 | <Domenic> | Although I guess there's a lot of implicitness in "element that caused the navigation" and thus "document that caused the navigation" |
| 16:34 | <Domenic> | That shouldn't be too hard to fix though, navigate doesn't have too many call sites in the spec |
| 16:44 | <dtapuska> | I'm hopeful to start taking another stab at the agent cluster stuff based on 4664 |
| 16:50 | <annevk> | The other big thing is inheritance of document state into weird URL schemes |
| 16:51 | <annevk> | Oh and downloads |
| 16:51 | <annevk> | Hmm |
| 16:53 | annevk | whispers *session history* |
| 17:38 | <Domenic> | Inheritance of document state into weird URL schemes? |
| 17:39 | <Domenic> | downloads seem pretty reasonable to me |
| 17:42 | <annevk> | Domenic: e.g. referrer policy et al into srcdoc / about:blank / data: / blob: |
| 17:43 | <annevk> | Domenic: and in particular when is the policy copied and such |
| 17:43 | <annevk> | Domenic: afaik downloads aren't defined as a navigation still |
| 17:43 | <Domenic> | Downloads are defined as a navigation I am pretty sure |
| 17:43 | <Domenic> | I see the problem with weird URLs |
| 17:43 | <annevk> | "Handle the result of fetching request as a download." |
| 17:44 | <Domenic> | I see yes |
| 17:44 | <Domenic> | It's backwards from what you're proposing: navigations can end up as downloads. https://html.spec.whatwg.org/#navigating-across-documents:as-a-download |
| 17:45 | <annevk> | Well, that too, download="" just forces that code path (again, in impls) |