is not. I understand why, but still would be very very good, if there was indeed a safe way to embed and escape it. [10:51:41.0000] Preferably a way that doesn't involve CDATA but maybe that's the only way? [11:38:29.0000] Krinkle: Correct, there's no way to generically escape JS in a (Extra-hard mode: the / can come from a regex. The expression `x-block. [11:41:42.0000] ) [12:03:18.0000] eval(atob('YWxlcnQoImhlbGxvIik=')) ... and I would have gotten away with it to except for those pesky kids and their CSP. [12:03:37.0000] s/pesky/meddling/, *sigh* [13:02:14.0000] 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 to parse without errors; [16:28:42.0000] 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 element. Otherwise it kept interpreting it as HTML. [16:31:44.0000] Krinkle: Yup, but then you pay the penalty that you *can't* write a bare < in your script without cdata. [16:34:08.0000] (and if you use cdata, you run into the same difficulty as with avoiding TabAtkins: Yeah - https://github.com/wikimedia/mediawiki/blob/1.30.0/includes/Html.php#L594-L612 [16:34:57.0000] For CSS we somewhat found a workaround for that. [16:35:00.0000] But not for JS really [16:35:26.0000] CDATA syntax is rare enough that it hasn't bitten us yet in the subset of scripts that can end up embedded [16:36:14.0000] The end glyphs for cdata are even more reasonable to show up in a realistic script, imo. Just a ]]> [16:36:22.0000] 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. [16:36:39.0000] That's just a double-array access with a comparison. [16:37:28.0000] Right, but that's only a problem in XML mode, right? [16:40:12.0000] From a quick test, having a seems to work fine [16:40:14.0000] in HTML mode [16:40:23.0000] despite containing a literal ]]> [16:41:09.0000] Not sure why/how that works. 2018-05-18 [18:37:50.0000] TabAtkins: Any current estimate of when you might be able to do the thing of extracting the syntax-highlighting stuff from Bikeshed so that we can use it for the HTML spec? [19:58:04.0000] MikeSmith: Ah dang, that's like 80% finished, I just dropped it. I'll get it done next week for you. [20:32:40.0000] TabAtkins: \o/ [20:32:44.0000] thanks! [00:10:56.0000] annevk: re:https://github.com/w3c/web-platform-tests/pull/10594#issuecomment-390116038, it would be nice if we could write down what folks think `from-origin` means. The github thread is confusing, and seems to be moving in a direction that doesn't match what's in WebKit at the moment. [00:11:23.0000] Is that on your plate? Or Apple's? Or do we need to find a volunteer? :) [00:11:29.0000] mkwst: so WebKit folks would get back to my suggestion I think [00:11:53.0000] mkwst: I think making From-Origin the CORB opt-in makes the most sense and would be the easiest to adopt [00:13:01.0000] mkwst: so I guess it's on Apple's plate and perhaps also on Google and Microsoft's plate to evaluate my input and give their perspective [00:13:29.0000] I worry a bit that further narrowing `from-origin`'s impact makes it even less likely that folks would serve it. [00:13:46.0000] I also worry about some Google security folks' feedback regarding deployability. [00:14:10.0000] mkwst: this makes it much easier to deploy as it only affects cross-origin no-cors fetches [00:14:38.0000] mkwst: it also helps as a long term defense when everyone has site isolation [00:15:57.0000] annevk: Less risky, certainly. *shrug* I'm happy for folks to ship implementations of this to see if developers pick it up. My suspicion is that we'll end up seeing more value in approaches with broader scope, but this is small enough that shipping it doesn't cost much. [00:16:41.0000] Whenever we tightly couple stuff it seems it's less likely to be adopted because it requires changing all the things [00:17:02.0000] annevk: When you say that it should be part of CORB, do you mean it would be another way of triggering the blocking behavior? Or that it would influence the heuristics, similarly to `x-content-type-options`? [00:17:24.0000] mkwst: another way of triggering a block [00:18:26.0000] Ok. So, the idea is that you'd compare the resource's origin to the requesting origin (without consideration of embedding contexts, etc), and block if there's no match? [00:18:33.0000] (for cross-origin, no-cors requests) [00:18:53.0000] Yes [00:19:41.0000] Ok. I'll try to summarize my understanding of the thing on the thread. [00:20:42.0000] And now we landed CORB in Fetch this would be a fairly trivial PR. I volunteered doing the work on it [00:21:47.0000] /me read "CORB in French" and was very confused [00:23:16.0000] Ms2ger: "Blocage de lecture inter-origine" [01:16:51.0000] hi all, does whatwg.org have a CSS spec? [01:17:51.0000] michael2: there's two CSS-related ideas we host, but they're not living standards: https://idea.whatwg.org/ [01:18:00.0000] michael2: they're also not really maintained as far as I'm aware [01:19:07.0000] so would I need to browse w3c.org to find the CSS spec's? (1,2,3+) [01:20:59.0000] michael2: I'd use https://drafts.csswg.org/ [01:21:15.0000] michael2: those are also the documents the WHATWG links to [01:21:50.0000] michael2: they're probably mostly identical to what ends up on w3.org, but might be a bit more recently updated [01:22:46.0000] annevk: thats really helpful (alot of reading there) thank you :) [01:53:19.0000] annevk: is something in particular blocking [Cached] in idl? If so we could instead add something to infra like "Return the cached result of these steps" [01:54:18.0000] JakeA: IDL is lacking resources [01:54:29.0000] JakeA: I don't think anything is blocking that work [01:56:14.0000] JakeA: it could maybe work in Infra; I guess it could create a unique slot on this and store the result of running the steps there if it's empty and otherwise return the value of the unique slot [01:56:34.0000] JakeA: though I guess creating the unique slot is the problem, but we could hand-wave it perhaps [01:57:38.0000] annevk: The context object could have a map, where the key is the steps and the value is the cached value. But I'm not sure how to decide if it'd be better as an idl thing or a prose thing [02:01:22.0000] JakeA: IDL is somewhat better as just like it can generate the spec code for us, it can generate the impl code too [02:01:39.0000] JakeA: e.g., Firefox supports a variant of Cached already iirc [02:01:51.0000] Gotcha. Yeah that makes sense [02:32:14.0000] annevk: It seems like subresource requests from an don't inherit the frame's referrer policy in Chrome/FF. Want to confirm with you that the rp should be inherited, due to steps in Main Fetch that use a request's client's referrer, right? [02:34:42.0000] domfarolino: looking at it now, I'm not sure there's actually anything that takes that referrerpolicy attribute value and installs it on the loaded document or its global [02:35:00.0000] domfarolino: it seems to be just used for the load triggered by src="" [02:36:42.0000] annevk: Hmm, but don't we set request's client to a node doc's Window's environment settings object when fetching things like etc? [02:36:55.0000] And since environ settings obj has a referrer policy, Main Fetch should "inherit" it? [02:37:17.0000] domfarolino: yes [02:37:37.0000] domfarolino: but the referrer policy of the environment settings object of a thing loaded in an