| 07:33 | <annevk> | Domenic: not sure if it's all your work, but that custom elements introduction looks great |
| 07:33 | <annevk> | Domenic: reviewing the non-DOM parts for a bit |
| 09:53 | <Ms2ger> | annevk, ping |
| 09:53 | <annevk> | Ms2ger: hey |
| 09:54 | <Ms2ger> | The document.domain getter seems to put []s around ipv6 addresses now |
| 09:54 | <Ms2ger> | Was that intentional? |
| 09:56 | <annevk> | Ms2ger: yeah, I think that changed a while back |
| 09:57 | <Ms2ger> | jgraham, I don't suppose we can test that in wpt? |
| 09:57 | <annevk> | Ms2ger: see https://github.com/whatwg/html/issues/670 |
| 09:58 | <Ms2ger> | annevk, great, thanks |
| 10:24 | <Ms2ger> | annevk, no luck for https://github.com/whatwg/html/issues/635 ? :) |
| 10:28 | <annevk> | Ms2ger: ftp/http/https check I guess, not sure if URL should have a primitive |
| 10:37 | <annevk> | Ms2ger: yeah, I guess I should add network scheme, and leave out ws/wss since they are pointless |
| 10:37 | <annevk> | Ms2ger: will fix later today |
| 10:37 | <Ms2ger> | Thanks! |
| 10:46 | <jgraham> | Ms2ger: No ipv6 at the moment |
| 10:49 | <MikeSmit1> | jgraham: no ipv6 for what? |
| 10:49 | <MikeSmit1> | ah, see scrollback now |
| 10:50 | <MikeSmit1> | smaug____: Justin Fagnini from Polymer project was at some of the Web Components f2f meetings |
| 10:50 | <MikeSmit1> | can find an e-mail address for him if that’s all you want |
| 10:51 | <MikeSmit1> | I don’t know him so well personally, so if you want an actual intro, maybe annevk or Domenic can help |
| 10:59 | <annevk> | MikeSmit1: I am missing some context |
| 11:00 | <annevk> | Oh scrollback, doh |
| 11:02 | <smaug____> | MikeSmit1: I was just looking for some way to report about a bug in Polymer |
| 11:04 | <annevk> | smaug____: would love input in the slotchange issue |
| 11:09 | <smaug____> | annevk: I commented there |
| 11:10 | <smaug____> | annevk: if this is about the event |
| 12:10 | <annevk> | smaug____: yeah, no opinions on reusing mutation observers (or their infrastructure)? |
| 12:29 | <smaug____> | annevk: kind of mixed opinions :). It is not about any DOM mutation |
| 12:29 | <smaug____> | it is about distribution change |
| 12:30 | <smaug____> | and we'd need to then tell exactly what was changed |
| 12:30 | <annevk> | smaug____: I guess it's not strictly speaking insert/remove, but shadow DOM is part of the DOM |
| 12:31 | <smaug____> | and rniwa was worried about providing all the distributed nodes in the record or something |
| 12:31 | <smaug____> | I don't consider shadow DOM being part of DOM. DOM tree is DOM tree, and Shadow DOM is a layer on top of it |
| 12:32 | <annevk> | smaug____: maybe, but the DOM mutation algorithms specifically account for shadow roots |
| 12:32 | <annevk> | smaug____: and soon will probably have to be changed to account for slots too if we're doing something with this event, which it seems like we will |
| 12:33 | <smaug____> | I'm mostly talking about the concept |
| 12:33 | <smaug____> | of DOM and Shadow DOM |
| 12:33 | <annevk> | Sure, me too, I just view it differently I think |
| 12:34 | <annevk> | If Shadow DOM was just a layer on top, we wouldn't have to revise all existing features to account for it |
| 12:41 | <annevk> | TabAtkins: when will Shepherd next index HTML? |
| 12:41 | <annevk> | TabAtkins: I want to make use of the various new origin terms in other documents |
| 13:06 | <zcorpan> | who should review https://github.com/whatwg/html/pull/907 and https://github.com/html5lib/html5lib-tests/pull/72 ? should i ask for review in a comment in https://bugs.chromium.org/p/chromium/issues/detail?id=412945 ? |
| 13:07 | <zcorpan> | smaug____: ^ |
| 13:07 | <smaug____> | my review queue is rather full atm |
| 13:08 | <zcorpan> | ok :-) do you happen to know someone who knows the parser and doesn't also have a full review queue? |
| 13:09 | <smaug____> | hsivonen? |
| 13:10 | <jgraham> | There are people who will admit to not having a full review queue? |
| 13:11 | <Ms2ger> | Huh |
| 13:11 | <Ms2ger> | zcorpan, is there no longer a spec for alternative style sheets? |
| 13:12 | <smaug____> | Ms2ger: you hate the new w3c stylesheet too? |
| 13:12 | <Ms2ger> | Meh |
| 13:12 | <zcorpan> | Ms2ger: there is, but the API is gone |
| 13:12 | <jgraham> | The new W3C stylesheet is surprisingly bad |
| 13:12 | <Ms2ger> | zcorpan, where is it, and why? |
| 13:13 | <zcorpan> | Ms2ger: since only gecko implemented it and nobody else has shown any interest in implementing the API |
| 13:13 | <Ms2ger> | Did you file a bug? |
| 13:17 | <zcorpan_> | i think i have, yeah, but need to dig to confirm. i brought it up on www-style a few years ago and there has been no movement afaict |
| 13:18 | <zcorpan_> | https://lists.w3.org/Archives/Public/www-style/2013Aug/0640.html |
| 13:28 | <Ms2ger> | zcorpan_, filed bug 1260720 |
| 13:28 | <Ms2ger> | zcorpan_, so where is the spec for the feature? |
| 13:30 | <zcorpan_> | Ms2ger: https://drafts.csswg.org/cssom/#add-a-css-style-sheet et al. though there are various bugs especially around mutation of attributes and such |
| 13:30 | <zcorpan_> | Ms2ger: there's something in CSS2 talking about alternative stylesheets too I believe |
| 13:31 | <Ms2ger> | Aha |
| 13:33 | Ms2ger | finds https://github.com/whatwg/html/issues/848 |
| 13:33 | <zcorpan_> | hmm CSS2 didn't have much on the topic |
| 13:34 | <zcorpan_> | though https://html.spec.whatwg.org/multipage/semantics.html#link-type-stylesheet |
| 13:35 | <zcorpan_> | loading stylesheets needs more love :-( |
| 13:37 | <Ms2ger> | I know the perfect person! |
| 13:38 | <annevk> | zcorpan_: could you confirm https://github.com/whatwg/html/pull/965#discussion_r57881425 please? |
| 13:38 | <annevk> | zcorpan_: ta |
| 13:38 | <zcorpan_> | annevk: sorry for the delay :-) |
| 13:39 | <annevk> | zcorpan_: no worries, I was taking a break anyway |
| 13:39 | <zcorpan_> | let me know if there's something else that needs my attention, i have too many notifications |
| 13:44 | <annevk> | zcorpan_: there's a bunch of issues and bugs assigned to you |
| 13:44 | <annevk> | zcorpan_: not sure about anything immediate though |
| 14:06 | <beverloo> | Suppose I have a worker that imports something with importScripts() (using a relative URL), which in turn imports another script using importScripts() (again using a relative URL) |
| 14:06 | <beverloo> | is the second import expected to be resolved against the first imported script's URL, or the worker's URL? |
| 14:08 | <beverloo> | Is this the "API base URL" definition, which would imply it's resolved against the worker global scope's URL? |
| 14:10 | <Ms2ger> | first imported script's URL |
| 14:10 | <Ms2ger> | At least, that's what it should do |
| 14:11 | <Ms2ger> | Seems like the spec is buggy |
| 14:11 | <beverloo> | It looks like Chrome does the wrong thing too |
| 14:12 | <Ms2ger> | I'm fairly certain Gecko gets this right |
| 14:14 | <Ms2ger> | https://github.com/whatwg/html/issues/969 |
| 14:14 | <beverloo> | I'll run some more tests and file this against Chrome if it's broken. Thanks :) |
| 14:15 | <annevk> | Ms2ger: no, not against the script URL |
| 14:15 | <Ms2ger> | ? |
| 14:15 | <annevk> | Ms2ger: that doesn't make much sense, we don't know what a given function is associated with |
| 14:16 | <annevk> | Ms2ger: URLs are always resolved against some thing grabbed from the global |
| 14:20 | <Ms2ger> | @import doesn't |
| 14:20 | <annevk> | Ms2ger: sure, statics are different, module script identifiers don't either |
| 14:21 | <Ms2ger> | Still seems very confusing |
| 14:21 | <annevk> | Ms2ger: but with executing scripts there's no reasonable way to determine what resource they come from |
| 14:21 | <annevk> | Ms2ger: this is no different in an HTML context |
| 14:21 | <annevk> | Ms2ger: if you have <script src=/test/> in / and that does fetch("x") it'll fetch /x and not /test/x |
| 14:22 | Ms2ger | will think about it some more later |
| 14:23 | <annevk> | Ms2ger: otherwise each function would have to keep some pointer to the script its associated with and it'll get harrier still if functions invoke each other from different files, etc. |
| 14:23 | <Ms2ger> | I guess that's true |
| 14:23 | <annevk> | Ms2ger: it'd also be incompatible with what Brendan et al shipped years ago |
| 14:52 | <Ms2ger> | > In general, Chrome engineers should only be implementing new APIs that have reasonable Explainer documents attached. |
| 14:52 | <Ms2ger> | Are they going to write them too? |
| 14:52 | <annevk> | beverloo: if you manage to get hold of jsbell, tell him I'll try put in some effort into the Storage Standard tomorrow |
| 14:52 | <annevk> | Ms2ger: not sure I'll put effort into that, not even sure Explainer documents are useful if they're not part of the specification; only a very select audience would see them |
| 16:15 | <TabAtkins> | annevk: Shepherd respiders everything (a) whenever anything in our CI gets updated (CSSWG, Houdini, FXTF), and (b) midnight pacific time |
| 16:16 | <annevk> | Hmm, so tomorrow things should work in theory |
| 16:17 | <annevk> | I've started putting data-export="" on a couple of things |
| 16:17 | <TabAtkins> | annevk: Cool! Unexported things from HTML are annoying. ^_^ |
| 16:18 | <TabAtkins> | I'm still not 100% sure I made the right call in "dfn" terms being unexported by default (so "local" definitions wouldn't leak out accidentally). |
| 16:18 | <annevk> | I think typically I would have expected those to be exported actually |
| 16:18 | smaug____ | wonders why insertAdjacentText doesn't return the inserted text node |
| 16:19 | <annevk> | And actually, what probably would be best is export everything and require some kind of keyword for the other spec, as in <a spec=html>whatever term</a> |
| 16:19 | <annevk> | smaug____: I didn't try to question the design |
| 16:20 | <smaug____> | annevk: right. so the answer is "it's legacy stuff" |
| 16:21 | <annevk> | smaug____: yeah, I suppose |
| 16:21 | <annevk> | "Find the person at Microsoft who shipped this before going home early" |
| 16:21 | <annevk> | That's probably a little too mean |
| 16:22 | <annevk> | Everyone ships pretty poor APIs the web sometimes get stuck with |
| 16:22 | <smaug____> | annevk: so https://dom.spec.whatwg.org/#insert-adjacent doesn't actually return the element ever. It returns null in some cases, but not the element |
| 16:23 | <smaug____> | I assume the idea is to return whatever pre-insert returns |
| 16:23 | <annevk> | smaug____: my bad |
| 16:23 | <smaug____> | this is for insertAdjacentElement case |
| 16:24 | <annevk> | smaug____: yeah, I'll fix |
| 16:24 | <annevk> | smaug____: yeah, *Text ignores the return value |
| 16:24 | <smaug____> | thanks |
| 16:30 | <annevk> | smaug____: https://github.com/whatwg/dom/commit/5790d7288f3970b27ec5ac81aad2662eddb94959 |
| 16:32 | <TabAtkins> | annevk: Making cross-spec linking as seamless as possible was the entire point. That said, if you *do* always specify the spec, you never have to worry about exporting. ^_^ |
| 16:33 | <annevk> | TabAtkins: yeah, except now the seamless aspect is often wonky with other specs taking over terms and such |
| 16:33 | <annevk> | TabAtkins: and requiring terms to be globally unique |
| 16:34 | <annevk> | TabAtkins: probably makes sense for CSS, but not sure it scales well beyond that |
| 16:35 | <TabAtkins> | Specs "taking over terms" accidentally was an impl mistake on my part, it doesn't happen any more. |
| 16:35 | <smaug____> | r+ (at least for the insert adjacent stuff. seems to have random other changes too) |
| 16:36 | <TabAtkins> | I've got a planned mechanism for handling obsoletion and *purposeful* takeover, but I haven't implemented it yet. Still slowly, cautiously, doing autolinking refactoring to make the code sane before I introduce another complication to the model. |
| 16:36 | <smaug____> | btw, we're getting wpt tests for this from a gecko patch |
| 16:36 | <annevk> | smaug____: great |
| 16:36 | <TabAtkins> | smaug____: I can hook you up with some polymer folks; I'm heading into the office with them today. I'll be there in about an hour. Whatcha need? |
| 16:36 | <annevk> | TabAtkins: e.g., what about this HTML fork done in bikeshed? It seems it hasn't caused problems yet, but what if they start making demands? |
| 16:37 | <annevk> | TabAtkins: or these EME folks who think they want to reference forked HTML despite it having all kinds of security issues |
| 16:39 | <smaug____> | TabAtkins: it was about https://bugzilla.mozilla.org/show_bug.cgi?id=1256031#c13 |
| 16:39 | <TabAtkins> | annevk: I control the list of specs in Bikeshed, and I'm not going to put in both HTMLs unless/until the fork is resolved properly. |
| 16:40 | <TabAtkins> | (In other words, I'm only putting in one of them.) |
| 16:40 | <annevk> | I guess we'll find out if someone decides to try |
| 16:51 | <TabAtkins> | How they gonna try? They have to go thru me, or else just hand-author a <pre class=anchors> block. |
| 16:52 | <annevk> | TabAtkins: I mean when they try to go through you, agreed it's rather theoretical at this point |
| 16:53 | <annevk> | TabAtkins: btw, in case of conflicts you'll just have to use spec=""? |
| 16:53 | <TabAtkins> | Yeah. (Or resolve it document-wide with some link-defaults.) |
| 19:00 | <wanderview> | can we do this for all the whatwg specs in infrastructure? https://twitter.com/jensimmons/status/715017455349985280 |
| 20:48 | <MikeSmith> | wanderview: I believe the (smartass) answer is, Patches welcome |
| 20:48 | <MikeSmith> | but agreed it would be a very good thing to have and I would personally be willing to put time into making it happen |
| 20:49 | <MikeSmith> | especially for the lerget-than-life HTML spec |
| 20:49 | <wanderview> | MikeSmith: I guess I was wondering if it would have to be on a spec-by-spec basis... or if things like Bikeshed could just automatically add support |
| 20:50 | <MikeSmith> | as far as Bikeshed I guess TabAtkins would know the answer to that |
| 20:50 | <MikeSmith> | but for the general case it seems like we sure could |
| 20:51 | <MikeSmith> | just by making a library and maybe needing to tweak that specs a bit so that they all do whatever consistently to make use of the hook into the library in the same way |
| 20:53 | <MikeSmith> | well that all sounds really abstract when I say it so it makes me think we should just start out by trying it with one spec |
| 20:55 | <MikeSmith> | Domenic: btw about the dfn-links-across-multipage I really wonder if can’t just do that by building a separate index at build time, of all the terms and all references to them |
| 20:56 | <wanderview> | MikeSmith: maybe in the... service worker spec |
| 20:56 | <MikeSmith> | heh |
| 20:56 | <MikeSmith> | yeah that would be appropriate of course |
| 20:56 | <MikeSmith> | the SW spec is not a WHATWG spec though |
| 20:57 | <MikeSmith> | it’s really a standalone thing |
| 20:57 | <wanderview> | MikeSmith: we talk about it a lot in this channel |
| 20:57 | wanderview | doesn't understand the political divisions... |
| 20:58 | <MikeSmith> | well I guess it’s in either Respec or Bikeshed now and W3C-branded (or at least a copy of it is), so not an island in the way it used to be |
| 20:59 | <MikeSmith> | wanderview: I do understand the political divisions and like political divisions elsewhere, there are reasons for them |
| 20:59 | <MikeSmith> | that doesn’t make the political divisions helpful though |
| 20:59 | <MikeSmith> | anyway to me we are all part of a single do-ocracy |
| 21:00 | <MikeSmith> | I mean, the people who are solving real problems and getting technologies for the Web created that actually ship and make a difference in people’s lives on scale |
| 21:01 | <wanderview> | yea... I try to ignore that stuff and try to just get stuff done |
| 21:01 | <MikeSmith> | yup |
| 21:01 | <MikeSmith> | editors make their own choices about where they want to do their work, and they should have to discretion to do that |
| 21:04 | <MikeSmith> | slightlyoff has his way with how/where he started the Service Workers spec, mkwst has his way of getting a lot of great work done in a W3C WG (despite the politicsーexploiting the W3C to its full potential) |
| 21:05 | <MikeSmith> | exploiting in a good wayーmaking the best use of what’s actually good and most helpful about the W3C |
| 21:06 | <MikeSmith> | and yoav is making stuff get done in the WICG |
| 21:08 | <MikeSmith> | and in some ways the entities everybody happens to work for are enlightened patrons with good sense to give people doing the work on specs (and tests) for the platform a lot of flexibility and trust |
| 21:08 | <MikeSmith> | no matter what place those people/editors choose personally at the place to do their work, be it WHATWG, W3C, WICG or whatever |
| 21:09 | <MikeSmith> | trust the editors to make their own choices about where they can get their work done the best |
| 21:11 | <MikeSmith> | btw TabAtkins is obviously also an example of solving real problems productively even within the W3C constraints/political culture |
| 21:11 | <MikeSmith> | maybe the best example |
| 21:11 | <MikeSmith> | anyway, end sermon :) |
| 21:14 | <MikeSmith> | Domenic: for the dfn things, to mitigate the performance suckage of having it regenerate, we could client-side cache/store each formatted one (for each term) the first time the reader clicks a term to create it |
| 21:14 | <wanderview> | MikeSmith: I wasn't trying to be negative... I just admit I don't know how things get most of the time :-) |
| 21:15 | <jgraham> | wanderview: "I wasn't trying to be negative" - ah, then I think you were offtopic |
| 21:15 | <MikeSmith> | wanderview: nah, I realize you weren’t trying to be negative. I guess some of what I said is a sub-remark for the channel related to discussions some of us have also been having elsewhere recently |
| 21:15 | <MikeSmith> | heh |
| 21:17 | <MikeSmith> | Domenic: I would guess that most readers only use the dfn feature with a handful of terms and then use it repeatedly with those terms |
| 21:17 | <MikeSmith> | Domenic: so it would be a waste anyway to pre-generate them all for every reader ahead of time, since they are never going to use most of them anyway |
| 21:18 | <MikeSmith> | anyway, I’m clearly just thinking out loud right now about it |
| 21:27 | <Domenic> | MikeSmith: hmm interesting. I guess ahead of time seems nicer in most cases, just maybe not for singlepage. Although I'd be curious about the numbers. |
| 22:18 | <littledan__> | mathiasbynens: What do you think of this? https://bugs.chromium.org/p/v8/issues/detail?id=4879 It seems like a bug to me, but I think you reported the opposite to Apple |
| 22:18 | <littledan__> | I can't imagine how case folding semantics should make /\W/ui.test("S") true. If the ES spec makes it true, that seems like a spec bug |
| 22:24 | <TabAtkins> | Hmmm, Bikeshed probably could. At least it could produce the scripts for you (opt-in, obviously). You still need to be on https, of course. |
| 22:25 | <TabAtkins> | MikeSmith: ^^^ (re: Bikeshed providing a SW for caching the spec) |
| 22:27 | <Domenic> | The real trick is to get your spec generator to cache everything on the same origin... which I guess doesn't work great for *.spec.whatwg.org, lolz. But w3.org would be in good shape. |
| 22:28 | <TabAtkins> | Yeah. |
| 22:28 | <Domenic> | (the idea being you can click on any cross-spec link and still have it work offline) |
| 22:28 | <jyasskin> | Obviously the specs should be on https. ;-) |
| 22:29 | <Domenic> | Otherwise a network attacker could trick browser vendors into implementing CORS wrong. I can see the CVE now... |
| 22:32 | <TabAtkins> | Ah, so Bikeshed would analyze the cross-spec links, and set up a script accordingly so that when you viewed that spec, it made caching-requests to the origin's SW. Then any future views will have all links working. |
| 22:33 | <Domenic> | ooh that's a cool idea |
| 22:33 | <Domenic> | i was thinking more simply some kind of w3.org-wide service worker that cached everything |
| 22:33 | <Domenic> | relevant: https://github.com/whatwg/resources.whatwg.org/issues/6 from 2015-05-15 |
| 22:33 | <TabAtkins> | And once it's been loaded on one spec, unaware specs on the same origin will at least get the benefit of the SW's cache for the specs it's done caching for. |
| 22:33 | <Domenic> | also fun would be https://github.com/whatwg/resources.whatwg.org/issues/7 |
| 22:33 | <TabAtkins> | I just can't analyze unaware specs for their *own* dependencies, as the SW can't reach across on its own. |
| 22:34 | <TabAtkins> | (Until you click something on one of them; the SW will intercept and cache that.) |
| 22:35 | <TabAtkins> | Unfortunate that the WHATWG specs can't all share a cache, tho. ;_; |
| 22:35 | <Domenic> | yeah dang |
| 22:36 | <TabAtkins> | Y'all done goofed. |
| 22:36 | Domenic | handwaves ... isolation is good? |
| 22:37 | <littledan__> | move SW to cookie-style isolation! |
| 22:37 | <Domenic> | I think storage.spec.whatwg.org is already eTLD+1 for some reason |
| 23:51 | <Domenic> | TabAtkins: any reason auto-linking wouldn't work for interfaces named %Uint8Array%? |
| 23:56 | <TabAtkins> | Domenic: I have restrictions on what's allowed in a recognized shorthand, and % isn't there. I can add it tho. |