| 01:05 | <jhiesey> | @Domenic: am i right in thinking that encodingOverride doesn't actually do anything yet in https://github.com/jsdom/whatwg-url ? |
| 01:05 | <jhiesey> | in general, how finished is https://url.spec.whatwg.org/ and are there any complete reference implementations? |
| 01:08 | <jhiesey> | @Sebmaster: ^ |
| 01:12 | <MikeSmith> | jhiesey: https://url.spec.whatwg.org/ intends to be finished and has browser implementations that conform |
| 01:12 | <MikeSmith> | annevk would be the person to ask for more details |
| 01:13 | <MikeSmith> | and fwiw there is java implementation at https://github.com/smola/galimatias that was written from scratch to match the requirements in teh spec |
| 01:14 | <Sebmaster> | jhiesey: yeah, encodingOverride isn't actually implemented |
| 01:14 | <Sebmaster> | I'm not sure it actually matters because it produce queryParams yet, which is the only point where it's used if i remember correctly |
| 01:17 | <Sebmaster> | s/because it produce/because it doesn't produce/ |
| 01:33 | <boogyman> | Is anyone here familiar with multipart streams? Forwarding on an inquiry from another channel "can one file be split between two parts of the same multipart stream" |
| 03:44 | <annevk> | Sebmaster: you need it for correctly parsing the query state |
| 03:45 | <annevk> | Sebmaster: URLSearchParams doesn't really use it |
| 07:34 | <mkwst> | annevk: If I add crytographic nonce metadata to requests, would you like me to expose it via Request/RequestInit? (re: https://github.com/whatwg/fetch/issues/269) |
| 07:34 | <annevk> | mkwst: is there a use case? |
| 07:35 | <mkwst> | Beyond "explain the platform", I don't have one. |
| 07:35 | <annevk> | mkwst: probably not for v0 then |
| 07:35 | <annevk> | mkwst: it's rather tied to the CSP header, no? |
| 07:36 | <mkwst> | annevk: Yes. I don't know of anything else using the `nonce` attribute for anything. |
| 07:36 | <annevk> | mkwst: that is, at the moment you also can't fake type or destination |
| 07:36 | <annevk> | mkwst: so if nonce only works when type is script, it doesn't add much value |
| 07:36 | <annevk> | mkwst: you might want to add nonce support to workers though... |
| 07:36 | <mkwst> | annevk: style too. |
| 07:37 | <mkwst> | https://github.com/w3c/webappsec-csp/issues/15 <-- worker nonces. |
| 07:38 | <annevk> | Seems Nadoedalo is ahead of the curve |
| 07:38 | <mkwst> | it's not tough to be ahead of me... |
| 07:39 | <mkwst> | Do you happen to know how the HTML bits of xref work? |
| 07:39 | <mkwst> | Do I just run `html.py` to regenerate the json files? |
| 07:40 | <annevk> | mkwst: you need to update html.json unfortunately |
| 07:40 | <annevk> | mkwst: and then run html.py |
| 07:40 | <mkwst> | um. ok? what does html.py do, then? |
| 07:41 | <annevk> | mkwst: cleanup and multipage references |
| 07:42 | <annevk> | mkwst: so you don't need to stick to alphabetical order when inserting stuff in html.json |
| 07:42 | <mkwst> | Ok. Well, it's throwing exceptions. :) |
| 07:42 | <Ms2ger> | Is that still being used? |
| 07:43 | <mkwst> | Will you be terribly sad if I just add references without running html.py? :) |
| 07:45 | <annevk> | Ms2ger: yeah |
| 07:45 | <annevk> | mkwst: I guess I can try to fix it |
| 07:46 | <Ms2ger> | You could try to argue this is all my code, I suppose |
| 07:49 | <annevk> | I'm mostly stuck with it since bikeshed has these odd things |
| 07:50 | <annevk> | I guess I should really try to get bikeshed not to do the things I dislike, that's probably more productive |
| 07:57 | <zcorpan> | annevk: HTMLHyperlinkElementUtils doesn't provide a searchParams getter? is that intentional? |
| 07:57 | <annevk> | zcorpan: yeah |
| 07:57 | <zcorpan> | annevk: ok. what was the rationale? |
| 07:57 | <annevk> | zcorpan: since it can't work for Location and WorkerLocation it seemed better to just have it for URL |
| 07:58 | <annevk> | zcorpan: minor post-decision-reason could be that <a> and <area> use an override encoding and URL doesn't |
| 07:59 | <annevk> | zcorpan: and that URLSearchParams always uses utf-8 |
| 07:59 | <zcorpan> | ok thanks |
| 08:06 | <annevk> | mkwst: so for https://github.com/whatwg/fetch/pull/273 you didn't update xref at all? |
| 08:06 | <annevk> | mkwst: or it wasn't needed? |
| 08:07 | <mkwst> | I updated it locally, and apparently didn't send a PR. 2 seconds. |
| 08:08 | <mkwst> | https://github.com/whatwg/xref/pull/11 |
| 08:20 | <annevk> | mkwst: wasn't sure whether https://github.com/whatwg/fetch/issues/269 should be closed, will leave that to you |
| 08:20 | <mkwst> | Probably not. It needs an HTML patch I'm writing now. |
| 08:20 | <mkwst> | And a CSP patch, but that's less relevant to Fetch. |
| 08:23 | <annevk> | GitHub is super slow? |
| 08:31 | <alrra> | annevk: yes (see: https://status.github.com/messages) |
| 08:36 | <annevk> | ta |
| 08:36 | <annevk> | TabAtkins: so I got conflicts now for "origin" |
| 08:36 | <annevk> | TabAtkins: then I use "spec" as suggested to disambiguate |
| 08:36 | <annevk> | TabAtkins: but by default "spec" just picks the first <dfn> in HTML, even it says noexport! |
| 08:37 | <annevk> | TabAtkins: that's somewhat absurd, no? |
| 08:51 | <mkwst> | zcorpan: Where's the best place to submit PRs for CSSOM? :) |
| 08:51 | <mkwst> | Just file something at https://www.w3.org/Bugs/Public/buglist.cgi?component=CSSOM&list_id=62622&product=CSS&resolution=--- ? |
| 09:00 | <zcorpan_> | mkwst: https://github.com/w3c/csswg-drafts/ - but create a fork, branches on this repo don't work because of the hg sync |
| 09:01 | <mkwst> | zcorpan_: Thanks! |
| 09:02 | mkwst | waits an hour for GitHub to catch up. :/ |
| 09:08 | MikeSmith | lights his peace pipe and enjoys an early-evening break |
| 09:14 | <mkwst> | zcorpan_: If you have a moment, can you help me understand how "fetch a CSS style sheet" relates to "create a CSS style sheet"? |
| 09:14 | <mkwst> | The latter has data I want to use in the former (namely the "owner node" of the sheet). |
| 09:15 | <mkwst> | "create" is called from HTML. |
| 09:15 | <mkwst> | "fetch" doesn't seem to be called at all. |
| 09:16 | <zcorpan_> | mkwst: https://github.com/whatwg/html/issues/968 |
| 09:17 | <zcorpan_> | mkwst: also i think several things in this area are currently broken, i haven't spent time yet to fix it |
| 09:19 | <mkwst> | Got it. Ok. Then I'll defer this PR a bit and file a bug for myself to come back to it. :) |
| 09:19 | <zcorpan_> | mkwst: happy to allocate time for this soon though and help with whatever you want to fix |
| 09:19 | <mkwst> | I know jochen__ wants clarity here for Referrer Policy, and it would be helpful for CSP and SRI, which both need to stuff things into Fetch for various checks. |
| 09:20 | <mkwst> | *shrug* Not the most important thing ever, but it would be nice to have a clear path from `<link>` in HTML through to Fetch for stylesheets. |
| 09:20 | <annevk> | Yeah, he's always reminding me how CSS doesn't have its act together |
| 09:20 | <annevk> | But note that fixing that would also requiring some deeper fixes, such as defining what `background-image` and such do |
| 09:20 | <mkwst> | Yup. Baby steps. |
| 09:21 | <annevk> | Yeah, it's only a two decade old feature |
| 09:22 | <annevk> | Would be a bit soon for it to be properly defined |
| 09:22 | <mkwst> | Fetch isn't two decades old. :) |
| 09:22 | <annevk> | mkwst: background-image is |
| 09:22 | <mkwst> | I see. |
| 09:23 | <zcorpan_> | 1) Here's a URL. 2) ??? 3) It works!! |
| 09:23 | <annevk> | Also, I think I could argue that parts of Fetch maybe are that old |
| 09:23 | <Ms2ger> | zcorpan_, hey, you know if attr() case-sensitivity is specced? |
| 09:24 | <zcorpan_> | Ms2ger: what aspect of it? |
| 09:24 | <annevk> | E.g., the redirect behavior has existed since, well, browsers |
| 09:25 | <Ms2ger> | zcorpan_, something that says "it's case-insensitive in HTML documents, case-sensitive elsewhere" |
| 09:29 | <Ms2ger> | zcorpan_, will file on HTML, I guess |
| 09:29 | <zcorpan_> | Ms2ger: i don't find anything about that |
| 09:32 | <zcorpan_> | html http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4034 xhtml http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4035 |
| 09:33 | <Ms2ger> | Also http://test.csswg.org/suites/css21_dev/nightly-unstable/html4/content-attr-case-001.htm :) |
| 09:35 | <zcorpan_> | "The case-sensitivity of attribute names depends on the document language." says CSS 2.1 |
| 09:36 | <Ms2ger> | https://github.com/whatwg/html/issues/991 |
| 09:36 | <zcorpan_> | but no such text in https://drafts.csswg.org/css-values-3/#funcdef-attr |
| 09:40 | <Ms2ger> | I'd file an issue there, but they use Tracker |
| 09:40 | <Ms2ger> | And that's really not worth my time |
| 09:43 | <Ms2ger> | TabAtkins, ^ |
| 09:55 | <annevk> | squash and merge is very satisfying |
| 10:12 | <annevk> | mkwst: should the HTML parser hide nonce attributes? |
| 10:15 | <mkwst> | annevk: Why? |
| 10:15 | <annevk> | mkwst: probably not worth the complexity, but it reduces the risk of nonce being reused by an attacker |
| 10:16 | <mkwst> | An attacker could only gain access to the nonce if they had the ability to run script on the page though, right? |
| 10:16 | <mkwst> | At that point, it's not clear what we'd be defending against. |
| 10:16 | <annevk> | mkwst: sure, it's defense-in-depth, similar to your credential scheme |
| 10:17 | <annevk> | mkwst: e.g., it might prevent exfiltration |
| 10:19 | <mkwst> | annevk: File a bug? It's certainly worth considering, though I'm not sure the complexity is worth it. |
| 10:20 | <mkwst> | annevk: I've been thinking about something else that might be worth it, though: |
| 10:20 | <mkwst> | An issue that keeps coming up is injection of partial tags to capture attributes on subsequent tagfs. |
| 10:21 | <mkwst> | Like, an attacker injects `<script src='whatever'` just before a page writes `<script nonce='whatever' ...>`. |
| 10:21 | <mkwst> | Could we prevent script execution for script elements that contain an attribute named "<script"? |
| 10:22 | <annevk> | If it's web-compatible we could... |
| 10:23 | <mkwst> | I'm doing it in CSP (https://github.com/w3c/webappsec-csp/commit/2c92a09beeede27e45f2acef4041aa0a1770fa99), but I can't imagine there's any real use case. |
| 10:23 | <mkwst> | I guess I'll file a bug, add a use counter, and wait. :) |
| 10:23 | <annevk> | Yeah, that'd be a good approach |
| 10:24 | <annevk> | The cool alternative would be <script-[nonce]>, but that's not really backwards compatible |
| 10:24 | <annevk> | And you'd have </script-[nonce]> too of course |
| 10:24 | <mkwst> | Well, that's the next thing. :) |
| 10:25 | <annevk> | And the parser inserts <script> if [nonce] is good |
| 10:25 | <mkwst> | Since HTML isn't XML, how about we add `<tag closes-with='nonce'> ... </tag nonce>` :) |
| 10:25 | <annevk> | That'd be a lot more compatible, for sure |
| 10:26 | <annevk> | I have no objections, XML compat hasn't really done us any favors |
| 10:26 | <mkwst> | Hooray! Maybe I'll look at our HTML parser to see if this is at all implementable. |
| 10:27 | <annevk> | Attributes on the closing tag are definitely tokenized, but probably not along |
| 10:27 | <annevk> | passed along* |
| 12:36 | <annevk> | What's a good presentation framework these days? Other than Opera Presto which I can't really recommend anymore due to it not being maintained... |
| 12:36 | <annevk> | Anyone experience with https://github.com/hakimel/reveal.js? |
| 12:52 | ondras | has http://ondras.github.io/jsslides/v3/ |
| 12:52 | <ondras> | annevk: ^ |
| 14:30 | <annevk> | ondras: ta, none of these looks very simple, but maybe it's not a simple problem anymore |
| 14:30 | <annevk> | ondras: <style media=projection> was quite nice |
| 14:31 | <ondras> | depends on your definition of "simple" I guess |
| 14:32 | <ondras> | media=projection is nice but you often want to have this functionality without projection |
| 14:32 | <ondras> | and you want some interactivity not achievable with css |
| 14:32 | <ondras> | I have this pure-css variant: http://ondras.zarovi.cz/demos/nojs/ |
| 14:32 | <ondras> | but it is more of a hack |
| 14:33 | <ondras> | anyway, my jsslides is generally done by one additional <script src=...> node, sounds quite accessible to me |
| 14:33 | <ondras> | annevk: ^ |
| 16:47 | <Domenic> | Always so interesting when someone's only GitHub contribution is a reasonable, non-spammy spec bug: https://github.com/whatwg/dom/issues/203 |
| 16:51 | <jgraham> | Outside the filter bubble there are lots of technical people that never have occasion to use GitHub |
| 16:56 | <annevk> | Domenic: had not even noticed that |
| 17:55 | <TabAtkins> | Ms2ger: We do not, in fact, use Tracker for anything; I'll go fix that spec to stop lying. |
| 17:55 | <Ms2ger> | That's nice, I guess |
| 17:56 | <TabAtkins> | And yeah, you're right, we should ref the "CI defined by the host language". |
| 17:56 | <Ms2ger> | zcorpan also sent email |
| 18:43 | <TabAtkins> | Cool |
| 18:45 | <TabAtkins> | annevk: (re spec and noexport) That's actually intended behavior. The entire point of noexport is to hide definitions *by default*, if they're not considered sufficiently useful to pollute the global namespace with. The spec argument's main purpose is to *override* that, indicating that no, you really do want to look inside of this spec for a definition, |
| 18:45 | <TabAtkins> | so that overrides noexport. |
| 18:46 | <TabAtkins> | If spec didn't do that, I'd have to invent a *further* indicator to mean "no, really, I don't care whether they're exported or not". |
| 18:47 | <Domenic> | then how do you indicate which spec you want to get the definition from, while still respecting noexport? |
| 18:47 | <TabAtkins> | You don't. |
| 18:47 | <TabAtkins> | There is no such indicator right now. Hasn't been needed. |
| 18:48 | <TabAtkins> | As long as a single spec's definition are well-formed (all distinguishable), you don't need it - you can just say "use this spec, and get me this particular definition". |
| 18:48 | <TabAtkins> | Which is possible in this case anyway - I don't know how correct it is, but the one exported HTML "origin" definition is for=origin |
| 18:48 | <Domenic> | I guess this comes back to the conflict where you think textContent is unique and we think IDs are unique |
| 18:49 | <TabAtkins> | While the other three aren't for anything. (They're not well-formed per Bikeshed's model, but as long as you're not trying to link them that doesn't matter.) |
| 18:50 | <TabAtkins> | I mean, IDs are unique, yes. But they're also arbitrary strings that require extra memorization to use, and should be left to automation to generate anyway. They're a tool of the underlying tech, not really intended for usability at the authoring layer. |
| 18:50 | <Domenic> | I disagree, probably because of the years of using <a href="#id"> |
| 18:51 | <TabAtkins> | Yeah, if you've already got calluses over the parts of your brain that remember IDs, it doesn't feel like it's a problem. |
| 18:53 | <Domenic> | I mean, it'd only be used for the disambiguation cases where the textContent is not unique |
| 18:54 | <TabAtkins> | Bikeshedded specs already enforce that case as a fatal error; this is only for the handful of specs that (a) want to be in the cross-spec-linking db, and (b) don't want to play by the rules of that db. |
| 18:54 | <TabAtkins> | There's only a handful of those, and they can be fixed over time. Blessing their behavior isn't great for the ecosystem. |
| 18:56 | <Domenic> | I pretty strongly disagree that unique text content is necessary for being a good citizen of the ecosystem |
| 18:56 | <Domenic> | but, it's not my db |
| 18:56 | <TabAtkins> | Good thing it's not! |
| 18:56 | <Domenic> | ouch |
| 18:56 | <TabAtkins> | Ugh, collision. |
| 18:57 | <TabAtkins> | Was responding to the *previous* line. |
| 18:57 | <TabAtkins> | You have to be a unique {linking text, type, for, spec} value. Which is a very low bar to meet. |
| 18:58 | <TabAtkins> | (Being unique on {linking text, type, for} is *nice*, but not required. When I finally implement support for obsoletion, it'll be easier.) |
| 19:04 | <TabAtkins> | That all said, my error message *does* explicitly say to insert "spec:html; type:dfn; text:origin" into link defaults, which would not be sufficient here. I should improve that. |
| 19:05 | <Domenic> | I guess this all sounds reasonable; we'll see if I run into problems again and have more specific complaints |
| 19:06 | <Domenic> | Somewhat-relatedly, we should talk about what we can do to HTML to make it a good citizen for cross-spec links. Add more data- attributes, mainly? Especially export, but also some type-related ones---e.g. get it to mark up the IDL somehow? |
| 19:07 | <TabAtkins> | I think the for=origin on that value is wrong. It's actually the core "origin" definition, all by its lonesome; it should be the only one *without* a for='' value. The other three should get for=request, for=url, and for=http, or something like that. |
| 19:07 | <TabAtkins> | I *think* plinss's parser handles IDL reasonably well automatically, but I'll have to check. Otherwise, yeah, it's just a matter of honoring the anchor contract <https://github.com/tabatkins/bikeshed/blob/master/docs/dfn-contract.md>; |
| 19:08 | <Domenic> | I can't believe we've been putting data-noexport on all our <dfn>s like chumps, so silly |
| 19:09 | <TabAtkins> | A lot of them *do* need it. HTML is *not* defining the url origin, for example. |
| 19:09 | <Domenic> | but dfn is noexport by default, I thought? |
| 19:09 | <TabAtkins> | Oh yeah, right, that's true. |
| 20:53 | <jyasskin> | TabAtkins: While I was looking at BT's HTML use, I noticed that I have to define anchors for https://www.w3.org/2001/tag/doc/promises-guide and https://heycam.github.io/webidl/. Can you add those to shepherd? (I'll still have to define link-defaults for those, but that's preferable) |
| 20:57 | <jyasskin> | Domenic: Note that https://www.w3.org/2001/tag/doc/promises-guide#resolve-promise has link-text "Resolve p with x", which doesn't work at all in other specs. I'm using just "Resolve" in Bluetooth. |
| 20:57 | <Domenic> | jyasskin: yeah I should probably fix that |
| 20:59 | <TabAtkins> | jyasskin: Promises Guide is already in there. |
| 20:59 | <TabAtkins> | WebIDL isn't Bikeshed-friendly. Dunno what results we'd get if we put it in. |
| 21:00 | <jyasskin> | Thanks. I bet I searched for the wrong thing. WebIDL would have results like HTML, right? |
| 21:00 | <TabAtkins> | Yeah, approximately. |
| 21:00 | <jyasskin> | That's better than nothing. |
| 21:06 | <TabAtkins> | Hmmmmm, there's only 225 definitions. It shouldn't be too hard to just add the right attrs to WebIDL. |
| 21:06 | <TabAtkins> | Gimme an hour. |
| 21:16 | <Domenic> | Just Bikeshed it ;) |
| 21:16 | <Domenic> | Ms2ger or nox started such a project IIRc |
| 21:17 | <TabAtkins> | Bikeshedding it would be a lot more work. ^_^ I can at least make it *friendly* easily. |
| 21:17 | <TabAtkins> | And yeah, I recall someone starting a Bikeshedding, but I guess they lost interest; haven't heard anything about it in a while. |
| 21:18 | <nox> | Domenic: I would like to do it but I have other things to do and I've been told there are some licensing issue to take care of or whatever. |
| 21:19 | <Domenic> | but the XSLT ;_; |
| 21:22 | <TabAtkins> | Eh, who cares, data-* attributes still work I'm pretty sure. |
| 21:22 | <TabAtkins> | But also: licensing??!? |
| 22:19 | <nox> | TabAtkins: You would have to look into this very channel's logs, because I don't remember. |
| 22:23 | <Domenic> | It does seem like Web IDL is currently under the "no derivative works allowed" copyright. |
| 22:32 | <TabAtkins> | Right, but that doesn't stop it from *switching* to another processor. |
| 23:26 | <TabAtkins> | Wooo https://github.com/heycam/webidl/pull/105 |
| 23:31 | <heycam> | TabAtkins: thank you! |
| 23:32 | <TabAtkins> | Welcome! Hope it works and everything's kosher! |
| 23:33 | <heycam> | TabAtkins: unfortunately no, since it's XML those data-* attributes need an ="" |
| 23:33 | <TabAtkins> | Ah, kk, gimme a sec |
| 23:33 | <TabAtkins> | I thought of that early, but forgot by the time I was writing things. |
| 23:34 | <TabAtkins> | k, done |
| 23:35 | heycam | tries |
| 23:35 | <heycam> | TabAtkins: https://pastebin.mozilla.org/8866534 |
| 23:36 | <TabAtkins> | Holy crap, what possible reason could XML have for disallowing < in attr values? |
| 23:36 | heycam | started Bikeshedification (as did Ms2ger), which he should get back to completing |
| 23:37 | <TabAtkins> | And done. |
| 23:38 | <heycam> | TabAtkins: success :) |
| 23:38 | <TabAtkins> | yus |
| 23:39 | heycam | brb will land in a min |