06:15 | <sideshowbarker> | sideshowbarker: now that https://html.spec.whatwg.org/review-drafts/2020-01/ is a Rec would it be possible to get redirects/NOTE stubs for as much of https://wiki.whatwg.org/wiki/Fork_tracking as possible? Like was done for the other specs? |
06:15 | <sideshowbarker> | I’ve done some of the HTML ones, but need to audit against that list to get them all |
15:05 | <sideshowbarker> | looking at https://github.com/mdn/content/pull/6009 |
15:06 | <sideshowbarker> | can anybody suggest a test case/demo that would demonstrate an empty string for location.pathname ? |
15:07 | <sideshowbarker> | when a browser navigates you to a particular site, it’s got to have a path, right? |
15:07 | <Domenic> | Maybe data: |
15:07 | <sideshowbarker> | how can you navigate to a URL that doesn’t have a path? |
15:08 | <Domenic> | Neither Chrome nor Firefox allow navigating to data: though |
15:08 | <sideshowbarker> | in other words, is it actually possible in practice for location.pathname to be the empty string rather than an actual path? |
15:09 | <Domenic> | In the current browsers that I am testing with it does not seem to be possible |
15:09 | <Domenic> | But it's not prohibited per spec |
15:09 | <Domenic> | Oh |
15:09 | <Domenic> | In Firefox about:blank has empty pathname |
15:09 | <Domenic> | (Per spec pathname should be "blank") |
15:10 | <Domenic> | Wait no |
15:10 | <Domenic> | Using new URL() about:blank has empty pathname, but using Location it has blank as the pathname |
15:12 | <sideshowbarker> | yeah OK that is reassuring :) |
15:12 | <sideshowbarker> | I guess the MDN article is just trying to say too much here |
15:13 | <sideshowbarker> | at https://html.spec.whatwg.org/multipage/history.html#dom-location-pathname-dev the spec just says:
|
15:14 | <sideshowbarker> | I’m not sure it’s useful to say anything more than that |
15:14 | <sideshowbarker> | hmm, well, I see now the MDN article doesn’t mention setting it, though the spec does |
15:15 | <sideshowbarker> | the fact that it can be set and that setting it causes a navigation is pretty useful info |
15:15 | <sideshowbarker> | Can be set, to navigate to the same URL with a changed path. |
15:16 | <sideshowbarker> | hmm, though “same URL with a changed path” maybe it not the greatest wording — if the path changes, it’s not the “same URL” any more |
16:41 | <wanderview> | new URL("data:") has an empty pathname and is valid in spec and chrome at least |
16:42 | <sideshowbarker> | But is that a location? Can you navigate to it? |
17:34 | <wanderview> | are navigations limited to special schemes or something? otherwise anything that uses a custom scheme can have an empty path |
17:34 | <Domenic> | Yeah above I was trying to test non-special schemes and didn't find any that a browser could navigate to |
17:35 | <Domenic> | But there's nothing prohibiting such navigations. |
17:36 | <Domenic> | Maybe if you launched the browser from the command line... |
17:36 | <wanderview> | or a redirect? |
17:37 | <wanderview> | or an extension helping with the navigation |
17:39 | <Domenic> | Navigate can either go to a fetch scheme (about, blob, data, file, http, https) or javascript: or ends up in https://html.spec.whatwg.org/#process-a-navigate-url-scheme . The latter will always result in an opaque-origin page so unless the page itself gets to run JS nobody will be able to observe location.pathname being empty string. So that's why I was focused on about, data, and javascript. |
17:40 | <Andreu Botella (he/they)> | This reminds me, has there been any progress on defining "navigation specifically through the URL bar"? |
17:42 | <Andreu Botella (he/they)> | Or I guess opening the browser from the command line should have the same result, minus creating the browsing context |
17:43 | <Domenic> | Command line and URL bar are different it turns out since the URL bar does searches |
17:43 | <Domenic> | So javascript: from command line opened the new tab page whereas typing that in the URL bar did a search |
17:44 | <Domenic> | Anyway defining navigation through the URL bar is somewhat happening, see https://wicg.github.io/app-history/#user-initiated-patches |
17:45 | <Andreu Botella (he/they)> | I thought the specs could ignore the URL bar search, treating it as "navigation through the URL bar" to the search engine |
17:45 | <Andreu Botella (he/they)> | Testing that would be trickier though |
17:46 | <Domenic> | Agreed they'd ignore the distinction, just saying that it turns out they are different and that made trying to generate degenerate empty-path pages tricky :) |
17:46 | <Andreu Botella (he/they)> | Right 👍️ |
19:35 | <smaug> | Domenic: silly question, how do I get from https://github.com/WICG/app-history to https://wicg.github.io/app-history/ ? |
19:47 | <Domenic> | smaug: ^ (it seems Matrix doesn't let you type a message to go with your image upload...) |
19:48 | <smaug> | there |
19:48 | <smaug> | thanks |
19:48 | <smaug> | I was going through the text |
19:49 | <smaug> | (still don't know whether I should read readme or the spec, or both) |
19:49 | <Domenic> | The spec should be a subset of the readme |
19:50 | <Domenic> | Corresponding to the parts I've managed to make precise |
20:26 | <Luca Casonato> | Is there a specification that defines the ! prefix for preform steps in specifications? For example in Perform ! stream.[[controller]].[[ErrorSteps]]() , what does the ! mean? |
20:27 | <timothygu> | Luca Casonato: https://timothygu.me/es-howto/#completion-records-and-shorthands |
20:27 | <timothygu> | specifically https://timothygu.me/es-howto/#exclamation-mark |
20:27 | <Luca Casonato> | Ah! Thanks :-) |
20:28 | <Domenic> | I regret using ECMAspeak in the Streams spec... only a bit remains, but the !s and ?s are definitely part of it. |
20:29 | <Domenic> | annevk: jgraham: apparently you can make rooms have avatars; we should make the WHATWG logo this room's avatar. |
20:29 | <Andreu Botella (he/they)> | annevk: jgraham: apparently you can make rooms have avatars; we should make the WHATWG logo this room's avatar. |
20:30 | <Domenic> | Hmm, not for me, even after reloading; rather curious. |
20:30 | <Luca Casonato> | Yeah, isn't for me either. |
20:30 | <timothygu> | Ah, but if one clicks on the icon, the avatar shows up |
20:31 | <timothygu> | I'm guessing the avatar is SVG, which only some clients support :') |
20:31 | <Luca Casonato> | Oh, very interesting: https://matrix-client.matrix.org/_matrix/media/r0/thumbnail/mozilla.org/56b9d49c31be7d13714fa95e8c4674a4ea58d745?width=96&height=96&method=crop |
20:31 | <Luca Casonato> | seems the icon lives on mozilla.org? |
20:31 | Andreu Botella (he/they) | dives into the matrix specs |
20:32 | <Luca Casonato> | i was sort of expecting the icon to live on the same server as the room itself (matrix.org afaik for this room) |
20:32 | <Luca Casonato> | anyway, i have no idea how matrix works lol |
20:32 | <timothygu> | Nah, we had the same issue over on #jsdom:matrix.org |
20:33 | <timothygu> | SVG only shows up in some cases. PNG works everywhere. |
20:38 | <Luca Casonato> | Domenic: Working on some streams spec impl fixes in Deno, but I am running into a case where WritableStreamDefaultController[[AbortAlgorithm]] is undefined when calling WritableStreamDefaultController[[AbortSteps]] in WritableStreamFinishErroring because WritableStreamDefaultControllerError called WritableStreamDefaultControllerClearAlgorithms before calling WritableStreamStartErroring . Could this be a spec issue? |
20:39 | <Domenic> | Luca Casonato: it seems unlikely as I think that code path is well-tested in the reference implementation but it's always possible. I'd suggest opening an issue on whatwg/streams so folks can dive in when they have time. |
21:53 | <Luca Casonato> | Luca Casonato: it seems unlikely as I think that code path is well-tested in the reference implementation but it's always possible. I'd suggest opening an issue on whatwg/streams so folks can dive in when they have time. |
21:55 | <Luca Casonato> | Regarding the participant agreement - it got it signed a few weeks ago, but it hasn't been verified yet. Who can I ping for that? :-) |
21:56 | <Domenic> | I just verified it; we generally verify it the first time it's needed. |
21:56 | <Luca Casonato> | Ah I see you just did it, thanks :-) |