| 01:24 | <cantom> | When WHATWG recommends URL over URI, does that mean the specification is just for URLs, and they don't pay attention to URIs, or does it mean that they prefer everything is called URLs. |
| 01:30 | <cantom> | ? |
| 01:30 | <tantek> | what is the difference between URL and URI to you? |
| 02:19 | <cantom> | tantek: to me? |
| 02:19 | <cantom> | tantek: whatever you tell me :P |
| 02:19 | <cantom> | tantek: I do understand the difference, but I'm curious what's the official position of WHATWG |
| 02:23 | <TimothyGu> | cantom: everything should be called URLs |
| 02:23 | <TimothyGu> | cantom: "Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest." |
| 02:24 | <TimothyGu> | https://url.spec.whatwg.org/#goals |
| 02:27 | <cantom> | TimothyGu: Thanks, thing is I quoted this exact sentence to someone and they're adamant that this means "because browsers mostly need URLs they focus on URLs, and use the same parser for URLs and URIs, doesn't mean they call all URIs URLs" |
| 02:28 | <TimothyGu> | cantom: uh well, that's exactly what it says "Standardize on the term URL" |
| 02:28 | <cantom> | TimothyGu: another thing "this is just how WHATWG deals with it internally, it doesn't mean they want anyone else not calling it URIs" |
| 02:29 | <cantom> | TimothyGu: I know but... Sigh. |
| 02:29 | <cantom> | TimothyGu: thanks. |
| 02:30 | <TimothyGu> | this is written in a STANDARD, not a W3C working group note or TAG guide. those latter things are "internal", but standards are public standards |
| 02:30 | <TimothyGu> | well, WG-NOTE isn't really internal |
| 02:31 | <cantom> | TimothyGu: BTW what this guy says aside, it's interesting to me that it says "this standard obsoletes the IETF RFCs" |
| 02:31 | <cantom> | TimothyGu: it's curious to me how one organization obsoletes the standards of another ;-) |
| 02:33 | <cantom> | TML, I asked Timothy Gu and Tantek Çelik, and they said this is a published standard that intends to obsolete the IETF RFCs that call it URIs, and so they want everyone to use the URLs term for all link schemes. |
| 02:33 | <cantom> | Oops |
| 02:33 | <cantom> | Wrong place. |
| 02:46 | <TimothyGu> | cantom: btw I don't really consider the RFCs *fully* obsoleted, just their normative requirements |
| 02:47 | <cantom> | TimothyGu: all right :) thanks |
| 02:47 | <TimothyGu> | they still have some information that's helpful, like explanations of each fields of a URL |
| 02:48 | <cantom> | TimothyGu: last question, is there a good test suite for URL parsing WHATWG provides (or someone)? |
| 02:48 | <TimothyGu> | yep |
| 02:48 | <TimothyGu> | https://github.com/w3c/web-platform-tests/tree/master/url |
| 02:48 | <cantom> | Thanks!! |
| 02:48 | <TimothyGu> | if you are only intersted in parsing: https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.json |
| 02:49 | <TimothyGu> | (the others test URL() APIs too |
| 02:50 | <cantom> | Beautiful, I'm so happy I asked, I was about to write this myself hehe (poorly) |
| 02:56 | <TimothyGu> | cantom: oh, in case you are implementing the parsing algorithm, there's an unofficial JS reference implementation at https://github.com/jsdom/whatwg-url |
| 02:57 | <TimothyGu> | and Node.js' implementation is kept up-to-date too, though it's written in C++: https://github.com/nodejs/node/blob/master/src/node_url.cc |
| 02:57 | <TimothyGu> | (grep for url::parse) |
| 02:58 | <cantom> | :D |
| 02:58 | <TimothyGu> | URL::Parse() |
| 09:59 | <tobie> | zcorpan: as a sidenote I'd prefer unlessViewed to notIfViewed |
| 10:36 | <zcorpan> | tobie: thx |
| 11:30 | <Ms2ger> | https://www.khronos.org/registry/webgl/specs/latest/2.0 is the very latest, right? |
| 11:31 | <gsnedders> | Ms2ger: well maybe something newer in the GitHub repo |
| 11:38 | <Ms2ger> | Ugh, apparently so |
| 11:38 | <gsnedders> | but idk if that actually reflects consensus in any real sense |
| 11:40 | <Ms2ger> | Well, does anything? |
| 11:41 | <Domenic> | Do we have a statement anywhere about how the web is supposed to be portable? E.g. how we don't generally expose hardware/OS capabilities directly and require feature testing to figure out what works, but instead we build a slightly higher-abstraction API that covers general situations |
| 11:42 | <Domenic> | Ms2ger: gsnedders: in my experience the delta from GitHub merge to publication was very low, possibly zero? |
| 11:43 | <annevk> | Domenic: https://www.w3.org/TR/html-design-principles/#media-independence |
| 11:44 | <Domenic> | That seems OKish I guess. It seems pretty small for something so foundational, and you have to squint to see how it would apply to e.g. the Notifications API |
| 11:45 | <Ms2ger> | Does chromium code search have blame? |
| 11:45 | <annevk> | Yeah, and media is a little different from platforms arguably... Maybe at some point we should redo that document and makes it apply more generally |
| 11:45 | <annevk> | And bring it back home to the WHATWG... |
| 11:51 | <gsnedders> | Ms2ger: under layers |
| 11:51 | <Ms2ger> | Thx |
| 11:52 | <Ms2ger> | > blink-reformat⊙co |
| 11:52 | <Ms2ger> | <.< |
| 11:52 | <Ms2ger> | >.> |
| 14:58 | <wanderview> | JakeA: service worker scripts can redirect same-origin, right? |
| 14:58 | <wanderview> | hmm, no... I guess it sets redirect mode to "error" |
| 15:05 | <JakeA> | yeah, errors |
| 15:06 | <wanderview> | JakeA: sorry, I should have checked the spec before pinging you |
| 15:06 | <JakeA> | np :D |
| 15:06 | <wanderview> | I wonder if we have a WPT for that |
| 15:42 | <wanderview> | well, at least both browsers prevent install when redirected: https://sw-script-redirect.glitch.me/ |
| 15:47 | <wanderview> | JakeA: but I guess imports can redirect |
| 15:48 | <JakeA> | wanderview: yeah, they can be cross-origin too |
| 15:59 | <wanderview> | JakeA: I'll add a WPT test for the importScripts() redirect... I don't think we test that today |
| 15:59 | <wanderview> | we had a bogus assertion that path was hitting |
| 16:06 | <wanderview> | JakeA: btw, I think we've made the call not to ship ReadableStream in FF57... doesn't look like the remaining issues will be fixed in time |
| 16:19 | <JakeA> | wanderview: more important for it to be right than early imo |
| 16:19 | <wanderview> | well, it definitely won't be "early" :-) |
| 16:28 | <JakeA> | In specs: If I'm going to resolve a promise with an object, say a Request, do I need to queue a task before creating that object? |
| 16:29 | <wanderview> | JakeA: are you already on the js thread? |
| 16:29 | <Mek> | JakeA: if you use the shorthands from https://www.w3.org/2001/tag/doc/promises-guide#shorthand-manipulating, then "If the algorithm using these shorthands is running in parallel, the shorthands queue a task on p’s relevant settings object’s responsible event loop to call the stored function." |
| 16:29 | <Mek> | but that doesn't help with creating the Request itself of course... |
| 16:30 | <Mek> | well, "resolve with a newly created X object" should be fine, while "1) create a new Request object, 2) resolve with that object" wouldn't |
| 16:30 | <Mek> | or maybe not |
| 16:33 | <JakeA> | Mek: Makes sense, cheers. I guess if I need two steps I could propose something like "Resolve p with the result of these steps:" |
| 17:56 | <jyasskin> | Did the delegatesFocus flag (mentioned in https://developers.google.com/web/fundamentals/architecture/building-components/shadowdom#focus but not in DOM) get replaced by anything, or is it just gone? |
| 18:06 | <jyasskin> | (I don't need to use it; I'm reviewing a spec that propagates it from one place to another.) |
| 19:57 | <jyasskin> | Has there been any movement on declaratively attaching a shadow tree to an element? Someone gave me a proposal to attach <template shadowmode="..."> as its parent's shadow root, but if there's another live proposal I'll encourage them to use that instead. |
| 19:57 | <jyasskin> | Domenic: ^? |
| 20:42 | <TabAtkins> | jyasskin: None yet, but I *really really really* want it. |
| 20:47 | <Domenic> | jyasskin: I think delegatesFocus is still in shadow DOM, not yet moved over. |
| 20:48 | <Domenic> | Declarative shadow DOM is just <script>el.attachShadow(...)</script> :) https://github.com/w3c/webcomponents/issues/657#issuecomment-324417136 |
| 20:48 | <TabAtkins> | Domenic: Boooooooo |
| 20:51 | <TabAtkins> | In particular, big "booooooo" because that breaks syntax highlighting, and doesn't work well with anything that expects to be able to output HTML. You can't include a <script> inside the shadow without remembering to do the string tricks to avoid a literal `</script>` showing up in the string. Etc. |
| 20:51 | <TabAtkins> | It's not a good answer. :( |
| 20:52 | <jarek> | What about allowing Shadow DOM on SVG elements? |
| 20:52 | <TabAtkins> | What about them? |
| 20:52 | <jarek> | This used to be in the v0 spec, but was removed in v1 |
| 20:53 | <jarek> | IMHO features that were previously implemented by user agents should have the highest priority |
| 20:53 | <TabAtkins> | The v0-to-v1 removals were mostly about getting something that Safari and others would actually implement. |
| 20:54 | <TabAtkins> | v0 was implemented a single user agent (Chrome), so the plural isn't accurate. ^_^ |
| 20:54 | <TabAtkins> | (That said, Shadow DOM should absolutely work on SVG.) |
| 20:54 | <jarek> | TabAtkins: Chrome, Opera, Electron, NW.js, the list goes on... |
| 20:54 | <TabAtkins> | Those aren't separate user agents for this purpose. |
| 20:54 | <TabAtkins> | They're all "things using Blink", which is what implemented it. |
| 20:56 | <jyasskin> | Domenic: https://w3c.github.io/webcomponents/spec/shadow/ is in really bad shape. For example, it refers to delegatesFocus without defining it. |
| 20:57 | <Domenic> | Indeed :( |
| 20:57 | <jarek> | So, are custom SVG elements a dead end like HTML imports? |
| 20:58 | <jyasskin> | Domenic: <script>el.attachShadow(...)</script> doesn't work in sandboxed code (which is how we handle MHTML), and doesn't seem like it'd play well with CSP either. |
| 20:58 | <Domenic> | Use nonces |
| 20:58 | <jyasskin> | Well, my real use case is MHTML, which disallows script, so ... |
| 20:58 | <TabAtkins> | Domenic: Deeper and deeper... |
| 21:00 | <TabAtkins> | "I'd like to just put this subtree into the shadow DOM for an element. / Use script, it's simple. / This causes X, Y, and Z problems. / Here's workarounds for each of those problems; oh yeah, and some of them require you to use crypto safely." |
| 21:00 | wanderview | notices work is more pleasant with the twitter tab closed. |
| 21:02 | <Domenic> | Wow, this is a bold proposed change... https://s.codepen.io/cssgrid/debug/50554e6ae6f9a57e5d566b73edcbca37 |
| 21:02 | <Domenic> | Maybe it is time to shake things up a bit though |
| 21:04 | <TabAtkins> | Oh gosh, I really like it to (everything except the GitHub font; it's jarring surrounded by the normal-text buttons around it). |
| 21:06 | <Domenic> | https://github.com/whatwg/whatwg.org/pull/90 for encouragement to the author :) |
| 21:10 | <inoas> | TabAtkins: would you say a declarative (markup) approach to creating shadow dom roots is missing? |
| 21:11 | <TabAtkins> | Yes, definitely. Something like what jyasskin said - `<div><template shadow-mode="open">...</template></div>` to add the template contents to the div as a shadow root would be great. |
| 21:12 | <inoas> | I am not nitpicky on the syntax but anything that is xhtml5-polyglot compatible and does not require a script block would be <3 |
| 21:13 | <inoas> | (or any other kind of inline js) |
| 21:13 | <jyasskin> | inoas: Why can't you use inline js? |
| 21:13 | <TabAtkins> | We long ago abandoned polyglot as a goal, so I dont' care about that, but yeah, inline scripting has so many frustrating downsides. |
| 21:13 | <TabAtkins> | jyasskin: *Can* use it isn't the question. *Want to* use it is, because of the reasons I gave above. |
| 21:14 | <inoas> | TabAtkins: well as long as you do not force people to use non-closing tags, stand-alone attributes its ok |
| 21:14 | <inoas> | we are still validating against xml wellformdness and it makes things lots easier |
| 21:14 | <inoas> | but thats beside the point, being tag based/declarative <3 |
| 21:15 | <jyasskin> | TabAtkins: That's enough for me, but the more "can't"s we can find, the more likely we are to convince Domenic and rniwa. |
| 21:16 | <inoas> | the reason for us is that we can use it for sand-boxing css and we can forbid javascript to certain users but allow shadow doms for css |
| 21:16 | <inoas> | (other users than can build javascript that attaches on the same shadow dom) |
| 21:17 | <jyasskin> | Do you forbid JS to some-authors-but-not-others with a build step or something the browser enforces? |
| 21:18 | <inoas> | different privileges in our software |
| 21:19 | <inoas> | writing to the database, building documents/assets off that |
| 21:20 | <jyasskin> | inoas: 'k, thanks. |
| 21:23 | <inoas> | jyasskin: what's your use case? |
| 21:29 | <jyasskin> | inoas: Chrome supports saving MHTML snapshots of loaded web pages, but because of historical bugs, when those snapshots are loaded, they're not allowed to run script. If the web page had some shadow dom, how do we serialize it? |
| 21:30 | <jyasskin> | https://crbug.com/330663 |
| 21:31 | <inoas> | so implementors using declarative shadow dom would allow serialization into mhtml snapshots? |
| 21:35 | <jyasskin> | inoas: Yeah, the implementation would write declarative shadow dom into the snapshot. This still works if we only allow declarative shadow dom during MHTML loads. |
| 22:17 | <TabAtkins> | jyasskin, inoas: https://github.com/whatwg/dom/issues/510 |
| 22:36 | <Domenic> | TabAtkins: nonces are not related to crypto |
| 22:36 | <TabAtkins> | It's 100% related to crypto? You have to send an unguessable nonce. |
| 22:36 | <jyasskin> | Yeah, although they're a security feature that's hard to get right. e.g. No static HTML page can safely include a nonce. |
| 22:37 | <jyasskin> | TabAtkins: There's no encryption involved. There's a random number generator, but that's easier than crypto. |
| 22:37 | <TabAtkins> | Okay, sure, you could just use randomness. |
| 22:38 | <TabAtkins> | But randomness is crypto. ^_^ |
| 22:41 | <TabAtkins> | But yeah, point is that authors can't reliably use nonces anyway (thus why Ian designed <iframe srcdoc> the way he did, rather than a <sandbox> element with nonces to mark the start/end), and they *require* server-side dynamic pages. |
| 22:44 | <MikeSmith> | TimothyGu: about https://github.com/whatwg/html/pull/3031 thing, thanks for caring enough about this (non-implementation-requirements) to take time to review and comment |
| 22:45 | <MikeSmith> | in hindsight, I realize your comment about “Nothing” being technically correct, that was spot on |
| 22:46 | <MikeSmith> | you were right, I was wrong to think we shouldn’t make it clear there (even for author/developer readers) |
| 22:47 | <MikeSmith> | it’s just messy to try figure out how to clearly explain the template case, as far as authoring/document-conformance requirements |
| 22:47 | <MikeSmith> | I mean, to explain it without making it even more complicated and confusing to read about |
| 22:49 | <MikeSmith> | it’s a pulling-threads case, where I find that the more details I consider including there, the more other explanation that requires pulling in |
| 22:49 | <MikeSmith> | anyway, I think (hope) we are getting close to the sweet spot, in the review iterations in https://github.com/whatwg/html/pull/3031 |