freenode :: #whatwg

12 Sep 2017
01:24cantomWhen 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:30tantekwhat is the difference between URL and URI to you?
02:19cantomtantek: to me?
02:19cantomtantek: whatever you tell me :P
02:19cantomtantek: I do understand the difference, but I'm curious what's the official position of WHATWG
02:23TimothyGucantom: everything should be called URLs
02:23TimothyGucantom: "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:27cantomTimothyGu: 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:28TimothyGucantom: uh well, that's exactly what it says "Standardize on the term URL"
02:28cantomTimothyGu: another thing "this is just how WHATWG deals with it internally, it doesn't mean they want anyone else not calling it URIs"
02:29cantomTimothyGu: I know but... Sigh.
02:29cantomTimothyGu: thanks.
02:30TimothyGuthis 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:30TimothyGuwell, WG-NOTE isn't really internal
02:31cantomTimothyGu: BTW what this guy says aside, it's interesting to me that it says "this standard obsoletes the IETF RFCs"
02:31cantomTimothyGu: it's curious to me how one organization obsoletes the standards of another ;-)
02:33cantomTML, 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:33cantomWrong place.
02:46TimothyGucantom: btw I don't really consider the RFCs *fully* obsoleted, just their normative requirements
02:47cantomTimothyGu: all right :) thanks
02:47TimothyGuthey still have some information that's helpful, like explanations of each fields of a URL
02:48cantomTimothyGu: last question, is there a good test suite for URL parsing WHATWG provides (or someone)?
02:48TimothyGuif you are only intersted in parsing:
02:49TimothyGu(the others test URL() APIs too
02:50cantomBeautiful, I'm so happy I asked, I was about to write this myself hehe (poorly)
02:56TimothyGucantom: oh, in case you are implementing the parsing algorithm, there's an unofficial JS reference implementation at
02:57TimothyGuand Node.js' implementation is kept up-to-date too, though it's written in C++:
02:57TimothyGu(grep for url::parse)
09:59tobiezcorpan: as a sidenote I'd prefer unlessViewed to notIfViewed
10:36zcorpantobie: thx
11:30Ms2ger is the very latest, right?
11:31gsneddersMs2ger: well maybe something newer in the GitHub repo
11:38Ms2gerUgh, apparently so
11:38gsneddersbut idk if that actually reflects consensus in any real sense
11:40Ms2gerWell, does anything?
11:41DomenicDo 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:42DomenicMs2ger: gsnedders: in my experience the delta from GitHub merge to publication was very low, possibly zero?
11:44DomenicThat 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:45Ms2gerDoes chromium code search have blame?
11:45annevkYeah, 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:45annevkAnd bring it back home to the WHATWG...
11:51gsneddersMs2ger: under layers
14:58wanderviewJakeA: service worker scripts can redirect same-origin, right?
14:58wanderviewhmm, no... I guess it sets redirect mode to &quot;error&quot;
15:05JakeAyeah, errors
15:06wanderviewJakeA: sorry, I should have checked the spec before pinging you
15:06JakeAnp :D
15:06wanderviewI wonder if we have a WPT for that
15:42wanderviewwell, at least both browsers prevent install when redirected:
15:47wanderviewJakeA: but I guess imports can redirect
15:48JakeAwanderview: yeah, they can be cross-origin too
15:59wanderviewJakeA: I&#39;ll add a WPT test for the importScripts() redirect... I don&#39;t think we test that today
15:59wanderviewwe had a bogus assertion that path was hitting
16:06wanderviewJakeA: btw, I think we&#39;ve made the call not to ship ReadableStream in FF57... doesn&#39;t look like the remaining issues will be fixed in time
16:19JakeAwanderview: more important for it to be right than early imo
16:19wanderviewwell, it definitely won&#39;t be &quot;early&quot; :-)
16:28JakeAIn specs: If I&#39;m going to resolve a promise with an object, say a Request, do I need to queue a task before creating that object?
16:29wanderviewJakeA: are you already on the js thread?
16:29MekJakeA: if you use the shorthands from, then &quot;If the algorithm using these shorthands is running in parallel, the shorthands queue a task on ps relevant settings objects responsible event loop to call the stored function.&quot;
16:29Mekbut that doesn&#39;t help with creating the Request itself of course...
16:30Mekwell, &quot;resolve with a newly created X object&quot; should be fine, while &quot;1) create a new Request object, 2) resolve with that object&quot; wouldn&#39;t
16:30Mekor maybe not
16:33JakeAMek: Makes sense, cheers. I guess if I need two steps I could propose something like &quot;Resolve p with the result of these steps:&quot;
17:56jyasskinDid the delegatesFocus flag (mentioned in but not in DOM) get replaced by anything, or is it just gone?
18:06jyasskin(I don&#39;t need to use it; I&#39;m reviewing a spec that propagates it from one place to another.)
19:57jyasskinHas there been any movement on declaratively attaching a shadow tree to an element? Someone gave me a proposal to attach <template shadowmode=&quot;...&quot;> as its parent&#39;s shadow root, but if there&#39;s another live proposal I&#39;ll encourage them to use that instead.
19:57jyasskinDomenic: ^?
20:42TabAtkinsjyasskin: None yet, but I *really really really* want it.
20:47Domenicjyasskin: I think delegatesFocus is still in shadow DOM, not yet moved over.
20:48DomenicDeclarative shadow DOM is just <script>el.attachShadow(...)</script> :)
20:48TabAtkinsDomenic: Boooooooo
20:51TabAtkinsIn particular, big &quot;booooooo&quot; because that breaks syntax highlighting, and doesn&#39;t work well with anything that expects to be able to output HTML. You can&#39;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:51TabAtkinsIt&#39;s not a good answer. :(
20:52jarekWhat about allowing Shadow DOM on SVG elements?
20:52TabAtkinsWhat about them?
20:52jarekThis used to be in the v0 spec, but was removed in v1
20:53jarekIMHO features that were previously implemented by user agents should have the highest priority
20:53TabAtkinsThe v0-to-v1 removals were mostly about getting something that Safari and others would actually implement.
20:54TabAtkinsv0 was implemented a single user agent (Chrome), so the plural isn&#39;t accurate. ^_^
20:54TabAtkins(That said, Shadow DOM should absolutely work on SVG.)
20:54jarekTabAtkins: Chrome, Opera, Electron, NW.js, the list goes on...
20:54TabAtkinsThose aren&#39;t separate user agents for this purpose.
20:54TabAtkinsThey&#39;re all &quot;things using Blink&quot;, which is what implemented it.
20:56jyasskinDomenic: is in really bad shape. For example, it refers to delegatesFocus without defining it.
20:57DomenicIndeed :(
20:57jarekSo, are custom SVG elements a dead end like HTML imports?
20:58jyasskinDomenic: <script>el.attachShadow(...)</script> doesn&#39;t work in sandboxed code (which is how we handle MHTML), and doesn&#39;t seem like it&#39;d play well with CSP either.
20:58DomenicUse nonces
20:58jyasskinWell, my real use case is MHTML, which disallows script, so ...
20:58TabAtkinsDomenic: Deeper and deeper...
21:00TabAtkins&quot;I&#39;d like to just put this subtree into the shadow DOM for an element. / Use script, it&#39;s simple. / This causes X, Y, and Z problems. / Here&#39;s workarounds for each of those problems; oh yeah, and some of them require you to use crypto safely.&quot;
21:00* wanderview notices work is more pleasant with the twitter tab closed.
21:02DomenicWow, this is a bold proposed change...
21:02DomenicMaybe it is time to shake things up a bit though
21:04TabAtkinsOh gosh, I really like it to (everything except the GitHub font; it&#39;s jarring surrounded by the normal-text buttons around it).
21:06Domenic for encouragement to the author :)
21:10inoasTabAtkins: would you say a declarative (markup) approach to creating shadow dom roots is missing?
21:11TabAtkinsYes, definitely. Something like what jyasskin said - `<div><template shadow-mode=&quot;open&quot;>...</template></div>` to add the template contents to the div as a shadow root would be great.
21:12inoasI am not nitpicky on the syntax but anything that is xhtml5-polyglot compatible and does not require a script block would be <3
21:13inoas(or any other kind of inline js)
21:13jyasskininoas: Why can&#39;t you use inline js?
21:13TabAtkinsWe long ago abandoned polyglot as a goal, so I dont&#39; care about that, but yeah, inline scripting has so many frustrating downsides.
21:13TabAtkinsjyasskin: *Can* use it isn&#39;t the question. *Want to* use it is, because of the reasons I gave above.
21:14inoasTabAtkins: well as long as you do not force people to use non-closing tags, stand-alone attributes its ok
21:14inoaswe are still validating against xml wellformdness and it makes things lots easier
21:14inoasbut thats beside the point, being tag based/declarative <3
21:15jyasskinTabAtkins: That&#39;s enough for me, but the more &quot;can&#39;t&quot;s we can find, the more likely we are to convince Domenic and rniwa.
21:16inoasthe 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:16inoas(other users than can build javascript that attaches on the same shadow dom)
21:17jyasskinDo you forbid JS to some-authors-but-not-others with a build step or something the browser enforces?
21:18inoasdifferent privileges in our software
21:19inoaswriting to the database, building documents/assets off that
21:20jyasskininoas: &#39;k, thanks.
21:23inoasjyasskin: what&#39;s your use case?
21:29jyasskininoas: Chrome supports saving MHTML snapshots of loaded web pages, but because of historical bugs, when those snapshots are loaded, they&#39;re not allowed to run script. If the web page had some shadow dom, how do we serialize it?
21:31inoasso implementors using declarative shadow dom would allow serialization into mhtml snapshots?
21:35jyasskininoas: 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:17TabAtkinsjyasskin, inoas:
22:36DomenicTabAtkins: nonces are not related to crypto
22:36TabAtkinsIt&#39;s 100% related to crypto? You have to send an unguessable nonce.
22:36jyasskinYeah, although they&#39;re a security feature that&#39;s hard to get right. e.g. No static HTML page can safely include a nonce.
22:37jyasskinTabAtkins: There&#39;s no encryption involved. There&#39;s a random number generator, but that&#39;s easier than crypto.
22:37TabAtkinsOkay, sure, you could just use randomness.
22:38TabAtkinsBut randomness is crypto. ^_^
22:41TabAtkinsBut yeah, point is that authors can&#39;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:44MikeSmithTimothyGu: about thing, thanks for caring enough about this (non-implementation-requirements) to take time to review and comment
22:45MikeSmithin hindsight, I realize your comment about Nothing being technically correct, that was spot on
22:46MikeSmithyou were right, I was wrong to think we shouldnt make it clear there (even for author/developer readers)
22:47MikeSmithits just messy to try figure out how to clearly explain the template case, as far as authoring/document-conformance requirements
22:47MikeSmithI mean, to explain it without making it even more complicated and confusing to read about
22:49MikeSmithits a pulling-threads case, where I find that the more details I consider including there, the more other explanation that requires pulling in
22:49MikeSmithanyway, I think (hope) we are getting close to the sweet spot, in the review iterations in
13 Sep 2017
No messages
Last message: 9 days and 11 hours ago