[08:19:01.0000] frewsxcv_: "the HTML body element" is a specific body element instance for which innerBody is not a match [08:20:05.0000] Right, that was my understand too [08:20:19.0000] Though should the spec be changed if no browsers honor such a rule? [08:21:52.0000] frewsxcv_: if the spec doesn't match browsers it should change, yes [08:22:17.0000] frewsxcv_: unless all browsers are willing to change within some reasonable timeframe [08:22:48.0000] Where's the issue tracker for cssom-view? [08:23:41.0000] https://github.com/w3c/csswg-drafts ? [08:24:37.0000] Think so [08:26:07.0000] https://github.com/w3c/csswg-drafts/issues/584 [08:44:33.0000] \o frewsxcv_ [08:45:25.0000] o/ [10:59:17.0000] Hi! [11:22:10.0000] Ms2ger: Yeah, that's right (per spec; nobody's implemented that syntax yet). [11:48:11.0000] How I have to do the commits in order to collaborate? [13:21:08.0000] aha, ExtendableMessageEvent is buggy [13:21:24.0000] the usual, default values for dictionary properties missing [13:21:28.0000] (or required) [13:32:16.0000] tobie: Nice analysis in https://github.com/heycam/webidl/pull/180#issuecomment-252736486! [13:32:56.0000] tobie: Your examples make me personally lean toward traversing the prototype in record<>s, but I defer to Domenic and the other real experts here. [13:33:19.0000] Same. [13:34:09.0000] tobie: I am relieved that I said "this only matters in obfuscated-javascript competitions" about the order we call Get(), and not about whether we traverse the prototype. ;) [13:49:14.0000] Would love a bunch of eyeballs especially from folks with a WebDev background on https://github.com/heycam/webidl/pull/180#issuecomment-252736486 (off the top of my head: JakeA, slightlyoff, marcosc_) [13:56:08.0000] uh, lots of discussion in github prs [13:56:15.0000] it all really should go to issues [13:58:14.0000] Why? Discussion in PRs makes sense; it's discussion about something concrete. [14:01:08.0000] github hides some comments in prs [14:01:28.0000] prs should be about discussion about the pr itself [14:01:30.0000] like review [14:02:03.0000] I disagree. [14:02:23.0000] it is mostly github's buggy handling of comments in prs which is really bad [14:02:35.0000] I haven't seen that issue recently. [14:02:36.0000] I don't recall in which cases it hides some comments [14:03:08.0000] it hides then if someone pushes with -f [14:03:35.0000] its got better at showing there were comments on a previous version of the PR [14:03:52.0000] but before you used to lose ALL context. [14:04:15.0000] it has happened that feedback was asked for a spec change, but pretty much all the interesting discussion was hidden [14:09:51.0000] smaug: afaik, but I could be wrong, this is an issue when discussions happen on comments regarding a specific line of code, not on general comments. [14:10:12.0000] smaug: best way to check this would be to look at the GH API's output. [14:24:03.0000] smaug: curl https://api.github.com/repos/heycam/webidl/issues/180/comments and https://api.github.com/repos/heycam/webidl/issues/180/comments?page=2, you'll see the whole top-level comments there. [14:24:43.0000] smaug: note this is the GH API URL to the issue #180 and not it's related PR. [14:25:13.0000] smaug: implementation wise, GH treats PR as a special case of issue [14:27:03.0000] and it is just buggy with prs :) [14:27:08.0000] no reason to not use issues [14:28:57.0000] smaug: talking about real code beats talking about abstract things in my book [14:30:31.0000] smaug: I agree we could do a PR and then open another issue to discuss said PR in that case, [14:30:35.0000] https://github.com/heycam/webidl/pull/180 as an example is a mix of reviews and proposals and stuff. It would be way easier to follow the discussion if the proposals and such were in an issue and one people agree what should be done, there would be a pr for the spec change [14:31:18.0000] smaug: well, except sometimes people only really start to understand what's at stake when there's code to review. [14:31:50.0000] smaug: (code or spec changes) [14:31:53.0000] That rarely happens with spec stuff [14:32:34.0000] (partly because it is somewhat harder to review spec changes) [14:32:55.0000] smaug: well it's a non-issue, then, no? ;) [14:33:10.0000] reviewing itself is an issue [14:33:24.0000] but nothing to do with github issues/pr stuff [14:34:54.0000] smaug: I agree both GH issues and PRs tend to drift and quickly go all over the place. [14:36:31.0000] smaug: that's why, as editor, I tend to update the main issue with the current state of the conversation, write summaries, or split up an issue into more precise ones, potentially sometimes closing the main issue. [14:36:48.0000] smaug: Not sure how to best fix that, but I digress. [14:40:59.0000] I see that spec writing should be similar to writing code [14:41:33.0000] when you upload a patch (pr) you already should know what kind of change should be done [14:41:36.0000] smaug: The open-dictionary issue (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158) sat for years until the PR focused people's minds. Folks got stuck discussing iteration order in the issue, but only noticed the prototype question once the spec text was there. [14:41:49.0000] so, github pr is similar to bugzilla bug in my mind [14:41:54.0000] and issues for discussion [14:42:51.0000] (well, W3C bugzilla is used like github issues, I was referring to mozilla's bugzilla ) [14:43:37.0000] I guess I could be happy with PRs only, if it wasn't buggy [14:49:12.0000] How I do to make suggestions? I'm not allowed to do a pull request, what can I do? [14:52:50.0000] larfen: have you read https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F ? 2016-10-11 [18:46:23.0000] can anyone think of a reason why validator should consider require-sri-for in csp header to be an error? [18:50:03.0000] a-ja: possibly because I haven't updated the validator with the latest spec changes [18:51:16.0000] actually we mostly just rely on a third-party library for CSP checking, and I have not updated to the latest version of that for many months [18:52:08.0000] https://github.com/shapesecurity/salvation [18:53:02.0000] MikeSmith, ....looking [18:54:38.0000] issue 144 fixed 3 months ago, eh? [18:58:53.0000] Yeah I'm using version 2.0.1, which was released in February [19:00:02.0000] please file an issue at https://github.com/validator/validator/issues if you have time [19:00:29.0000] MikeSmith, think I'll pass that URL on to April King for possible use at observatory.mozilla.org [19:03:12.0000] Ah yeah I like that Observatory thing [19:03:35.0000] MikeSmith, https://github.com/validator/validator/issues/382 [19:03:57.0000] But Observatory already does CSP header checking, right? [19:04:19.0000] thanks for raising the issue [19:04:25.0000] MikeSmith, found a csp parser error with it the other day....which is why i thought of it now [19:04:36.0000] Ah [19:04:49.0000] it's been fixed [19:05:02.0000] Ok [19:07:15.0000] I will try to update the validator to the latest Salvation version today [19:08:27.0000] and hope they did not make any breaking changes to their API that will require me to rewrite my code [19:10:57.0000] MikeSmith, sorry....got a call. sounds good. tks [23:48:25.0000] can't agree more with jyasskin. Nothing beats a PR, and new issues show up as you start writing things down. [00:13:07.0000] That is kinda why we keep discussing things there [02:51:20.0000] heycam: hey think you could give me admin access to the webidl repo? I need to set up some web hooks for a bot. Happy to relinquish afterwards, just easier to setup that way. [02:55:59.0000] tobie: I need to move it to an org to be able to do that [02:56:18.0000] heycam: oh, really? That sucks. [02:56:23.0000] tobie: yeah :( [02:56:48.0000] tobie: I can either add a hook now for you, or we can discuss moving again ... [02:57:46.0000] heycam: I'll look into the hook url and payloads I need. [02:57:57.0000] heycam: you're still around for a little bit? [02:57:59.0000] tobie: ok thanks, sorry for the inconvenience [02:58:07.0000] tobie: no I have to leave the office about now :) [02:59:01.0000] heycam: ok, will email you later so you get this by tomorrow morning [02:59:10.0000] tobie: no problem, will add them first thing in the morning [02:59:22.0000] ty [04:43:12.0000] could someone explain why there are MessageEvent and ServiceWorkerMessageEvent interfaces? [04:47:35.0000] smaug: I think primarily because source could be something else [04:47:42.0000] smaug: I suggested we should just merge those though [04:48:01.0000] yeah, feels a bit silly to have similar events [04:48:07.0000] which are now even inconsisten [04:48:09.0000] t [04:48:18.0000] one accepting null ports, one doesn't [04:48:19.0000] etc [04:49:06.0000] smaug: it seems like Hixie_ blocked it in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28199 [04:49:34.0000] smaug: well, he didn't really [04:49:50.0000] smaug: it seems nobody studied that in sufficient detail :/ [04:50:00.0000] "studied" [04:50:27.0000] filed https://github.com/w3c/ServiceWorker/issues/989 [04:51:22.0000] of course there is also https://github.com/w3c/ServiceWorker/issues/988 [04:51:33.0000] smaug: oh, I filed https://github.com/w3c/ServiceWorker/issues/990 [04:52:29.0000] smaug: ok, marked mine as dupe [04:53:45.0000] I wonder what to implement now [04:53:53.0000] whether .ports should be nullable or not [04:54:18.0000] (or in other words, whether I can review+ the patch which makes MessageEvent to follow the latest spec) [04:58:17.0000] I think so, unless there's some weird reason we can't change ServiceWorkerMessageEvent [04:58:24.0000] But that seems unlikely [04:58:36.0000] not sure [04:58:39.0000] or, hmm [04:59:09.0000] is the ServiceWorkerMessageEvent.ports always set to some value when UA dispatches those events [05:01:29.0000] I guess so [05:01:32.0000] at least to [] [05:45:34.0000] MikeSmith: can https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html now be a redirect to https://xhr.spec.whatwg.org/? [05:55:18.0000] this focusin/out is such a nice mess too :) [05:56:22.0000] smaug: sigh yes [06:02:00.0000] in blink it is possible to have events for the same target in order: blur, focus, focusin, focusout [06:02:11.0000] and after that the element is focused [06:02:34.0000] even though the last even it got was focusout [06:03:14.0000] This is what you get when UI events refuses to define a processing model for years on end [06:03:52.0000] rbyers isn't convinced that's the biggest problem for some reason, but there's just so many edge cases that would suddenly be clear if we did that [06:04:53.0000] well, this isn't even UI events [06:05:02.0000] this is webkit/blink implementing something totally random [06:05:35.0000] against even those vague hints UI events spec have about the behavior [06:08:10.0000] The other problem with focus is that it's in part defined by HTML [06:12:01.0000] smaug: pre and post-click-dispatch steps [06:12:13.0000] smaug: is that basically an extra iteration over event's path? [06:12:26.0000] smaug: before we call any listeners, and after all listeners are invoked? [06:12:33.0000] smaug: and we only do after if the canceled flag is still unset? [06:12:55.0000] so in Gecko "pre" is about creating path [06:13:03.0000] we may do some other stuff there too [06:13:15.0000] like that type=checkbox state change [06:13:40.0000] yeah, that would become part of pre-click-dispatch [06:13:45.0000] is there anything else? [06:13:54.0000] and post is using the path, and is a separate iteration after normal dispatch [06:13:59.0000] I guess it could be combined with creating the path, but it doesn't necessarily have to be [06:15:03.0000] (In gecko '̈́post' is part of "system group dispatch", which is separate, not-web-visible capture-target-bubble phase after normal c-t-b, and 'post' is part of the system groups bubble phase) [06:15:28.0000] Yeah, I'm trying to get us to improve this space is a test-driven way. We've got a number of inconsistencies between specs and implementations already, I'm skeptical that focusing primarily on improving spec quality will help much on its own. [06:15:59.0000] rbyers: it's really hard to write comprehensive tests if you don't know the processing model [06:16:07.0000] rbyers: you can't really have good implementations without specs [06:16:18.0000] rbyers: considering them each in isolation is somewhat problematic [06:16:28.0000] Right we need to do them all together [06:16:31.0000] (and yes, having good specs require 2-3 implementations at leasts) [06:16:42.0000] rbyers: and why many efforts fail (e.g., the one around contenteditable which also focused only on tests) [06:16:59.0000] We can write tests from the perspective of what developers expect to happen / what sites are relying on today. [06:17:12.0000] I agree it would be a mistake to focus only on tests [06:17:14.0000] that's way too simplistic, imo [06:17:25.0000] But in the UI events space tests have been almost entirely neglected. [06:17:47.0000] So we have a lot of catch-up to do there before all three can really evolve together [06:17:47.0000] tests and impls have too [06:17:53.0000] specs and impls have too* [06:18:20.0000] nothing there has meaningfully improved for a long time [06:18:38.0000] I'm extremely skeptical you can write comprehensive tests by studying what websites do [06:19:12.0000] Not in isolation, no of course not [06:19:19.0000] yeah, without some model one will miss tons of edge cases in tests [06:19:57.0000] We have some model in the spec today, it's just weak [06:20:22.0000] I'm not opposed to someone rewriting the spec to make more sense if one of you is volunteering ;-) [06:20:23.0000] There's no real model in the spec imo [06:20:47.0000] I guess at some point someone will have to, since the current approach doesn't seem to be working [06:21:00.0000] And it's starting to hurt other things [06:21:33.0000] (as long as it's done in a forum Microsoft can participate in of course - they have a ton of good web compat experience on input behavior) [06:21:43.0000] It's a little annoying that all the cleaning up falls to us [06:22:29.0000] UIEvents doesn't really have model. it has just a list of events basically. List of feature browser is expected to implement, but doesn't tell how the features should work. Quite similar to WebPerfWG's specs. [06:22:37.0000] rbyers: if it actually falls to me I'll do it somewhere where I'm comfortable [06:23:17.0000] It's not true that there haven't been real improvements here BTW [06:23:32.0000] mouseover/out/enter/leave behavior used to be completely different between a number of engines [06:23:46.0000] and we saw real world bugs as a result [06:24:08.0000] the spec got more precise and blink overhauled it's behavior to match. Now blink, gecko and Edge are at least pretty consistent. [06:25:59.0000] We'll keep making incremental progress like this. Eg. focus behavior is on the blink input team's plans for Q4: https://bugs.chromium.org/p/chromium/issues/detail?id=645988 [06:27:30.0000] rbyers: BTW, as of now my plan is to just go with blink's focusin/out behavior in Gecko (someone else has written the patch). With most of blink's bugs and all. [06:27:41.0000] I guess we should document somewhere the behavior [06:27:50.0000] (well, there will be some wpts) [06:28:02.0000] ugh [06:28:35.0000] Please cc dtapuska on your plans in gecko - he's leading a new engineer in trying to fix our behavior. [06:28:44.0000] all these events are so regression prone. [06:29:11.0000] So if the spec'd behavior isn't web compatible, then it would be good to know that.... [06:29:24.0000] rbyers: but, if you're actively now fixing the bugs and possibly even making focusin/out follow the spec, Gecko would do that too [06:29:45.0000] Ah, good. Yeah it's happening just taking time while some new folks ramp up [06:30:15.0000] rbyers: I guess only MS might know whether the spec'ed behavior is web compatible [06:30:25.0000] since they had it something like that in EI [06:30:35.0000] but switched to closer to webkit/blink model in Edge [06:33:59.0000] "We're starting on the (hopefully not too convoluted) process of updating the Cookies RFC" [06:34:00.0000] Lol [06:36:13.0000] lunch [07:04:33.0000] JakeA: are we re-creating cookies for this issue? https://github.com/w3c/ServiceWorker/issues/920#issuecomment-252657496 [07:04:48.0000] an origin scoped thing that gets set on network requests automatically [07:05:04.0000] by "thing" I mean header [07:05:46.0000] obviously there are some differences too... but the similarities we striking to me reading through the last few comments there [07:06:20.0000] wanderview: yep. I'm a little sad about that. See https://github.com/w3c/ServiceWorker/issues/920#issuecomment-245621515 and the following few comments [07:07:05.0000] It certainly makes the API less tidy [07:07:30.0000] JakeA: I wonder if we could split this from the particular use case... origin headers that are applied based on sane rules (as opposed to cookies which I think might have insane rules?) [07:08:39.0000] I dunno, just a random though [07:08:41.0000] thought [07:12:01.0000] wanderview: https://github.com/w3c/ServiceWorker/issues/920#issuecomment-247144874 is Facebook's objection [07:13:26.0000] JakeA: well, right... I was saying lets avoid cookies... but pre-specifying a header to apply to all future requests that match X could be a generic thing and not specific to SW preload (or whatever we are calling it these days) [07:13:37.0000] Domenic: the "initialized" pattern you like so much stems from the lack of internal slots [07:14:13.0000] Domenic: the idea was to use "initialized" rather than "set" as some language to get to the internal slot, but with nothing formalized it's all somewhat confused of course [07:14:22.0000] wanderview: I'm open to that. It's very specific right now though, it's specifically these preload requests [07:15:24.0000] wanderview: avoid cookies because? [07:15:47.0000] annevk: see JakeA's link to FB's objection to cookies [07:16:10.0000] annevk: https://github.com/w3c/ServiceWorker/issues/920#issuecomment-247144874 this is what Nate from Facebook was talking about at the F2F [07:16:25.0000] wanderview: sorry, I meant to ask why you'd like to avoid that [07:16:33.0000] my interpretation is "cookies have a lot of baggage and don't worry the same everywhere"... and we don't expose cookies in SW yet [07:19:13.0000] JakeA: have we thought about things like size limits on this preload header thing? Its basically another place for people to store stuff (perhaps synchronously?) [07:19:51.0000] wanderview: I hadn't thought much about it. I guess it could count towards origin storage [07:20:33.0000] JakeA: less worries about quota and more thinking of people abusing it as synchronous storage... does the API currently sync set and get the header? [07:20:46.0000] wanderview: no it's async [07:20:51.0000] ok, good [07:20:52.0000] thanks [07:21:13.0000] /me was thinking of fxos code that stuck pre-rendered HTML for the page in a cookie for fast first load. [07:21:21.0000] hah [07:23:12.0000] annevk: my impression is cookies had all kinds of weird legacy behavior around paths, limits on number, etc... that fact that everyone groans when cookies come up made me want to avoid them [07:23:34.0000] wanderview: I see, but this has none of that [07:23:46.0000] wanderview: main problem with cookies imo is that they're not origin-bound, which this is [07:24:03.0000] ok... I was not saying to use cookies... [07:24:07.0000] Also they only want it sent on the preloads [07:29:37.0000] JakeA: I think the bit that makes me mention all this is the differences with Cache API... Cache is origin-based and the SW then picks which one to use... this header thing is implicitly to the registration matching logic [07:29:54.0000] JakeA: although maybe this is just a consequence of not going whole hog on static routing [07:30:51.0000] /me wonders if Europeans understand the phrase "whole hog". [07:32:02.0000] oh... it seems its common in Britain as well: https://britishhogroasts.co.uk/go-the-whole-hog/ [07:41:09.0000] wanderview: since the preload is a service worker thing, it makes sense to tie it to the registration (like push subscriptions) [07:41:34.0000] wanderview: I think static routes will end up being tied to the service worker rather than the registration fwiw [07:41:55.0000] I wanted preload to be tied to the service worker too, but that doesn't work if you have a header that can be updated at any point [07:42:44.0000] JakeA: I think the same could be said about Cache API... but we made it its own thing... just seems similar to me [07:43:50.0000] wanderview: we nearly made caches tied to a sw, but it became really ugly when you wanted a cache to last longer [07:44:24.0000] wanderview: not against adding an api to tie a cache (or storage box) to a sw. It'd remove the need for that ugly "activate" boilerplate [07:45:05.0000] JakeA: you misunderstand me :-) I was saying we could separate the header API from the SW registration just like we did for Cache API... I don't want to go the other way [07:46:19.0000] wanderview: ohhh sorry! But if this header is sent has part of preload, which is inherently a service worker thing, doesn't separating them make it more confusing? [07:48:27.0000] JakeA: yea... if we moved it out we would have to have a way to say "apply this to preload requests only"... but in theory this API would have a way to match requests anyway in order which ones to apply the header to [07:49:27.0000] JakeA: but this is all just brainstorming... I'm not really objecting to the current API proposal [07:50:14.0000] wanderview: I'll have a think about it. I'm a little grumpy about it because the API was *so much* nicer when the header wasn't updatable :D [07:50:31.0000] But I suppose there's no point in a nice API if it isn't useful [07:51:05.0000] JakeA: I was just thinking if we could make it setable at the origin level, separate from SW, perhaps it would be easier to manage across SW life cycles [07:51:18.0000] similar to how you can load Cache objects from window today [07:51:40.0000] wanderview: I think that would clash with having multiple registrations on the same origin [07:52:24.0000] JakeA: well, the API would need some kind of URL matching... perhaps the same matching algorithm specified by Cache API [07:53:14.0000] but maybe the intent is really to glob resources under the scope [07:53:24.0000] I dunno... again... just random thoughts [07:55:32.0000] wanderview: I'd like this preload thing to be expressible in static routing at some point, so separating the header a little would help there [07:58:50.0000] JakeA: I'm thinking something like this: https://gist.github.com/wanderview/d268442914398a66613682957dd2f8ff [08:00:00.0000] wanderview: how would that only relate to preload requests? [08:06:21.0000] JakeA: let met add that now... someone was at the door [08:08:32.0000] JakeA: ok, reload the gist [08:09:12.0000] wanderview: ohhh, that's actually pretty neat [08:09:50.0000] JakeA: using the http cache matching semantics doesn't really provide scope-like path matching, though [08:10:11.0000] but that could be adapted in some way [08:11:39.0000] although for Cache API we set substring matching was a de-opt [08:11:43.0000] and removed it [08:11:50.0000] ^set^said [08:12:10.0000] Hah, I was just trying to remember what we called that option [08:13:17.0000] woah... shots fired at npm https://code.facebook.com/posts/1840075619545360 [08:13:27.0000] wanderview: anyway, my brain's not working right now (for some reason I didn't sleep last night). Let's pick this up again tomorrow… but I kinda like it. [08:13:53.0000] JakeA: np, have a good night! (I assume you were still thinking about Sunday's debate in the US!) [08:14:50.0000] I'll stick the idea in the github issue [08:56:18.0000] annevk: was it intentional that when Headers.get() was switched to combine headers that the Cache API Vary matching would begin matching combined headers as well? [08:56:25.0000] JakeA: ^^^ [08:57:21.0000] I'll file an issue to clarify [09:00:00.0000] annevk: JakeA: filed this... https://github.com/w3c/ServiceWorker/issues/991 [09:13:08.0000] wanderview: dunno, will study later [10:23:43.0000] wanderview: sooo, briefly looked at the Cache API algorithms [10:23:49.0000] wanderview: they appear broken [10:27:21.0000] annevk: ok, we'll have to discuss with JakeA tomorrow I guess [10:27:42.0000] wanderview: yeah, we basically shouldn't be invoking IDL operations [10:27:56.0000] wanderview: and definitely not from algorithms that run "in parallel" [10:28:32.0000] wanderview: but I also think HTTP doesn't just look at the first header [10:28:46.0000] wanderview: for HTTP there's no difference between multiple headers or one header with a comma-separated value [10:28:56.0000] wanderview: except for cookies (another reason folks dislike them) [10:29:43.0000] how does "Add links to tests from requirements (beta)" work? [14:04:20.0000] TabAtkins: where's you and fantasi's old old form control styling proposal? [14:48:40.0000] Domenic: here's my handwavy one from a few years ago https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html [14:49:22.0000] hober: oh cool, thanks! [14:49:28.0000] np 2016-10-12 [23:56:08.0000] heycam: just emailed you the webhook details right now. No hurry, I'm on parental duty today. :) [23:56:13.0000] tobie: just saw it :) [23:58:10.0000] heycam: while you're at it, can you check: Enforce HTTPS at the bottom of the settings page? [23:59:17.0000] heycam: at the bottom of https://github.com/heycam/webidl/settings [23:59:19.0000] tobie: ok added, it tells me it sent a ping message, for which the hook returned a 502 page whose title is "Heroku | Welcome to your new app!" [23:59:35.0000] ticked. [00:01:00.0000] Yeah, need to deploy the bot. [00:01:22.0000] heycam: which I'll find time for later (hopefully) [00:01:28.0000] cool cool [00:03:16.0000] sigh [00:04:09.0000] johanneswilm keeps at it with premature closing of issues [00:04:39.0000] heycam: thanks a bunch [00:04:47.0000] np! [00:25:22.0000] annevk: which issue? [00:26:16.0000] MikeSmith: https://github.com/w3c/input-events/issues/38 [01:07:07.0000] "Beyond that, it doesn't really matter what it returns, or whether it differs from implementation to implementation." [01:07:28.0000] longer sigh [01:20:51.0000] miketaylr_: seen anything about outerText yet? [01:21:13.0000] Ms2ger: Gecko not getting a bug report for outerText might not mean which with respect to "mobile web" [01:21:48.0000] Ms2ger: at this point if it's everyone-but-Gecko it'll only disappear from the web if someone else starts actively removing [01:22:01.0000] Ms2ger: asking for data and they'll just be like "shrug" [01:22:31.0000] Don't we have people at Google who like to add use counters now? [01:24:23.0000] I guess I wouldn't be surprised if the response ended up being "too high, won't remove", but it feels like it's worth checking [01:27:23.0000] I guess you could ask @foolip [02:15:50.0000] No overnight feedback on the click event business unfortunately [05:27:06.0000] Maybe for the best, since I found some mistakes [05:27:58.0000] smaug: it seems other implementations do not traverse the whole path to run "activation behavior" [05:28:05.0000] smaug: they only do it for the first instance [05:28:42.0000] smaug: also, I can't figure out how works [05:29:35.0000] it depends on the case I think [05:29:54.0000] Gecko may have a bug with / [05:30:07.0000] well, basically input [05:30:20.0000] smaug: I also get different behavior for click() and synthetic events [05:30:25.0000] to not mark the event handled so that doesn't try to handle it [05:30:40.0000] https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Ca%20href%3D%2F%3Ex%3Cinput%20type%3Dcheckbox%3E%3Cdiv%3Ex%3C%2Fdiv%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.querySelector(%22input%22).dispatchEvent(new%20MouseEvent(%22click%22))%0A%3C%2Fscript%3E [05:30:52.0000] Now replace the dispatchEvent stuff with click() [05:31:20.0000] From your explanation of how click() should work (just run dispatchEvent()) it seems like there's a bug there? [05:32:20.0000] Oh, maybe it's because of bubbling? [05:32:57.0000] /me wonders what bug he is looking at [05:33:17.0000] smaug: classify bug? [05:33:18.0000] ah, in chrome there might be a bug it seems [05:33:27.0000] annevk: you said there is a bug :) [05:33:36.0000] smaug: there's a lot of different behavior [05:33:46.0000] bug = "inconsistency" in this case [05:35:59.0000] smaug: so the other thing seems to indeed be about bubbling [05:36:20.0000] smaug: but that means that for the pre-click stuff we should also look at bubbling, no? [05:37:30.0000] I'm lost now what you're talking about [05:39:02.0000] Compare [05:39:03.0000] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Avar%20input%20%3D%20document.createElement(%22input%22)%0Ainput.type%20%3D%20%22checkbox%22%0Ainput.appendChild(new%20Text(%22x%22))%0Ainput.firstChild.dispatchEvent(new%20MouseEvent(%22click%22))%0Aw(input.checked)%0A%3C%2Fscript%3E [05:39:07.0000] https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ca%20href%3D%2F%3Ex%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.querySelector(%22a%22).firstChild.dispatchEvent(new%20MouseEvent(%22click%22))%0A%3C%2Fscript%3E [05:39:17.0000] Why does the former check the checkbox, but the latter not follow the link? [05:43:14.0000] annevk: ah, that. Ok, input checked is changed during pre-handling [05:43:27.0000] smaug: I know [05:43:40.0000] and link triggered during post-handling, but we don't bubble from the textnode to [05:43:54.0000] so yes, bubble needs to be taken account [05:43:55.0000] as far as I see [05:44:25.0000] /me tries to find some code in blink which was very unexpected... dealing with some of this stuff [05:45:30.0000] smaug: but this means that if you cancel that click event the post-handling steps don't run for the input [05:45:56.0000] Can't find the code in blink now [05:46:08.0000] but anyhow, looks like they have similar handling for bubbling as gecko: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/events/EventDispatcher.cpp?sq=package:chromium&l=297 [05:46:34.0000] smaug: that is, we change checkedness of the input due to a non-bubbling click on a descendant, but you can't cancel that as you could if it bubbled [05:46:58.0000] right [05:47:01.0000] smaug: so logically, it seems you'd want to take bubbling into account for pre-handling too [05:47:31.0000] annevk: well, this is very edge case. is odd beast, and that element doesn't usually have child nodes [05:47:46.0000] (not that it matters much in practice, since almost never has children, but it would make the logic better in the spec, since you can determine the "activation element" just once) [05:48:14.0000] that is, if we determine the activation element just once, we don't have to traverse the path multiple times [05:52:31.0000] smaug: thoughts on that? [05:56:18.0000] annevk: if it helps with spec'ing and only change browsers would need to do is change default handling when event is coming from a child node of an element, sounds ok to me. .... are there other cases when pre-handling is used? [05:56:56.0000] smaug: I only found pre-click handling and post-canceled-click handling in HTML for and [06:06:37.0000] annevk: fwiw, the Encoding Standard's big5 encoder can produce output that glibc thinks is valid Big5-HKSCS but not valid Big5 [06:07:21.0000] annevk: we probably don't care, but still interesting considering that the Encoding Standard is trying to be conservative on the encoder side [06:07:57.0000] hsivonen: foolip basically designed that encoding; I suspect that he wanted to be mostly conservative, but also not make it too hard on himself [06:08:11.0000] hsivonen: or effectively, require two tables [06:08:58.0000] let's avoid two tables [06:10:15.0000] (ah, right, the weird blink case was something about hit testing and when to dispatch click. So, not really about this case) [07:39:39.0000] how does "Add links to tests from requirements (beta)" work? [07:45:36.0000] In XHR? [07:45:40.0000] xpath in the tests [07:46:32.0000] ewwww [07:47:26.0000] it just looks /so/ fragile [07:47:37.0000] ids would be so much better :\ [07:47:48.0000] maybe I've been in CSS-land too long thinking that it's better [07:52:34.0000] gsnedders: if you get stable IDs [07:59:57.0000] annevk: sure, but IDs are more likely stable than '"following::dfn[2] following::dfn[3] following::dfn[4] following::dfn[5] following::dfn[6]' [08:00:10.0000] annevk: and it's far easier to make IDs stable [08:00:32.0000] gsnedders: I'm agreeing with you [08:01:05.0000] gsnedders: does require adding IDs to places and making them discoverable (inspect element is not liked) [08:01:05.0000] oh, ok :) [08:01:34.0000] well even with inspect element it's more discoverable than the current XPath paths [08:01:46.0000] That's prolly the main difficulty, bz is asking for a lot more (discoverable) IDs in HTML too [08:02:19.0000] We could prolly do some through Wattsi, once someone starts hacking on it more seriously, but not sure about per-paragraph and keeping those stable [08:08:51.0000] what's the motivation to stick with wattsi for HTML when nothing else is using it? just the time/effort taken to move away? [08:09:49.0000] gsnedders: yeah, and likely speed of alternatives [08:13:49.0000] Rewrite bikeshed in Rust, obviously [08:29:52.0000] jgraham: You have 2 hours. [08:35:09.0000] nox: As fun as that sounds instead I have to work on javascript angular crap [08:35:23.0000] jgraham: Heh. [08:38:05.0000] jgraham: Angular? That's so 2015. [08:38:23.0000] gsnedders: Well 2014 in this case I think [08:38:41.0000] There seems to be a drive to put some React in our angular [08:38:44.0000] jgraham: you haven't redone the website in *two years*?! WTF. How do you still have customers? [08:38:48.0000] For maximum buzzword compliance [08:38:59.0000] jgraham: And I mean you're never going to get VC funding with such an outdated tech stack [08:38:59.0000] gsnedders: "captive audience" [08:39:12.0000] No VC funding you say? [08:39:14.0000] Excellent [08:39:21.0000] Fuck that [08:40:52.0000] Don't you care about your valuation!? [09:06:44.0000] Domenic: https://drafts.csswg.org/css-forms/ [09:07:42.0000] that was it, thanks! [09:10:48.0000] gsnedders: Yeah, tho I've recently done some major perf-hacking on HTML-using-Bikeshed, it still takes almost a full minute on my high-powered workstation. [09:11:34.0000] (Almost all of the time is spent in the initial HTML parse, the final HTML serialization, and evaluating selectors between those two, in roughly equal amounts.) [09:39:06.0000] In Fx/Ch land, does a single build go from Beta -> Stable, or does it have a different version number? [09:43:03.0000] Not a single build all the way through, but same major version [09:43:28.0000] yeah, I just mean the final move from beta to stable? [09:43:48.0000] or is there no RC-phase where you have essentially the final build in its final config before it lands on stable? [09:47:43.0000] gsnedders: I think we still land stuff post beta and RC is at the end of stable [09:48:04.0000] gsnedders: have not really looked into this much though [09:48:50.0000] annevk: I mean really what I want to know is can I take a version number (from the UA string) and tell what channel it's on? [09:50:53.0000] gsnedders: oh, dunno, maybe [10:31:22.0000] hsivonen: you'll enjoy reading through https://github.com/whatwg/html/commit/76f88a4015d55273749c34238d250b7bdb1aff62 [10:32:20.0000] (prolly most people here would, but, you know, hsivonen wrote a whole thing about it back in the day: https://hsivonen.fi/vendor-prefixes/ ) [10:41:10.0000] annevk: wait so is trusted the default? [10:41:34.0000] ah i see it is in DOM [10:41:53.0000] HTML just doesn't re-state that. [11:40:57.0000] Domenic: default for spec-dispatched stuff [11:41:33.0000] Domenic: click(), maybe reset(), are exceptions [11:41:52.0000] Domenic: hopefully all clear soonish [11:55:40.0000] Domenic: I was thinking of also defining a special "create" for event classes for specs, that would give them a trusted variant [11:56:04.0000] Domenic: but click stuff first [13:02:29.0000] Good morning (UGT: Universal Greeting Time). 2 questions: is there a place used to track compatibility issues between browsers (like https://github.com/whatwg/compat)? Can anyone open issues there? [13:14:56.0000] Savago: not exactly what you're asking for, but try https://browser-issue-tracker-search.appspot.com/ [13:15:47.0000] Savago: there is some repo that the Edge and Mozilla folks use a lot to report specific websites that fail due to cross-browser compat problems... I think I've seen paul_irish using it too. Can't remember what it was called... [13:16:37.0000] astearns, that is a pretty handy site. Thanks. :-) 2016-10-13 [00:10:37.0000] rniwa: could you comment on https://github.com/whatwg/dom/pull/336 please? [00:31:38.0000] oh, this is interesting [00:31:57.0000] i always thought react's virtual DOM is something that they use on the standards [00:32:50.0000]