| 06:26 | <rniwa> | Domenic: yt? |
| 06:26 | <rniwa> | annevk: yt? |
| 07:15 | <annevk> | rniwa: yup |
| 07:15 | <rniwa> | annevk: so I've been looking into sync creation of custom elements |
| 07:15 | <rniwa> | annevk: I'm consulting with my colleagues as well |
| 07:16 | <rniwa> | annevk: but the biggest problems i've found thus far are: |
| 07:16 | <rniwa> | 1. adoption agency algorithm creates an arbitrary element so this algorithm needs to be robust against scripting |
| 07:17 | <rniwa> | 2. SVG use elements as implemented in WebKit/Blink clones elements such that we need to completely prohibit the use of custom elements inside a SVG context that's referred by use elements if I wanted to have any chance of shipping this in near term |
| 07:18 | <rniwa> | 3. We create document fragment in various places for internal use; e.g. for copy/paste, and those codes can't instantiate custom elements as that would be observable |
| 07:18 | <rniwa> | I think 3 is quite fixable |
| 07:18 | <rniwa> | annevk: I think 1 and 2 are trickier |
| 07:18 | <annevk> | Isn't cloning a kind of important operation to support either way? Frequently used for shadow DOM, no? |
| 07:19 | <rniwa> | annevk: supporting cloning is not that bad |
| 07:19 | <rniwa> | annevk: the problem with SVG use element is that we use cloning internally to implement "use" element's capability to replicate SVG contents |
| 07:59 | <JonathanC> | Still looking for one more W3C member to join us on DataSheets - https://www.w3.org/community/groups/proposed/ |
| 08:03 | <annevk> | rniwa: sounds like Mozilla's problem with cloning, we use it for printing |
| 08:04 | <rniwa> | annevk: yeah, kind of |
| 08:04 | <annevk> | rniwa: well, one of the problems we have with synchronous stuff |
| 08:07 | <rniwa> | annevk: yeah |
| 08:07 | <rniwa> | annevk: I guess we need to talk about this during TPAC |
| 08:07 | <rniwa> | I'm hoping to put all web components related topics on Tue so that I can attend Web Perf WG on Monday |
| 08:08 | <rniwa> | it's really annoying that Service Worker meeting is happening concurrently on Tuesday :( |
| 08:08 | <annevk> | rniwa: Tue is also service workers so that would be a major pain |
| 08:08 | <rniwa> | I don't understand why it's not on Monday or Tuesday with Web Platform WG's meeting |
| 08:08 | <rniwa> | annevk: yeah :( |
| 08:08 | <rniwa> | annevk: do you need to attend SW meeting as well? |
| 08:08 | <annevk> | yes |
| 08:08 | <rniwa> | okay |
| 08:09 | <rniwa> | annevk: I guess we need you for modules stuff though |
| 08:09 | <annevk> | well, depends a bit on what is going to be discussed I guess, but I suspect so |
| 08:09 | <annevk> | this is why WG meetings don't make sense, should just all be unconference |
| 08:09 | <rniwa> | annevk: or rather we should make time arrangements in advance |
| 08:10 | <annevk> | yeah I guess if we already know the topics |
| 08:10 | <annevk> | also not having Domenic around when discussing custom elements is sad |
| 08:10 | <rniwa> | e.g. why is WebApps, SW, CSS, and WebPerf all having meetings at the same time? |
| 08:10 | <rniwa> | the set of people who need to attend those meetings tend to overlap |
| 08:10 | <annevk> | I don't know, it seems like anything discussed at TPAC won't be much conclusive, so I'm mostly going to say hi |
| 08:10 | <rniwa> | so it would make more sense to spread them out |
| 08:11 | <rniwa> | since HTML WG is basically dead now |
| 08:11 | <rniwa> | annevk: oh Domenic won't be at TPAC!? |
| 08:11 | <annevk> | nope |
| 08:11 | <zcorpan> | which meetings are you guys planning to attend? we can suggest agenda items for things we want to talk about |
| 08:11 | <rniwa> | fuuuuuu |
| 08:11 | <annevk> | he'll be in Japan and we'll meet up, but not at TPAC |
| 08:12 | <annevk> | back in a bit |
| 08:12 | <rniwa> | I'd like to iron out shadow DOM styling, custom elements, and ES6 modules |
| 08:12 | <roc> | rniwa, annevk: seems to me that when cloning for printing we'd want to actually clone the shadow tree, not create a fresh instance of the custom element |
| 08:12 | <rniwa> | and attend WebPerf WG as much as I can |
| 08:12 | <rniwa> | roc: makes sense |
| 08:12 | <roc> | that would cover copy-paste as well |
| 08:12 | <rniwa> | roc: selection/focus is another topic we need to discuss |
| 08:12 | <zcorpan> | (i'm planning on attending css, houdini, texttracks, but might jump in somewhere else) |
| 08:12 | <rniwa> | roc, annevk: right now, the spec says selection behavior is up to implementation which makes zero sense. |
| 08:13 | <rniwa> | since the API is Web exposed |
| 08:13 | <roc> | right |
| 08:15 | <rniwa> | annevk: do you think we should discuss ES6 modules during HTML WG meetings on Thursday or Friday? |
| 08:15 | <rniwa> | instead* |
| 08:15 | <rniwa> | it's kind of weird to have it in HTML WG given WG is dead but maybe that's an argument for stealing some time from it |
| 08:16 | <rniwa> | I almost don't care whether it'll be discussed during a formal meeting either |
| 08:16 | <rniwa> | but keeping things in minutes help for remote participants |
| 08:18 | <Ms2ger> | Clearly we need a WHATWG room |
| 08:19 | <rniwa> | Ms2ger: I'd vote for that |
| 08:19 | <rniwa> | Ms2ger: our meeting will be held on Monday, Tuesday, Thursday, and Friday :D |
| 08:19 | <rniwa> | annevk: you could just do ^ |
| 08:19 | <rniwa> | and ditch all WGs LOL |
| 08:20 | <Ms2ger> | Ask MikeSmith to set up something for an "XML RDF Application Business Group", nobody'd dare complain about that |
| 08:21 | <roc> | the real XML RDF Application Business Group would complain |
| 08:35 | <terinjokes> | the who? |
| 08:47 | <annevk> | roc: the custom element might have some logic associated with cloning, such as cloning an internal value slot or some such |
| 08:47 | <annevk> | roc: similar to what <input> does |
| 08:47 | <roc> | yes |
| 08:47 | <roc> | which we should not run when printing! |
| 08:47 | <annevk> | roc: but then the print doesn't include the text you want printed |
| 08:47 | <roc> | it will if we clone the shadow tree of the original document |
| 08:48 | <annevk> | roc: I guess if everything ends up there or <canvas> or CSS that might work... |
| 08:48 | annevk | hasn't tried to think that through |
| 08:49 | <annevk> | maybe that would work |
| 08:49 | <roc> | anything that's not in the shadow tree or canvas or CSS shouldn't affect the printout |
| 08:50 | <roc> | Houdini custom style and layout, now, that's different |
| 08:56 | <annevk> | yeah, whatever that means |
| 10:35 | <zcorpan> | annevk: in adding inline style support for webvtt, i find i need to set the base URL of the stylesheet to the <track>'s URL post redirects (because that's what CSS does, afaict). HTML only exposes the pre-redirect URL. how should i spec this? |
| 10:35 | <Ms2ger> | Probably fix HTML |
| 10:36 | <Ms2ger> | Base urls should always be post-redirect |
| 10:36 | <annevk> | zcorpan: you need to fix HTML and if you support @import in WebVTT you also need to have some kind of security story |
| 10:37 | <annevk> | zcorpan: and you need to think through referrer behavior I guess |
| 10:38 | <zcorpan> | annevk: the idea is to support @import and all, but security issues haven't been discussed yet |
| 10:40 | <annevk> | zcorpan: I would try to avoid introducing more "opaque" CSS |
| 10:50 | <zcorpan> | annevk: what do you mean "opaque"? |
| 10:51 | <annevk> | zcorpan: https://fetch.spec.whatwg.org/#concept-filtered-response-opaque |
| 10:53 | <zcorpan> | annevk: ok... i don't really follow. what uses that today? |
| 10:54 | <annevk> | zcorpan: CSS, at times |
| 10:55 | <annevk> | zcorpan: basically, require CORS |
| 10:56 | <annevk> | zcorpan: though you should probably read up on Fetch if WebVTT is going to fetch subresources with itself as base URL and referrer and such |
| 10:56 | <annevk> | zcorpan: there's not that many resource types that do that today |
| 10:59 | <zcorpan> | ok. yeah. my idea would be to let the CSS specs handle fetching, though possibly i'd have to fix CSS to do what i want. but i should first consider security if we want to allow fetches at all |
| 11:00 | <zcorpan> | possibly people expect <track> (and <video> with in-band tracks) to be safe like <img> |
| 11:02 | <zcorpan> | even if i require cors, one can write a webvtt file or video with webvtt embedded that pings your server when each cue is rendered |
| 11:16 | <mounir> | annevk: I would like your input on this, if you don't mind: do you think it's better to have one request() method like: sequence<PermissionStatus> request(sequence<Permission>) |
| 11:16 | <mounir> | hmm, scratch that |
| 11:16 | <mounir> | ^ Promise<sequence<PermissionStatus>> request(sequence<Permission>) |
| 11:17 | <mounir> | or: Promise<PermissionStatus> request(Permission) |
| 11:17 | <mounir> | + Promise<sequence<PermissionStatuS>> requestAll(sequence<Permission>) |
| 11:17 | <mounir> | annevk: ^ putting aside the fact that you do not like the Permissions API :) |
| 11:23 | <annevk> | zcorpan: yeah that's a good point, WebVTT having network side effects might have to be opt in to begin with |
| 11:23 | <annevk> | mounir: yeah I dunno |
| 11:24 | <mounir> | annevk: ok |
| 11:24 | <zcorpan> | annevk: yeah and how would you opt-in from a standalone video player? asking the user seems like a bad idea :-) |
| 11:27 | <annevk> | zcorpan: well, it's up to the video player |
| 11:27 | <annevk> | zcorpan: be that <video> or some standalone thing |
| 11:27 | <annevk> | zcorpan: it isn't really up to the user |
| 11:28 | <zcorpan> | yeah |
| 11:29 | <annevk> | The more I poke at these cross-origin objects the weirder they get |
| 11:31 | <mounir> | annevk: oh, speaking of cross origin, do you know why cors restrictions are opt-out instead of opt-in? |
| 12:10 | <annevk> | mounir: I'm not sure what you mean |
| 12:24 | <mounir> | annevk: an xhr will, by default not succeed if done an a cross origin unless the headers have the right flags |
| 12:24 | <mounir> | it's failing by default |
| 12:24 | <mounir> | contrary to stuff like <img> |
| 12:24 | <mounir> | I was wondering if you had any background around the reasons that lead to that |
| 12:24 | <annevk> | mounir: <img> doesn't do a CORS request by default |
| 12:24 | <Ms2ger> | MikeSmith, ping |
| 12:25 | <mounir> | that's what I meant |
| 12:25 | <annevk> | mounir: it's just a legacy SOP hole |
| 12:25 | <annevk> | mounir: see https://annevankesteren.nl/2015/02/same-origin-policy |
| 12:25 | <mkwst> | annevk: Do y'all have a process for PRs that sit on top of other PRs? Like https://github.com/whatwg/html/pull/273 and https://github.com/whatwg/html/pull/272? I'd like to give you small chunks to review, but it's not clear that it makes things any simpler. :) |
| 12:26 | <annevk> | mkwst: I guess tell us which one to do first and then rebase? |
| 12:26 | <mkwst> | annevk: Ok. *shrug* I'll do that, then. |
| 12:51 | JonathanC | is away: I'm busy |
| 12:57 | <annevk> | Ms2ger: I'm going to delete the www-dom hook anyway |
| 12:57 | <annevk> | Ms2ger: it's really annoying and makes me want to unsubscribe from www-dom |
| 13:08 | <MikeSmith> | Ms2ger: her enow |
| 13:35 | <Ms2ger> | annevk, could we set up a dedicated list? |
| 13:35 | <Ms2ger> | MikeSmith, can you give Domenic push access to wpt? |
| 13:41 | <MikeSmith> | Ms2ger: yup but I thought you could as well |
| 13:42 | <Ms2ger> | MikeSmith, only for people who are already in the w3c org |
| 13:42 | <philipj> | zcorpan: do you understand why STYLE blocks must precede cues? |
| 13:43 | <zcorpan> | philipj: to support streaming |
| 13:44 | <zcorpan> | which we don't yet |
| 13:45 | <philipj> | zcorpan: right, and if we did it would only mean that if all of the style isn't known up front, one would have to start a new WebVTT stream if one actually needs new style |
| 13:45 | <MikeSmith> | Ms2ger: ah OK, lemme do it right now |
| 13:45 | <philipj> | zcorpan: doesn't seem to make much sense in a browser, to me at least |
| 13:46 | <Ms2ger> | どうも有難う |
| 13:49 | <zcorpan> | philipj: i'm not familiar enough with inband tracks to know what makes sense for that when there's streaming or seeking and so |
| 13:51 | <philipj> | zcorpan: Me neither really, but I trust that you really do want all of the STYLE up front in that case. I don't follow why that should carry over to the standalone file format, however. |
| 13:55 | <zcorpan> | philipj: it is possible that it is not strictly necessary. but it seems premature to open the door to STYLE blocks after cues before we have figured out how streaming should work (esp. for out-of-band tracks) |
| 13:58 | <annevk> | Ms2ger: you could I guess |
| 13:58 | <philipj> | zcorpan: Sure, perhaps as a precaution, but I genuinely don't understand what Singer is telling me. It would be nice if it were spec'd in a way where the STYLE blocks are all recognized and parsed just fine, but there's a very artificial-looking condition to drop them if there's already a cue. |
| 13:58 | <philipj> | gotta go |
| 14:05 | <zcorpan> | philipj: that would not be strictly equivalent to the current spec i think, a bad cue makes STYLE be ignored also. i suppose the parser can set a flag when first seeing "-->" |
| 14:27 | <MikeSmith> | Ms2ger: nice Japanese :) |
| 14:27 | <MikeSmith> | Domenic should have wpt push access now |
| 14:27 | <Ms2ger> | MikeSmith, the internet is excellent at it :) |
| 14:27 | <MikeSmith> | heh |
| 14:31 | <MikeSmith> | I have no idea what github doesn't allow the (non-"owner") admins for a particular repo to give anybody they want push access or admin access to the repo |
| 14:32 | <MikeSmith> | I'll be charitable and assume they have some good reason that's just not clear |
| 14:32 | <MikeSmith> | s/no idea what github/no idea why github/ |
| 14:33 | <MikeSmith> | ideally, giving somebody admin access to a repo should just make them the full "owners" of the repo so that they can do anything they want with it |
| 14:36 | <MikeSmith> | but as it works now, the full rights still seem to be restricted to people who are "owners" in the org the repo happens to be placed in, and so the only way to give somebody full admin rights to a repo is to make them an "owner" in the parent org, but that then also has the consequence that they have full rights to all other repos in the org as well (including any private repos) |
| 14:49 | <annevk> | I wish we could have different permissions for master vs everything else |
| 14:50 | <annevk> | Big team with push access, but not to master, small set of folks can push to master |
| 14:50 | <Ms2ger> | Ditto |
| 14:57 | <beverloo> | annevk, johnme points out that ULL may not be the ideal type for `timestamp`, since it wouldn't allow dates prior to 1970 (whereas Date does) |
| 14:57 | <beverloo> | annevk, Date.now() returns a Number, which'd map to an unrestricted double, but I'm not sure what the expected behavior for Inf/NaN would be |
| 14:58 | <beverloo> | annevk, do you prefer any type over another? |
| 14:59 | <annevk> | beverloo: hmm, IDL has https://heycam.github.io/webidl/#common-DOMTimeStamp too |
| 14:59 | <beverloo> | yes, but that's only used for events afaik |
| 14:59 | <annevk> | beverloo: when would we have an event prior to 1970 though? |
| 14:59 | <beverloo> | newer specs seem to use either "long long" (file api) or "unrestricted double" (battery api, media controller, media source) for times/durations |
| 15:00 | <annevk> | what a mess |
| 15:01 | <beverloo> | yes. I don't have any solid use-cases ("on this day N years ago"?), but from a purist point of view it's not great that we use Date-created timestamps, but don't support all values |
| 15:01 | <annevk> | I wish there were some principles we could draw from, since it's not at all clear to me what needs to be considered here |
| 15:02 | <beverloo> | issue 2 on WebIDL is exactly about this :) https://github.com/heycam/webidl/issues/2 /cc Domenic |
| 15:02 | <annevk> | beverloo: lazy me thinks you should write a PR for unrestricted double and get Domenic to review it |
| 15:03 | <annevk> | beverloo: if DOMTimeStamp is indeed only for Event it should probably be removed from IDL since it will likely be removed from Event |
| 15:04 | <annevk> | per https://github.com/whatwg/dom/issues/23 if you're interested |
| 15:19 | <beverloo> | annevk, https://github.com/whatwg/notifications/pull/56 |
| 15:35 | JonathanC | is back (gone 02:44:14) |
| 15:35 | JonathanC | is away: I'm busy |
| 15:40 | <annevk> | beverloo: should probably handle NaN/Inf or does unrestricted mean they throw? |
| 15:40 | <annevk> | beverloo: would be weird |
| 15:41 | <beverloo> | unrestricted means they're allowed, restricted (normal double) throws |
| 15:43 | <annevk> | beverloo: it does seem they need to be handled given the other definitions around this concept |
| 15:43 | <annevk> | beverloo: either by throwing or in prose |
| 15:43 | JonathanC | is back (gone 00:08:18) |
| 15:44 | JonathanC | is away: I'm busy |
| 15:44 | <annevk> | JonathanC: could you perhaps disable posting status messages through /me for this channel? |
| 15:44 | JonathanC | is back (gone 00:00:08) |
| 15:45 | <JonathanC> | ssorry |
| 17:25 | <TabAtkins> | Man, what sort of obnoxious client actually thinks that's a good thing to spam? |
| 19:42 | <TabAtkins> | rniwa: *I'll* be at TPAC, and can handle shadow dom styling. The rest is def Domenic material, tho. ^_^ |