| 06:20 | <annevk> | Ugh, some kind of OS X autocorrect thing added a space between opaque and redirect |
| 06:20 | <annevk> | Fortunately that only happened in the commit message |
| 06:35 | <annevk> | SimonSapin: and UAs implement that beyond 1024 bytes? |
| 07:58 | <SimonSapin> | annevk: html5lib has code for it, but I’ll have to test it in other impls |
| 09:30 | <annevk> | Any love here for range.insert(nodes...)? https://www.w3.org/Bugs/Public/show_bug.cgi?id=27650 |
| 09:49 | <annevk> | TabAtkins: using "<a spec=url>URL</a>" within DOM doesn't give the expected result |
| 10:01 | <JoWie> | why not make document fragments easier to use |
| 10:03 | <JoWie> | keep ranges as they are, and support something like document.createDocumentFragment(node1, node2, ...) |
| 10:03 | <annevk> | well, we could add that to new DocumentFragment() I guess |
| 10:04 | <annevk> | I guess the question is whether we'll ever need more arguments to support |
| 10:05 | <JoWie> | well in that case we could add a second method that is intended just for this convenience |
| 10:06 | <JoWie> | instead of using new DocumentFragment or document.createDocumentFragment |
| 10:06 | <JoWie> | could even add such a convenience method to collections |
| 10:06 | <annevk> | JoWie: maybe add that comment to that bug |
| 10:07 | <JoWie> | range.insertNode(document.getElementsByClassName('foo').toFragment()) |
| 10:07 | <JoWie> | sure |
| 10:08 | <Ms2ger> | new DocumentFragment(...document.getElementsByClassName('foo'))? |
| 10:08 | <JoWie> | yes or that |
| 10:08 | <annevk> | Ms2ger: yeah, JoWie, I meant the "make DocumentFragment easier" comment |
| 10:09 | <annevk> | JoWie: that seems spot on, toFragment() a lot less |
| 10:17 | <JoWie> | posted the comment |
| 10:17 | <JoWie> | bugzilla redirected me to a completely different bug after I submitted it, very weird |
| 10:18 | <annevk> | it does that sometimes when stuff is part of a collection or so |
| 10:18 | <annevk> | so you get to see more bugs? I'm not really sure what the purpose is |
| 10:18 | <annevk> | the whole page refresh is kind of oldfashioned |
| 10:18 | <JoWie> | Changes submitted for bug 27650... then on the same page: Bug 27688 - Odd comment in DO... |
| 10:21 | <JoWie> | speaking of that bug annevk, does subclassing Array work well with the live-ness of the dom collections? |
| 10:21 | <annevk> | JoWie: not sure which bug you're talking about, but a subclass of Array would only be used for a snapshot |
| 10:21 | <JoWie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27688#c3 |
| 10:22 | <JoWie> | the one i was redirected to ;) |
| 10:23 | <annevk> | Weird, that one is fixed |
| 11:37 | <SimonSapin> | Hixie: Are you aware of a case where "prescan a byte stream to determine its encoding" would fail to find an encoding when given 1024 bytes, but tree construction would still "change the encoding" based on a meta start tag in the first 1024 bytes? |
| 12:01 | <annevk_> | philipj: any opinions on https://www.w3.org/Bugs/Public/show_bug.cgi?id=27456 and https://bugzilla.mozilla.org/show_bug.cgi?id=1061578? |
| 12:02 | <annevk> | SimonSapin: I think hsivonen might have some statistics |
| 12:24 | <philipj> | annevk: ugh, namespace lookup? |
| 12:33 | <philipj> | annevk: commented on the bug, but haven't looked at any of this before |
| 12:36 | <annevk> | Hopefully Arkadiusz replies since indeed, ugh, namespaces |
| 12:37 | <annevk> | They're not the greatest APIs for dealing with them either |
| 12:43 | <philipj> | Are they supposed to reflect something like "the prefix->namespace" mappings that the parser would have used here? |
| 12:43 | <philipj> | move " to the end |
| 12:44 | <annevk> | philipj: something like that, I suppose |
| 12:44 | <annevk> | philipj: designed before my time |
| 12:44 | <philipj> | well, it sure looks weird as implemented in Blink |
| 12:45 | <philipj> | so I hope Arkadiusz will just tell me what to do :) |
| 12:57 | <annevk> | philipj: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25428? |
| 12:58 | <philipj> | annevk: hasFeature() now always returns true in Blink |
| 13:01 | <philipj> | annevk: I'll comment and close the bug |
| 13:01 | <annevk> | philipj: ta |
| 13:13 | <annevk> | MikeSmith: is there a way to close Bugzilla components for new bugs while still letting you mess around with existing bugs? |
| 13:13 | <annevk> | MikeSmith: I think other than HTML/Unwelcome, we're probably ready for such a switch within WHATWG and perhaps some WebAppsWG components |
| 13:15 | <annevk> | philipj: and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27386? |
| 13:16 | annevk | is doing some bug triage today |
| 13:16 | philipj | can tell |
| 13:17 | <philipj> | annevk: how much effort do you want to spend trying to kill CDATASection? |
| 13:17 | <annevk> | I don't know |
| 13:17 | <annevk> | Ms2ger: ^^? |
| 13:17 | <annevk> | philipj: I have stopped caring about a lot of these things, although any simplification we can make would still be nice |
| 13:18 | <philipj> | I tried to measure the cases where CDATASection was serialized at one point, but failed, and even if we could measure it I don't know what it would say about the risk |
| 13:18 | <philipj> | Well, if it never happens then the risk is low |
| 13:19 | <philipj> | but since CDATASection can't be nuked thoroughly, I'd vote to just keep it around and wait until time machines become available |
| 13:20 | <Ms2ger> | I know I don't want to add it to Servo :) |
| 13:21 | <annevk> | philipj: why can't we nuke it thoroughly? |
| 13:21 | <philipj> | annevk: because createCDATASection is used |
| 13:21 | <annevk> | philipj: that could return a Text node? |
| 13:22 | <philipj> | it could, but it's not as thoroughly nuked as it could be |
| 13:22 | <annevk> | Well, the node is gone |
| 13:22 | <annevk> | That's what matters |
| 13:22 | <philipj> | sure, that's not bad |
| 13:23 | <Ms2ger> | createCDATASection itself is a lot less complexity compared to another Node type |
| 13:23 | <philipj> | since CDATASection inherits from Text there isn't much complexity here |
| 13:24 | <philipj> | I tried to remove it just to see, and it wasn't a lot of code that needed fixing or could be removed |
| 13:24 | <philipj> | that being said, I'd be happy to see it gone, I'm just not excited enough to spend a lot of effort figuring out how to do it |
| 13:25 | <annevk> | Thanks, let me summarize this in a new comment, I guess I'll just leave it open for now |
| 13:50 | <wanderview> | annevk: got time to talk about RequestMode and navigations? |
| 13:51 | <annevk> | wanderview: yes |
| 13:51 | <wanderview> | annevk: can you explain why you think navigations should get RequestMode 'same-origin'? It seems navigations can normally redirect cross-origin, etc |
| 13:52 | <wanderview> | I guess google does this when you click on a search result, etc |
| 13:52 | <annevk> | wanderview: a navigation doesn't follow redirects |
| 13:52 | <annevk> | wanderview: each redirect is examined by the navigate algorithm and then acted upon with probably fresh request |
| 13:53 | <annevk> | wanderview: although whether we should model it that way is still a bit unclear to me |
| 13:54 | <wanderview> | annevk: I guess this annoyance I am running into is that RequestMode almost maps to our new gecko security policies: https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl?from=nsILoadInfo.idl&case=true#38 |
| 13:54 | <wanderview> | annevk: except for navigations... the navigations will get SEC_ALLOW_CROSS_ORIGIN_DATA_INHERITS I think... but I will have to special case RequestMode on navigations to force same-origin |
| 13:55 | <wanderview> | which makes me wonder if the same-origin RequestMode is correct |
| 13:55 | <annevk> | You think it should be "no-cors"? |
| 13:55 | <annevk> | Or a special mode? |
| 13:57 | <wanderview> | annevk: well, we used to have a "if client request, then do extra check" in HTTP Fetch step 2.2 |
| 13:58 | <wanderview> | annevk: also, chrome currently gives navigations "no-cors" (but has the old extra client request check you removed) |
| 13:58 | <annevk> | wanderview: well, workers are same-origin, we agree on that, right? |
| 13:59 | <wanderview> | annevk: yes, although chrome also seems to give them no-cors... I think thats incorrect, though |
| 13:59 | <wanderview> | annevk: workers will get a SEC_SAME_ORIGIN security policy |
| 13:59 | <wanderview> | in gecko |
| 14:00 | <annevk> | we could keep say that navigations are no-cors and add a check for navigation requests (not clients) |
| 14:00 | <annevk> | maybe that's better and maybe even navigations keep some state around when they hit a redirect |
| 14:01 | <annevk> | e.g. I guess Referrer is still the same |
| 14:03 | <annevk> | wanderview: what does bz think? |
| 14:03 | <annevk> | wanderview: or jgraham? |
| 14:03 | <botie> | rumour has it jgraham is happy with that option |
| 14:03 | <annevk> | fascinating |
| 14:03 | <philipj> | annevk, smaug____, can you battle it about nullability of ClipboardEvent.clipboardData? |
| 14:03 | <annevk> | jgraham outsources his opinions to a bot |
| 14:03 | <annevk> | philipj: if we already shipped that, do it? |
| 14:03 | <annevk> | philipj: I don't care strongly |
| 14:04 | <wanderview> | annevk: I guess it depends what the purpose of RequestMode is... is it supposed to reflect the overall security policy for the request or is it really only there for service worker interception stuff? |
| 14:05 | <annevk> | wanderview: if you don't follow redirects automatically, its value is a whole lot less interesting |
| 14:05 | <annevk> | wanderview: unless we have some automated way of following redirects, where given a Request and Response you get a new Request |
| 14:06 | <wanderview> | annevk: let me ask you this... what motivated you to add RequestMode? |
| 14:06 | <philipj> | annevk: when will you be 30? |
| 14:06 | <annevk> | wanderview: I think someone asked if we could expose it to script |
| 14:07 | <annevk> | philipj: 363 days, unless it's one of those special years next, which I guess it might be? |
| 14:07 | <philipj> | annevk: so I guess happy recent birthday? |
| 14:07 | <annevk> | philipj: heh, yes |
| 14:08 | <annevk> | wanderview: the reason it exists at all is security decisions in Fetch of course, the reason it's exposed is mostly so you can ask for a policy in fetch() |
| 14:08 | <annevk> | wanderview: reflecting it on Request.prototype.mode was the next logical step |
| 14:12 | <wanderview> | annevk: are there other places its used besides Http Fetch step 2.2? |
| 14:15 | wanderview | looks |
| 14:16 | <annevk> | wanderview: yes, lots of places |
| 14:16 | <annevk> | wanderview: ah, the main reason actually that I didn't think "no-cors" made sense for navigate was that the response could never be opaque |
| 14:16 | <annevk> | wanderview: the response is always treated as same-origin |
| 14:17 | <annevk> | wanderview: so either you have some new kind of mode that doesn't cause the response to be masked, or you just always make same-origin requests to ever changing URLs... |
| 14:17 | <annevk> | sorry it took me a while to get to that |
| 14:18 | <wanderview> | annevk: I guess the main disconnect I am running into is that fetch expects new RequestMode values for redirects while gecko's security policy flag encompasses redirects (I think) |
| 14:19 | <annevk> | wanderview: I don't expect new values for redirects... |
| 14:19 | <wanderview> | annevk: new Request objects |
| 14:19 | <wanderview> | no? |
| 14:19 | <wanderview> | I thought thats what you said above |
| 14:19 | <annevk> | wanderview: I expect navigate to make new requests when its a redirect, since it doesn't follow them automatically |
| 14:19 | <annevk> | when it hits a redirect* |
| 14:21 | <annevk> | wanderview: I guess you're saying even for navigate we have some kind of callback all the way from Necko that navigate does something with before Necko follows the redirect? |
| 14:22 | <annevk> | wanderview: such a design seems somewhat distasteful... |
| 14:23 | <wanderview> | annevk: in gecko the docshell (window container thing) starts a network request... it then gets told when everything is done... the docshell checks the final URL on the network request to see if it ended up redirecting... all the redirects happen transparently in that single network request |
| 14:23 | <wanderview> | AIUI |
| 14:24 | <wanderview> | annevk: so we have the security policy settings that say "allow cross-origin or require same-origin", etc... in this case navigations will get a cross-origin policy which conflicts with your vision of RequestMode |
| 14:24 | <wanderview> | this is the only conflict between our security policy and RequestMode as far as I can tell |
| 14:26 | <annevk> | wanderview: I don't understand what it means for a navigation to have a cross-origin policy |
| 14:26 | <wanderview> | annevk: allow a cross-origin redirect |
| 14:27 | <wanderview> | cross-origin as defined by your original navigation URL |
| 14:27 | <annevk> | wanderview: but what does that mean for the response? |
| 14:27 | <annevk> | RequestMode is really about what kind of responses you allow |
| 14:27 | <annevk> | And "no-cors" allows opaque responses |
| 14:28 | <annevk> | And whenever you hit a redirect with navigation you need to do all kinds of things |
| 14:30 | <annevk> | wanderview: so either we make it "no-cors" and navigate needs to open up some opaque responses, but not others, ... |
| 14:30 | <annevk> | wanderview: or we keep it same-origin and each navigate attempt is a newish fetch with some accumulated state |
| 14:31 | <annevk> | wanderview: it's not entirely clear to me how the "no-cors" processing model would work |
| 14:31 | <wanderview> | annevk: our network stack is modeled differently from the fetch spec... makes it really hard to reason about the two |
| 14:32 | <annevk> | wanderview: say I navigate to http://example.com/redirect and end up at http://crossorigin.example/ |
| 14:32 | <annevk> | wanderview: that second will become an opaque response if mode is "no-cors" |
| 14:32 | <annevk> | wanderview: it's not clear to me how we can allow that while disallowing arbitrary opaque responses |
| 14:32 | <annevk> | wanderview: though I guess we could compare the request and response URL or some such... |
| 14:33 | <annevk> | wanderview: that's why I suggested involving bz and maybe jgraham who have some experience with navigation and might know what's best |
| 14:33 | <wanderview> | annevk: isn't that exactly what we are saying behavior should be, though... the browser follows redirects on navigation even cross-origin... but we don't want a service worker to do an opaque cross-origin interception |
| 14:33 | <wanderview> | annevk: bz is on pto |
| 14:33 | <wanderview> | we could ask sicking |
| 14:33 | <annevk> | wanderview: the browser doesn't follow redirects automatically though |
| 14:33 | <wanderview> | when CA wakes up |
| 14:34 | <annevk> | wanderview: navigate does all kinds of things with the response before even deciding to go to the network again |
| 14:34 | <wanderview> | annevk: are you saying some redirects are not permitted? |
| 14:35 | <annevk> | wanderview: some redirects result in skype or some such |
| 14:35 | <annevk> | wanderview: for navigate |
| 14:35 | <annevk> | wanderview: whereas in fetch that would end up as a network error |
| 14:36 | <wanderview> | annevk: does fetch permit the case of clicking on a google link that goes to google and then redirects to the actual search result? |
| 14:37 | <annevk> | sure, the navigate algorithm is priveliged code |
| 14:37 | <annevk> | this is not Fetch, mind you, this is HTML |
| 14:37 | <annevk> | Fetch has nothing to do with navigate |
| 14:38 | <annevk> | it only supports not following redirects for it |
| 14:38 | wanderview | is thoroughly confused now. |
| 14:38 | <annevk> | as navigate is the only consumer that needs that |
| 14:38 | <annevk> | (though there's some API support for it added to fetch() too now) |
| 14:38 | <wanderview> | I'll just special case navigations to force same-origin RequestMode for now |
| 14:39 | <annevk> | wanderview: something else to consider, a navigate would never result in a service worker seeing a request for a cross-origin URL |
| 14:39 | <wanderview> | annevk: I think some of the confusion is coming from there being no rules for how to actually set RequestMode |
| 14:39 | <annevk> | wanderview: it will always be a request for a same-origin URL |
| 14:39 | <annevk> | wanderview: what do you mean, no rules? |
| 14:39 | <wanderview> | annevk: ok... so its really just ServiceWorkerRequestMode? |
| 14:39 | <annevk> | no :-/ |
| 14:41 | <wanderview> | annevk: how do I as a browser implementer determine what to set RequestMode to for any given Request? obviously confusion here since Chrome also sets navigations to no-cors |
| 14:41 | <annevk> | wanderview: oh you mean no specification |
| 14:41 | <annevk> | wanderview: yeah that is unfortunate |
| 14:42 | <annevk> | we'll get it fixed, will just take a bit more time |
| 14:42 | <wanderview> | annevk: no specification and it seems your expectations are not matching what has been shipped |
| 14:42 | <wanderview> | which suggests there is a disconnect somewhere |
| 14:42 | <annevk> | Well service workers have been implemented as a hack on top of existing code, so that much is pretty clear... |
| 14:43 | <annevk> | I'd be happy to discuss this with mattto et al though |
| 14:44 | <wanderview> | annevk: for now I will just match the current spec... which involves basically doing the "if navigation for same-origin mode" since that mode value doesn't match gecko's internal concept |
| 14:45 | <wanderview> | annevk: it seems the only other same-origin Requests will be worker scripts and xmldocument.load()? |
| 14:45 | <annevk> | wanderview: <track> when you don't specify crossorigin |
| 14:46 | <wanderview> | annevk: I looked at track and it appears to use CORS... where does it define same-origin? |
| 14:46 | <annevk> | wanderview: it says potentially CORS |
| 14:47 | <wanderview> | annevk: step 8 here says "No CORS" https://html.spec.whatwg.org/multipage/embedded-content.html#start-the-track-processing-model |
| 14:47 | <annevk> | wanderview: yeah, but that combination means "same-origin" |
| 14:47 | <annevk> | wanderview: because "default origin behaviour set to fail" |
| 14:48 | <wanderview> | ok, thanks |
| 14:48 | <wanderview> | that was.... non-obvious |
| 14:49 | <annevk> | yeah, rewrite coming up within some months |
| 14:52 | <annevk> | philipj: I'll try to give you a definition tomorrow for elements and attributes |
| 14:52 | <annevk> | philipj: bit tired |
| 14:54 | <philipj> | annevk: No problem, happy to help measure if it'd answer any questions. |
| 14:58 | <hsivonen> | smaug____: pong |
| 15:08 | <smaug____> | hsivonen: did I ping? |
| 15:09 | <smaug____> | and if I did, I have no idea what I was going to ask |
| 15:09 | <hsivonen> | smaug____: ok. the ping was pretty old (a couple of weeks) |
| 15:09 | <smaug____> | :) |
| 15:11 | <jgraham> | SimonSapin: hsivonen is around |
| 15:12 | <annevk> | (this is why you shouldn't ping, ask a question...) |
| 15:12 | <SimonSapin> | thanks jgraham |
| 15:12 | <Workshiva> | But the channel was pretty quiet anyway, so there's also the entertainment value to consider |
| 15:13 | <SimonSapin> | hsivonen: Do you know if there is a way around keeping unbounded amount of input in memory in case the parser decides to "change the encoding", when parsing HTML from bytes? |
| 15:14 | <hsivonen> | SimonSapin: there intentionally is not supposed to be one |
| 15:14 | <SimonSapin> | and, to test if browsers do it, are you aware of a case where "prescan a byte stream to determine its encoding" would fail to find an encoding when given 1024 bytes, but tree construction would still "change the encoding" based on a meta start tag in the first 1024 bytes? |
| 15:16 | <SimonSapin> | hsivonen: intentionally? Why? |
| 15:19 | <hsivonen> | SimonSapin: to answer the previous question: after the 1024-byte boundary, the parser instance commits to one encoding. However, a late meta or a Japanese/Russian/Ukrainian detector can still trigger a reload with a different encoding |
| 15:20 | <hsivonen> | SimonSapin: in which case a new parser instance starts a new parse |
| 15:20 | <SimonSapin> | hsivonen: I’m trying to decide what to do in html5ever, which doesn’t necessarily have a notion of reload |
| 15:21 | <hsivonen> | SimonSapin: IIRC, WebKit/Blink doesn't support late <meta> triggering a reload. I don't know if they do it for their Japanese detection |
| 15:22 | <hsivonen> | SimonSapin: as for "intentionally", the intention of the 1024-byte boundary is precisely to make sure that the parser doesn't keep buffering forever and not produce any output |
| 15:22 | <hsivonen> | SimonSapin: I suggest committing to an encoding at the latest when you've seen 1024 bytes |
| 15:23 | <hsivonen> | SimonSapin: I can't recall why I implemented the late <meta> thing in the new parser |
| 15:23 | <hsivonen> | SimonSapin: initially, I make the detectors see at most 1024 bytes so that they couldn't trigger a reload |
| 15:23 | <hsivonen> | SimonSapin: but that broke Japanese Planet Debian |
| 15:23 | <hsivonen> | SimonSapin: and people get really nervous if you break a Japanese site |
| 15:24 | <hsivonen> | so... |
| 15:24 | <hsivonen> | Japanese Planet Debian has since been fixed |
| 15:25 | <hsivonen> | it's quite possible that we could get rid of the Russian and Ukrainian detectors and limit the Japanese detector to 1024 bytes and the sky wouldn't fall |
| 15:25 | <SimonSapin> | hsivonen: I see, thanks. So only run the byte-based prescanner, or can tree construction find meta tags that the pre-scanner doesn’t? |
| 15:26 | <SimonSapin> | hsivonen: I’m referring to https://html.spec.whatwg.org/multipage/#parsing-main-inhead:change-the-encoding |
| 15:26 | <hsivonen> | SimonSapin: I suggest only running the prescanner. (but I bet it's possible to construct something that the prescanner doesn't see but the tree builder sees) |
| 15:27 | <annevk> | hsivonen: WebKit only has a Japanese detector iirc |
| 15:27 | <hsivonen> | SimonSapin: oh. the reason I added support for late <meta> may be that the spec said so! |
| 15:27 | <hsivonen> | SimonSapin: but IIRC, WebKit doesn't honor the spec there |
| 15:27 | <annevk> | we should fix the spec |
| 15:28 | <hsivonen> | SimonSapin: it quite possible that the spec says so because the old parser in Gecko behaved like that |
| 15:28 | <hsivonen> | SimonSapin: I'm not sure what IE did at the time the spec was written, but my vague recollection is that it supported late <meta> |
| 15:30 | <hsivonen> | hmm. an obvious way to create a <meta> seen by the tree builder but not by the prescanner is, of course, document.write |
| 15:30 | <jgraham> | This wasn't one of the cases where Hixie was concerned about the security impact of an attacker that could cause early termination of the byte stream? |
| 15:30 | <hsivonen> | jgraham: I don't recall this topic co-occurring with that topic |
| 15:31 | jgraham | isn't quite sure what such an attack would look like given incremental parsing |
| 15:31 | <hsivonen> | jgraham: that was about comments and scripts |
| 15:32 | <jgraham> | OK |
| 15:32 | <MikeSmith> | annevk: so about bugzilla, short answer is Yes, we can. I think. |
| 15:32 | <hsivonen> | SimonSapin: so I suggest 1) implementing just the prescan until 1024 bytes, 2) being aware that you might end up having to implement something that allows you to signal to the browsing context to reload if #1 Breaks the Web, 3) researching if old IE actually supports late <meta> and if it doesn't, filing a spec bug |
| 15:33 | <hsivonen> | it's possible that a spec bug is warranted just based on the success of WebKit, though |
| 15:33 | <SimonSapin> | hsivonen: Chrome doesn’t reaload, it switches encodings mid-stream: https://gist.github.com/anonymous/addad9f51781a6cd2cf9 |
| 15:33 | <SimonSapin> | Firefox reloads |
| 15:33 | <hsivonen> | SimonSapin: whoa! |
| 15:34 | <SimonSapin> | Firefox makes two HTTP requests |
| 15:34 | <MikeSmith> | annevk: In the admin UI for components, every component has a "Enabled For Bugs" which by default is enabled; I think the scope of the effect of disabling is that it just prevents anybody from creating new bugs in that component, but you can still comment on existing bugs and edit them. I think. |
| 15:34 | <hsivonen> | SimonSapin: Firefox making two requests is expected |
| 15:34 | <hsivonen> | SimonSapin: the Chrome behavior is news to me |
| 15:35 | <SimonSapin> | Chrome 46 dev, don’t have Release at hand |
| 15:37 | <MikeSmith> | beverloo: on Android, "new Notification(...)" intentionally no longer works in Chrome, right? (from 42 on? or 43?) |
| 15:37 | <hsivonen> | annevk: my current assumption is that the Russian and Ukrainian detectors misfiring is a greater problem than the problems they fix, but I don't have proof |
| 15:38 | <beverloo> | MikeSmith, yup |
| 15:38 | <MikeSmith> | k |
| 15:38 | <beverloo> | MikeSmith, we shipped it in Chrome 42 on Android |
| 15:38 | <beverloo> | MikeSmith, we'll support it eventually, but they'll be more like Android toasts |
| 15:38 | <beverloo> | have to figure out the right ux :) |
| 15:38 | <hsivonen> | annevk: I want to get rid of those two detectors but I feel I need something more concrete than a guess that they have negative utility |
| 15:39 | <annevk> | MikeSmith: that sounds good to me |
| 15:40 | <annevk> | SimonSapin: it changes the decoder on the fly? |
| 15:40 | <MikeSmith> | beverloo: what's there now seems to fairly well already. I mean was far as how the notifications get displayed in the status area, and what's shown if you pull down to view more |
| 15:40 | <annevk> | SimonSapin: now that is interesting |
| 15:41 | <MikeSmith> | annevk: OK, so shall I go ahead and disable "Enabled For Bugs" for all WHATWG components except "Unwelcome"? |
| 15:41 | <beverloo> | MikeSmith, yes, but there's lifetime issues with that (the OS can kill the page whenever it feels like it). That's why the spec now mentions they're a more ephemeral form of notifications |
| 15:41 | <annevk> | MikeSmith: they're still welcome for the HTML components too |
| 15:41 | <annevk> | MikeSmith: for the time being |
| 15:42 | <MikeSmith> | annevk: ah yeah ok, sure |
| 15:42 | <MikeSmith> | beverloo: oh, ok |
| 15:42 | <annevk> | MikeSmith: oh, Books and Figures too |
| 15:42 | <annevk> | MikeSmith: howcome hasn't switched it seems |
| 15:43 | <MikeSmith> | annevk: yeah, those I figured to leave as is |
| 15:43 | <MikeSmith> | beverloo: was there an intent-to-deprecate message sent out to blink-dev about de-supporting the Notification constructor? |
| 15:43 | <annevk> | MikeSmith: seems mimesniff hasn't migrated either |
| 15:43 | <annevk> | GPHemsley: ^^ |
| 15:44 | <beverloo> | MikeSmith, we still support it on desktop (but are considering changing UX there too, part of a larger "what do we want with notifications"-effort) |
| 15:44 | <annevk> | MikeSmith: neither has HTML Differences |
| 15:44 | <beverloo> | I sent a PSA, let me find a link for you |
| 15:44 | <annevk> | MikeSmith: hmm, perhaps I can better list what we should disable :-/ |
| 15:44 | <beverloo> | MikeSmith, https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BygptYClroM |
| 15:44 | <MikeSmith> | annevk: OK, for now, so I just did only Encoding, Fetch, and URL |
| 15:44 | <annevk> | MikeSmith: to disable: JavaScript, URL |
| 15:45 | <MikeSmith> | beverloo: thanks |
| 15:45 | <MikeSmith> | annevk: ok just did JavaScript too |
| 15:45 | <beverloo> | MikeSmith, up for a drink later this week btw? :) |
| 15:45 | <beverloo> | would be good to meet you |
| 15:45 | <MikeSmith> | whoah |
| 15:45 | <MikeSmith> | beverloo: you in Tokyo? |
| 15:45 | <beverloo> | flying on Wednesday |
| 15:46 | <annevk> | MikeSmith: Quirks Mode lists a very old URL in its description |
| 15:46 | <MikeSmith> | annevk: what should it be? |
| 15:46 | <annevk> | MikeSmith: https://quirks.spec.whatwg.org/ |
| 15:47 | <MikeSmith> | beverloo: oh man, on Thursday morning I'm flying to Shanghai for a few days. Do you arrive in Tokyo on Wednesday or Thursday? |
| 15:48 | <MikeSmith> | annevk: OK, updated |
| 15:48 | <annevk> | thanks |
| 15:48 | <beverloo> | MikeSmith, Thursday morning at Haneda (7:20am) |
| 15:49 | <MikeSmith> | beverloo: OK I think I fly from Haneda on Thursday at 1pm :( |
| 15:50 | <MikeSmith> | beverloo: but will be back in the evening on the 9th (sunday), so could meet up then |
| 15:54 | <Ms2ger> | Clearly the two of you should meet for drinks at the airport |
| 15:55 | <MikeSmith> | heh |
| 16:11 | <MikeSmith> | annevk: oh, Firefox on Android is going to continue supporting the old-style Notification constructor? |
| 16:12 | <MikeSmith> | per your comment at https://github.com/whatwg/notifications/issues/26#issuecomment-126310459 |
| 16:12 | <annevk> | MikeSmith: non-persistent notifications are toasts, just a different name |
| 16:12 | <annevk> | MikeSmith: also, I'm not familiar with Firefox' product plans |
| 16:14 | <MikeSmith> | ah I see, the "we" in "we're keeping non-persistent notifications" was about the spec itself |
| 16:15 | <annevk> | MikeSmith: yeah, WHATWG-we |
| 16:15 | <MikeSmith> | k |
| 16:16 | <annevk> | MikeSmith: I guess that's confusing, unless it's clear from context, I believe I usually make it quite clear when I speak of Mozilla or its products |
| 16:16 | <annevk> | but unless* |
| 16:16 | annevk | goes to look at the HTML parser |
| 16:46 | <annevk> | Domenic: see recent post on blink-dev, making createElement() match the HTML parser seems hard |
| 16:47 | <Domenic> | annevk: I didn't really understand that post. |
| 16:47 | <Domenic> | It seemed to contradict itself a couple times? Incompatible, but a full subset? |
| 16:49 | annevk | refers back to him being tired |
| 16:49 | <annevk> | Domenic: there's a distinction between requirements on the first code point and any remaining code points |
| 16:50 | <Domenic> | I guess I am not able to find an actual example of incompatibility in that message |
| 16:51 | <Domenic> | Maybe... HTML does not allow a start of xEFFFF, but XML does? |
| 16:51 | <Domenic> | It seems fine if createElement allows more characters than the parser does |
| 16:52 | <annevk> | Domenic: HTML only allows a-zA-Z at the start of an element |
| 16:52 | <Domenic> | annevk: OK. Why is that a problem? |
| 16:53 | <annevk> | Domenic: XML and createElement() allow more, per the production I pointed too |
| 16:53 | <Domenic> | annevk: again, why is that a problem. |
| 16:53 | <annevk> | Domenic: if you make createElement() a superset of both, you're suddenly allowing in new elements your code base might not have considered |
| 16:54 | <Domenic> | what elements? |
| 16:54 | <Domenic> | what is an example? |
| 16:54 | <Domenic> | it seems like any example could be either created by the parser or by createElement, so nothing new is happening. |
| 16:54 | <annevk> | Domenic: ":>" |
| 16:55 | <annevk> | Domenic: that cannot be created by the parser or by createElement() today |
| 16:55 | <annevk> | sorry |
| 16:55 | <Domenic> | annevk: then don't allow it. nobody is asking for *new* elements |
| 16:55 | <annevk> | Domenic: ":<" |
| 16:56 | <annevk> | Domenic: well either you restrict per the HTML parser or you restrict per XML |
| 16:56 | <annevk> | Domenic: HTML parser has restrictions on the first code point |
| 16:56 | <Domenic> | annevk: the proposal is very simple. allow a union of both. |
| 16:56 | <annevk> | Domenic: if you open those up, you automatically allow more and allow things that cannot be done through XML |
| 16:56 | <Domenic> | annevk: start char = union of (what xml allows) + (what HTML allows) = what XML allows |
| 16:56 | <annevk> | Domenic: so making it more complex? |
| 16:56 | <annevk> | Domenic: I guess... |
| 16:56 | <Domenic> | annevk: rest of chars = union of (what xml allows) + (what HTML allows) |
| 16:57 | <annevk> | well, you'd need to validate either or in that case |
| 16:57 | <Domenic> | yep |
| 16:57 | <annevk> | if the first char is a non-HTML char remaining cannot be HTML char |
| 16:57 | <Domenic> | there's something on the platform that is creating elements and following these rules |
| 16:57 | <annevk> | the internals might not actually care about the names I suspect |
| 16:57 | <Domenic> | then we should expose that |
| 16:58 | <Domenic> | saying that the platform can create elements you can't is the silly part people are against |
| 16:58 | <annevk> | though it's a bit trickier with XML namespaces of course |
| 16:58 | <annevk> | but that's namespaced elements and those likely have their own path anyway |
| 16:58 | <Domenic> | :-S |
| 17:03 | <TabAtkins> | annevk: I'll check it out, thanks. |
| 17:04 | <annevk> | TabAtkins: thanks, it seems we also haven't quite figured out references yet |
| 17:04 | <TabAtkins> | ? |
| 17:04 | <TabAtkins> | Oh, biblio stuff |
| 17:04 | <annevk> | TabAtkins: yeah, DOM still has SELECTORS4 and SELECTORS-4 whereas I just want SELECTORS |
| 17:05 | <TabAtkins> | Yeah, I need to finish working on deduping that. I've done *some* deduping. |
| 17:05 | <annevk> | TabAtkins: editor's drafts have dates listed next to them too |
| 17:06 | <annevk> | TabAtkins: also, it seems syntax for dated references doesn't work? https://dom.spec.whatwg.org/#informative for UIEVENTS is quite wrong |
| 17:06 | <TabAtkins> | Hm, there's no syntax for them, it's just another ref name. I'll see what's up. |
| 17:07 | <annevk> | But perhaps DOM stating it supersedes them is no longer necessary either... At some point that's just the new normal. |
| 17:13 | <TabAtkins> | annevk: Looks like URL's not in Shepherd's database, which is why that link didn't work. ^_^ Tell me which WHATWG specs are bikeshedded and I'll add them. |
| 17:45 | <littledan> | annevk, thanks for the suggestion, that makes more sense actually. Trivial proposal writeup at http://littledan.github.io/global.html |
| 17:48 | <Domenic> | littledan: probably want to explain that this is then either shadowed by or in conflict with HTML's `self`, which is a getter |
| 17:49 | <littledan> | oh, it's readonly? I see |
| 17:49 | <littledan> | yeah, we definitely can't make it readonly, due to SES, but shadowed makes sense to me |
| 17:49 | <littledan> | that's annoying |
| 17:50 | <Domenic> | littledan: not readonly. a getter. |
| 17:50 | <Domenic> | { get, configurable: true, enumerable: true } instead of { writable: true, configurable: true, enumerable: false } |
| 17:50 | <littledan> | looks like the IDL for Window says readonly, which translates into a getter in ES, right? |
| 17:50 | <Domenic> | right. |
| 17:50 | <Domenic> | and all IDL attributes are enumerable true |
| 17:51 | <littledan> | oh, interesting |
| 17:51 | <littledan> | doesn't that make enumerability pretty limited utility? |
| 17:51 | <Domenic> | note also that globals are special-cased and their getters/methods are on the instance, not the prototype. otherwise, if this was a normal IDL object, you'd have another mismatch |
| 17:51 | <Domenic> | yes. yes it does. |
| 17:52 | <littledan> | oh, well if it were on the prototype, then it'd just be shadowed and that's fine |
| 17:52 | <Domenic> | yeah, but it's not |
| 17:52 | <littledan> | you're allowed to have a writable thing shadow something |
| 17:52 | <Domenic> | i think it's just a conflict |
| 17:52 | <Domenic> | one or the other spec would have to change |
| 17:53 | <littledan> | yeah, OK, so in spec-land, the DOM is written on top of the new ES realm after all of the ES primordials are set |
| 17:53 | <littledan> | right? |
| 17:53 | <Domenic> | i guess. there's never really been a conflict of this sort where the ordering needed to be established. |
| 17:53 | <littledan> | so if I just say, in a note, this is occurring, then that's enough |
| 17:53 | <littledan> | well, the ES spec is pretty explicit about how a realm is established and then stuff is written to it imperatively |
| 17:53 | <Domenic> | right, but that stuff doesn't reflect reality, it's just allen's imagination |
| 17:54 | <Domenic> | similar to "jobs" |
| 17:54 | <littledan> | do you think this will be a difficult thing to do in implementations? |
| 17:54 | <Domenic> | i am really not sure (i.e. i would bet either way with 50% probability) |
| 17:54 | <littledan> | to have them make it a writable configurable property in, basically, their shell? |
| 17:55 | <Domenic> | engines can do it, but then what does an engine's IDL binding do when a global object IDL attribute has to override an existing property? |
| 17:55 | <Domenic> | depends on what APIs are used to implement the IDL binding layer |
| 17:55 | <Domenic> | It's solvable, but might require writing custom bindings. |
| 17:55 | <Domenic> | It would be better to hope that we can change `self` from a getter to a data property so that it isn't defined by HTML at all. |
| 17:56 | <littledan> | so the question is, would it be better for HTML to make it a writable/configurable data property, or can we figure out if SES can accept it in its current for (which I guess it would have to to make it work on the current web) |
| 18:03 | <Domenic> | I think if it is web-compatible the best approach would be to move self to ES as a writable/configurable data property. |
| 18:04 | <Domenic> | however, experimenting with that sounds like a decent amount of implementation work, and the potential to break websites, for very little benefit. |
| 18:04 | <Domenic> | so i am not sure that the best approach will end up happening. |
| 18:05 | <Domenic> | alternate approaches include: figuring out if SES can live with `self` as a configurable, enumerable getter, and trying to move that to ES; or going for `global` to avoid such issues. |
| 18:09 | <littledan> | OK, this whole thing sounds like too little benefit for me to pursue |
| 18:10 | <littledan> | maybe we should just suggest to Node people to add 'self' in some way or another to make things easier for library authors |
| 18:10 | <littledan> | or the problem just doesn't exist at all |
| 18:11 | <Domenic> | yeah the cost/benefit tradeoff is indeed quite high |
| 18:12 | <Domenic> | that is why this has not happened yet :) |
| 18:13 | <littledan> | OK, I'm new, I'm still learning this stuff |
| 18:13 | <Domenic> | :) all good! |
| 21:36 | <Domenic> | TabAtkins: I am trying to write a spec with bikeshed and <pre class="idl">... MediaStream ... </pre> and it is complaining that "No 'idl-name' refs found for 'MediaStream'" |
| 21:36 | <Domenic> | I've searched a lot of docs and haven't found how to tell it where to get MediaStream |
| 21:39 | <TabAtkins> | Domenic: https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#providing-custom-definitions |
| 21:42 | <Domenic> | TabAtkins: thanks. I guess I have to use url if I want to avoid lowercasing? |
| 21:43 | <TabAtkins> | Yeah, if you use text it auto-gens the url based on Bikeshed's normal id-generation rules. If your target doesn't conform to that, supply url manually. (You can still combine with urlPrefix; url is appended to the urlPrefix.) |
| 22:19 | <Domenic> | TabAtkins: any ideas on how I can make a <h4> into a definition for an IDL thingy without nesting a <dfn> inside it (which gets its own auto-generated id etc.)? |
| 22:20 | <TabAtkins> | Domenic: Don't? |
| 22:20 | <Domenic> | TabAtkins: that is literally all of the streams spec |
| 22:20 | <TabAtkins> | (That is to say, there is nothing in Bikeshed that supports that, and I don't really plan to make it.) |
| 22:20 | <Domenic> | methods and getters and constructors are all defined as headings |
| 22:20 | <Domenic> | all of ES too |
| 22:21 | <TabAtkins> | So what's wrong with getting a different heading? You'll get one formatted properly for IDL stuff, after all. |
| 22:21 | <TabAtkins> | Well, those are abstract ops, not IDL. Hm. |
| 22:21 | <Domenic> | I don't understand the question. What's wrong with <h4><dfn> is that then I get dfn styles and two IDs (one for hte h4 and one for hte dfn) |
| 22:21 | <Domenic> | No, all the public API is done the same way. |
| 22:22 | <TabAtkins> | Styling is trivially fixable, obviously. Two ids isn't, tho. |
| 22:22 | <Domenic> | I also get two self-link <a>s, a consequence of the double-IDs. Super-ugly. |
| 22:22 | <TabAtkins> | Yeah, that's definitely ugly. |
| 22:22 | <TabAtkins> | Okay, file a bug on me, I'll think about it. |
| 22:22 | <Domenic> | thanks |
| 22:28 | <jgraham> | jsbell: I was hoping that someone who had looked at those tests before would review, but if they haven't I'll look tomorrow |
| 22:55 | <jsbell> | jgraham: thx |