| 01:02 | <domfarolino> | Domenic: what is the benefit of having the ‘crossOrigin’ IDL attribute nullable? |
| 01:13 | <Domenic> | domfarolino: it allows removing the content attribute by setting the IDL atrribute to nill. |
| 03:37 | <devsnek> | does w3c have an irc channel besides the dead irc server |
| 03:50 | <joyee> | Domenic: is the "last script tag of WPT are tests" a convention? I am thinking about putting the tests that apply to browsers in a previous script tag, and tests that can be run by Node.js to the last tag, so it will be easier to automate any WPT updates in Node.js |
| 03:51 | <Domenic> | joyee: I don't think people would generally accept tests that don't run in browsers into the WPT project |
| 03:51 | <joyee> | Domenic: I mean to split the test cases into script tags |
| 03:52 | <joyee> | multiple tags |
| 03:52 | <joyee> | In general WPT is a superset |
| 03:52 | <Domenic> | ah i see |
| 03:52 | <joyee> | And we can update the union that can be run in both in the last script tag |
| 03:53 | <Domenic> | That should work fine, although it'd need heavy commenting to hopefully prevent people from messing it up over time, since most contributors (including CI) won't be aware of this division |
| 03:53 | <Domenic> | Like, most contributors have no idea what works or doesn't work in Node.js |
| 03:54 | <joyee> | I think right now only the URL tests are kept somewhat in sync |
| 03:55 | <joyee> | I've been told that browsers can automatically upstream their tests into WPT, so I am thinking about doing the same thing in Node.js, but it would be tricky to comment out stuff that don't work in browsers |
| 03:55 | <Domenic> | My understanding is right now the URL tests are maintained for browsers but other projects like node or jsdom will do their own stuff with those files |
| 03:55 | <Domenic> | Oh interesting |
| 03:55 | <joyee> | The blocking part is finding a way to denote the union of two sets |
| 03:57 | <Domenic> | I mean separate script tags will work for now I'm just saying that future contributors might not understand the division and put stuff in the "wrong" script tags (since for browsers both script tags will work). |
| 03:58 | <Domenic> | If you were able to divide by file and API that'd work better e.g. isolate all URL constructor tests into one file and insist that all future URL constructor tests also go there |
| 04:01 | <joyee> | Domenic: isn't that `url-constructor.html` is? Or that name just implies "the the constructor is tested here", not that "all constructor tests go here" |
| 04:02 | <Domenic> | I think the former, e.g. failure.html tests the constructor too I believe. |
| 04:02 | <Domenic> | I'm curious what file you're looking at right now that is mixed? |
| 04:04 | <joyee> | For example, this one https://github.com/w3c/web-platform-tests/blob/master/url/toascii.window.js there is `XMLHttpRequest` |
| 04:04 | <joyee> | I was working on a tool to automatically update WPT in Node.js, but I found tests that were commented out |
| 04:05 | <joyee> | Technically we can run the tests in a vm with browser globals that are just noops but it may not be enough |
| 04:07 | <joyee> | Basically grepping for `//` in `test/parallel/test-whatwg-url-*` would yield the results (with legit comments) |
| 04:12 | <joyee> | Domenic: I can work on splitting the tests that can't be run in Node.js into different files in WPT first as well, and focus on automating the process of updating tests that work into Node.js. If any updates come back breaking Node.js, we can just fix it and update again |
| 04:16 | <Domenic> | Awesome, sounds pretty reasonable to me! We should also check with annevk, who should be waking up soon I think. |
| 04:18 | <joyee> | Great! Yeah now come to think of it, splitting into different files should make things simpler than splitting them into tags |
| 05:24 | <annevk> | joyee: wfm |
| 05:24 | <annevk> | joyee: note https://github.com/w3c/web-platform-tests/issues/10918 though |
| 05:30 | <joyee> | annevk: Thanks for the heads up. I don't think we have the two .js there since they involve `XMLHttpRequest` and `<a>`. The JSON fixtures are now manually being copy-pasted into our own fixtures directory with some comments added, I plan to move all the WPT files into a separate fixtures directory of the same layout in Node.js anyway so it should be fine. |
| 13:18 | <JakeA> | annevk: I'm having brain fade. How do I reference https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks in Bikeshed? Or is it not exported? |
| 13:18 | <JakeA> | The HTML spec's markup always trips me up |
| 13:20 | <JakeA> | Hm, it doesn't have data-export, so I guess I'm stuck. |
| 13:21 | <annevk> | JakeA: you can add data-export |
| 13:21 | <annevk> | JakeA: then it'll be exported tomorrow |
| 13:21 | <JakeA> | Ta, I'll do a PR |
| 13:22 | <annevk> | JakeA: given that the processing model is a bit broken though I hope it's only for a non-normative dependency |
| 13:22 | <annevk> | JakeA: FYI, prefix commit with "Meta:" |
| 13:22 | <JakeA> | annevk: yeah, this is listing the types of APIs that make range-requests in a note |
| 13:22 | <JakeA> | ta |
| 13:33 | <JakeA> | annevk: A couple of parts of the fetch spec encode numbers to use as headers. What's the best way to encode a number for this purpose? https://heycam.github.io/webidl/#es-ByteString seems close, but feels wrong to use something like this in-parallel. |
| 13:36 | <annevk> | JakeA: "represented as shortest possible lowercase hexadecimal number" or "shortest possible decimal number" is what URL seems to use |
| 13:36 | <annevk> | JakeA: ideally Infra defines this, but that's blocked on the BigInt refactoring of JS |
| 13:37 | <annevk> | JakeA: what URL uses doesn't seem quite accurate, as it doesn't really explain what code points/bytes to use |
| 13:38 | <annevk> | JakeA: I'd be okay with a TODO and some hand-wavy wording for your Range patch |
| 13:38 | <JakeA> | annevk: I'll create the same definition as URL, along with a note |
| 13:40 | <wanderview> | JakeA: I wonder how much more broken the UI would get if your download glitch demo also piped through a service worker |
| 13:41 | <wanderview> | since the SW layer forces the transfer encoding to be stripped from the stream... maybe it would actually work better |
| 13:41 | <JakeA> | wanderview: it might not be any worse. Hah, yeah, probably better. |
| 13:42 | <JakeA> | wanderview: unless it gets angry that it gets more data than the content-length |
| 13:42 | <JakeA> | but it feels like that would be a problem elsewhere |
| 13:42 | <wanderview> | JakeA: yea, we already had to deal with that for normal service worker behavior with encoded resources |
| 13:42 | <wanderview> | basically a big shruggy for the content-length |
| 13:43 | <wanderview> | JakeA: probably a can of worms to sort out when fetch progress API is added |
| 14:00 | <annevk> | Domenic: some review on the WIP PRs against html/html-build/wattsi would be helpful |
| 14:01 | <annevk> | Domenic: I think they're almost ready to go, after which HTML would finally have slightly annotated commits |
| 17:49 | <Krinkle> | Hm.. does this really not have an outcome today? https://stackoverflow.com/a/34545749/319266 |
| 17:50 | <Krinkle> | E.g. a safe way to generically escape and embed a JS response in an inline <script> on a HTML5 text/html response |
| 17:50 | <Krinkle> | It surprised me that generically html-text escaping a script worked fine for evil event attributes, but not for inline scripts. |
| 17:51 | <Krinkle> | e.g. <script>var a = ""</script> is a syntax error but <div onclick="alert("")"> is not. I understand why, but still would be very very good, if there was indeed a safe way to embed and escape it. |
| 17:51 | <Krinkle> | Preferably a way that doesn't involve CDATA but maybe that's the only way? |
| 18:38 | <TabAtkins> | Krinkle: Correct, there's no way to generically escape JS in a <script> tag without doing full JS parsing on your own, so you can find </script subsequences in strings/etc. No one-size-fits-all replacement method exists. |
| 18:41 | <TabAtkins> | (Extra-hard mode: the / can come from a regex. The expression `x</script/.exec(...)` is both valid and potentially sensical, but it trigger end-of-<script>-block. |
| 18:41 | <TabAtkins> | ) |
| 19:03 | <jsbell> | eval(atob('YWxlcnQoImhlbGxvIik=')) ... and I would have gotten away with it to except for those pesky kids and their CSP. |
| 19:03 | <jsbell> | s/pesky/meddling/, *sigh* |
| 20:02 | <TabAtkins> | jsbell: Not trying to prevent XSS here, just be able to splice in a script from server-side without the possibility of it accidentally closing the <script> element partway thru. |
| 21:51 | <jugglinmike> | I'm seeing Chrome behaving inconsistently when setting `font-family` to a web font |
| 21:52 | <jugglinmike> | Sometimes the change is apparent synchronously, and sometimes not |
| 21:53 | <jugglinmike> | I'm trying to find the relevant spec text, but I don't know where to look |
| 21:53 | <jugglinmike> | the closest I've come is https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements |
| 21:53 | <jugglinmike> | but that's not quite right, since it's not phrased in terms of the JavaScript execution context |
| 21:55 | <TabAtkins> | As in, the layout effects of the new font might be async? |
| 22:07 | <jugglinmike> | TabAtkins: yeah. They normally are |
| 22:11 | <jugglinmike> | Still experimenting, but this may be related to the @font-face definition as well |
| 23:18 | <Krinkle> | TabAtkins: Aye, yeah. it's unfortunate, given that in most other areas, HTML escaping does not affect the code's function. E.g. things like attribute values such as for <a href> can redundantly use entities for any characters like < and it gets decoded before being interpreted as URL, but it seems that for <script> that isn't the case. |
| 23:19 | <Krinkle> | Although some sources on the web suggest that HTML escaping is supported in <script> if and only if the document is in XML mode. |
| 23:19 | <Krinkle> | E.g. that would allow <script>if ( 0 < 5 ) {}</script> to parse without errors; |
| 23:28 | <Krinkle> | Ha, indeed. I'm able to get it to work in an isolated test by using 'Content-Type: application/xhtml+xml' although at least in Chrome it only worked if I also added the xmlns attribute to the <html> element. Otherwise it kept interpreting it as HTML. |
| 23:31 | <TabAtkins> | Krinkle: Yup, but then you pay the penalty that you *can't* write a bare < in your script without cdata. |
| 23:34 | <TabAtkins> | (and if you use cdata, you run into the same difficulty as with avoiding </script) |
| 23:34 | <Krinkle> | TabAtkins: Yeah - https://github.com/wikimedia/mediawiki/blob/1.30.0/includes/Html.php#L594-L612 |
| 23:34 | <Krinkle> | For CSS we somewhat found a workaround for that. |
| 23:35 | <Krinkle> | But not for JS really |
| 23:35 | <Krinkle> | CDATA syntax is rare enough that it hasn't bitten us yet in the subset of scripts that can end up embedded |
| 23:36 | <TabAtkins> | The end glyphs for cdata are even more reasonable to show up in a realistic script, imo. Just a ]]> |
| 23:36 | <Krinkle> | XML mode support has been removed from MediaWiki in a previous version. It used to be a site configuration option for admins, but it was too troublesome to guruantee and just in general the idea of supporting two modes. We ended up going with HTML5. |
| 23:36 | <TabAtkins> | That's just a double-array access with a comparison. |
| 23:37 | <Krinkle> | Right, but that's only a problem in XML mode, right? |
| 23:40 | <Krinkle> | From a quick test, having a <script>/*<![CDATA[*/ if ( ''[''[0]]>0 ) {} console.log(1);/*]]>*/</script> seems to work fine |
| 23:40 | <Krinkle> | in HTML mode |
| 23:40 | <Krinkle> | despite containing a literal ]]> |
| 23:41 | <Krinkle> | Not sure why/how that works. |