| 05:27 | <annevk> | rniwa: hayato: are you both around? |
| 05:27 | <rniwa> | annevk: I'm around |
| 05:27 | <rniwa> | annevk: what's up? |
| 05:27 | <annevk> | rniwa: hayato: wondering if I should land the PR first with the isTrusted guard and then file a follow up to remove it or just remove it straight away |
| 05:28 | <rniwa> | annevk: yeah, I think that makes sense |
| 05:28 | <annevk> | rniwa: hayato: I was also wondering if we agreed that click() should be composed and if there's a bug on that |
| 05:28 | <rniwa> | annevk: yeah, I think I'm okay with that |
| 05:28 | <rniwa> | annevk: but that needs to be spec'ed somewhere |
| 05:28 | <annevk> | rniwa: hayato: I'm fixing all kinds of things around events so would be good to know |
| 05:28 | <rniwa> | annevk: probably in the HTML spec where we define click()? |
| 05:28 | <rniwa> | annevk: okay |
| 05:29 | <annevk> | rniwa: hayato: yeah, it would be in HTML |
| 05:29 | <annevk> | rniwa: hayato: contextmenu is another event btw we have to consider that is rather similar to click |
| 05:29 | <rniwa> | annevk: there is contextmenu() !? |
| 05:29 | <annevk> | rniwa: yeah |
| 05:30 | <annevk> | rniwa: without the parenthesis |
| 05:30 | <rniwa> | annevk: Wtf... i've never heard of this |
| 05:30 | <annevk> | rniwa: it's just an event |
| 05:30 | <rniwa> | annevk: oh just an event |
| 05:30 | <annevk> | rniwa: but it should probably be composed |
| 05:30 | <rniwa> | annevk: probably |
| 05:30 | <rniwa> | annevk: since that presuambly fires when a context menu is shown, right? |
| 05:30 | <annevk> | rniwa: yup |
| 05:30 | <rniwa> | annevk: btw, we really need the event processing model you were talking about: https://github.com/w3c/input-events/issues/42 |
| 05:31 | <rniwa> | annevk: the entire input events spec is extremely vague and underspeced due to input events processing model not being defined |
| 05:31 | <annevk> | rniwa: yeah, I've been complaining for a long time now |
| 05:31 | <annevk> | rniwa: and before me Hixie_ was doing the complaining |
| 05:31 | <rniwa> | annevk: it might be that we just need a different spec |
| 05:31 | <rniwa> | annevk: like event processing model spec |
| 05:31 | <rniwa> | annevk: since we don't want to have another mega spec... |
| 05:32 | <annevk> | rniwa: I guess, if they're not going to address it someone else will start writing it |
| 05:32 | <rniwa> | annevk: yeah... |
| 05:32 | <annevk> | rniwa: HTML defines small bits of it currently, such as the contextmenu event |
| 05:32 | <annevk> | rniwa: it's super messy |
| 05:32 | <rniwa> | annevk: I mean, in terms of what's being spec'ed, ui events spec is pretty good |
| 05:32 | <rniwa> | annevk: but we probably need a separate spec that details how each keydown / mousedown / etc... end up causing bunch of side effects and trigger other events |
| 05:33 | <annevk> | rniwa: I think if you write that, and also define hit testing and such, you'll find that most of UI events can go away |
| 05:34 | <rniwa> | annevk: perhaps |
| 05:34 | <rniwa> | annevk: but ui events define properties, etc... pretty well |
| 05:35 | <rniwa> | annevk: so I think that's pretty good |
| 05:35 | <rniwa> | annevk: but yeah, hit testing is another thing that's not well defined... |
| 05:35 | <annevk> | rniwa: it doesn't really, those properties need to be initialized during the action that dispatches the event |
| 05:35 | <annevk> | rniwa: they are the result of input from the OS and the result of hit testing and such |
| 05:36 | <rniwa> | annevk: well, sure but I think the whole thing doesn't necessary needs to be defined in one place although it could be |
| 05:37 | <rniwa> | annevk: ui events is still a very valuable spec. but I do agree a lot more |
| 05:37 | <rniwa> | we need* a lot more |
| 05:37 | <annevk> | HTML4 was valuable too at some point |
| 05:37 | <annevk> | anyway :p |
| 05:41 | <rniwa> | annevk: btw, if you could review, I have two more PRs for custom elements: https://github.com/w3c/web-platform-tests/pulls?utf8=✓&q=is%3Apr%20is%3Aopen%20rniwa |
| 05:42 | <rniwa> | annevk: it looks like custom elements is almost done now. |
| 05:42 | <annevk> | I'll let Domenic/Dominic review |
| 05:42 | <annevk> | rniwa: yeah, it's pretty exciting |
| 05:42 | <rniwa> | annevk: it's kind of crazy how we keep finding more issues with shadow DOM |
| 05:42 | <rniwa> | annevk: it's like digging potatos |
| 05:42 | <annevk> | rniwa: it's a pretty big feature |
| 05:42 | <rniwa> | annevk: it is. but we've been working on this years. |
| 05:43 | <rniwa> | annevk: I would have thought we have figured the list of issues by now... |
| 05:43 | <annevk> | rniwa: I think we only started working on some of the integration bits in the last two years or so |
| 05:44 | <annevk> | rniwa: in part because the closed mode was never integrated/accepted until then |
| 05:44 | <annevk> | rniwa: and the monkey patches for various algorithms were not completely worked out yet |
| 05:49 | <rniwa> | annevk: that's a good point |
| 05:55 | <annevk> | rniwa: btw, is https://github.com/whatwg/html/pull/1196 something you'd implement in WebKit? |
| 05:55 | <annevk> | rniwa: I thought I saw you saying we needed that somewhere |
| 05:56 | <rniwa> | annevk: oh, that's for custom elements reporting exceptions |
| 05:56 | <rniwa> | annevk: I wasn't saying that we needed that API though |
| 05:57 | <rniwa> | annevk: I just just saying that we needed to spec that behavior |
| 07:45 | <JakeA> | I'm failing at basic searching. What was the proposal to allow resources to be cached across origins using a hash? I thought it was SRI but can't find a reference to cache-sharing. |
| 07:47 | <JakeA> | Ah, it is SRI, just not in the spec. https://github.com/w3c/webappsec-subresource-integrity/issues/22 & https://github.com/w3c/webappsec/issues/504 |
| 08:16 | <mkwst> | JakeA: There was some non-normative text in an earlier version of the spec that got dropped. Brad wrote something up a few weeks ago that's probably worth skimming: https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html |
| 08:18 | <JakeA> | mkwst: cheers! |
| 08:40 | <annevk> | mkwst: maybe start using PRs? |
| 08:41 | <annevk> | mkwst: "nit picked up in next patch" is rather unclear |
| 08:41 | <annevk> | mkwst: esp if nothing has landed anywhere yet |
| 08:47 | <mkwst> | annevk: A PR would have been a better approach for this bug, you're right. |
| 08:47 | <mkwst> | annevk: In general, I find it hard to do anything useful with comments on specific commits. |
| 08:48 | <annevk> | mkwst: I usually file issues, but in this issue you asked for feedback on the commit |
| 08:56 | <mkwst> | annevk: I did. That was dumb. I'll PR questions next time. |
| 09:30 | <zcorpan> | i'd like for someone(TM) to add necessary tooling to enable coordinated shipping of breaking changes, for changes like https://github.com/whatwg/html/issues/944 or https://bugs.chromium.org/p/chromium/issues/detail?id=530342 |
| 09:31 | <zcorpan> | any takers? :-) |
| 09:32 | <zcorpan> | the current situation of "yeah sure we can try to coordinate shipping" doesn't seem to work |
| 09:36 | <annevk> | zcorpan: I don't think that'll ever quite work due to shipping dates being different |
| 09:36 | <annevk> | zcorpan: and UAs getting different compat pain due to sniffing |
| 09:37 | <zcorpan> | annevk: shipping dates is more difficult for microsoft and apple but seems manageable between mozilla/google/opera |
| 09:39 | <zcorpan> | annevk: sniffing was not a problem for the innerHTML thing and doesn't seem like a problem for https://bugs.chromium.org/p/chromium/issues/detail?id=530342 either |
| 09:40 | <zcorpan> | note also that greg from microsoft is asking for coordinated shipping in that issue |
| 09:43 | <annevk> | He is? |
| 09:43 | annevk | didn't see that |
| 09:43 | <annevk> | Anyway, I guess if it can be made to work somehow... |
| 09:46 | <zcorpan> | doesn't have to be on the same day, but as close as possible so the vendor who ships first can say "yeah it breaks your site but it also breaks in Beta of all other browsers which will ship in a few weeks" instead of having to revert the change |
| 09:46 | <zcorpan> | hmm, maybe not in that issue but in https://lists.w3.org/Archives/Public/www-style/2016Apr/0345.html |
| 09:47 | <zcorpan> | https://lists.w3.org/Archives/Public/www-style/2015Sep/0076.html was the first message |
| 09:51 | <annevk> | Git question: one branch (1) with many commits post-master; I then branch off (2) from there; then master gets a single commit covering all those commits, perhaps with minor changes, can I then rebase 2 against master and only get my new commits? |
| 09:52 | <annevk> | I'd like to start working on the changes needed for synthetic click events in HTML, but they depend on major event cleanup landing first |
| 09:53 | <Ms2ger> | Yes, I think |
| 09:54 | <Ms2ger> | You may need to remove the old commits manually when doing rebase -i |
| 09:54 | <annevk> | That sounds reasonable |
| 09:56 | <jgraham> | Yeah, so it will work out that the rebased commits don't add any changes and skip them (non-interactive case) or complain at you and make you write git rebase --skip (interactive case) |
| 11:26 | <smaug> | foolip: do you happen to know what might happen with https://github.com/whatwg/html/issues/1882 ? |
| 11:27 | <foolip> | smaug: no, I pinged https://github.com/w3c/ServiceWorker/issues/989 though |
| 11:28 | <foolip> | smaug: I guess you'd prefer that it's just reverted? |
| 11:28 | <smaug> | yes, but there is now a patch for Gecko so I don't care too much |
| 11:28 | <smaug> | this may break pages in theory |
| 11:28 | <smaug> | and I see no reason for the spec change |
| 11:32 | <foolip> | smaug: In hindsight I agree, had I understood that ServiceWorkerMessageEvent exists and that there still can be no [SameObject] I hope I'd have seen it differently. |
| 11:33 | <foolip> | smaug: is bakulf the maintainer of this in Gecko? |
| 11:33 | <smaug> | he just happened to write the patch for this |
| 11:33 | <smaug> | which I just reviewed |
| 11:35 | <foolip> | smaug: I took https://github.com/whatwg/html/issues/1882#issuecomment-252685167 as some amount of enthusiasm from a Gecko dev, I guess asking for not just the test but also implementation change to be done before landing the spec change would have caused you to notice earlier. |
| 11:35 | <foolip> | Well, maybe, it'd probably have been WebKit first. |
| 11:36 | <smaug> | foolip: not sure bakulf really expressed opinion, but just technical comment |
| 11:36 | <annevk> | We should figure something out for SW imo, current duplication situation is not great |
| 11:36 | <smaug> | oh well |
| 11:37 | <smaug> | foolip: anyhow, I'm ok with either approach now, even though making this kind of useless changes feels wrong |
| 11:37 | <annevk> | I somewhat prefer not having null when it is meaningless, but I can see the argument for avoiding churn |
| 11:38 | <foolip> | smaug: we did have a 3/4 split and a recent 2/2 split, had it been nullable everywhere I don't think we'd have contemplated it |
| 11:56 | <littledan__> | to follow up on grapheme breaks: I asked Mark Davis, and he said that the definition of grapheme breaks is currently in some bit of flux when it comes to Indic scripts; he recommended including the locale in any new APIs for grapheme breaks as a future-proofing mechanism |
| 11:57 | <foolip> | I have no context here, but to include something in an API that currently does nothing makes it harder to feature detect when it starts doing something later. |
| 12:00 | <annevk> | littledan__: was that meant for a different channel? |
| 12:01 | <littledan__> | I think rniwa expressed this concern in this channel, that's why I mentioned it here |
| 12:01 | <annevk> | Oh, was it about <textarea>? |
| 12:01 | <littledan__> | no, this is a TC39 thing |
| 12:01 | <annevk> | I guess I also lack context 😊 |
| 12:01 | <littledan__> | foolip: If behavior changes, it'll be due to locale data changing, which you shouldn't be trying to feature-detect for |
| 12:02 | <littledan__> | I am proposing that https://github.com/littledan/Segmenter handle grapheme breaks based on an object that takes a locale as a parameter |
| 12:02 | <littledan__> | anyway, I guess rniwa is not on here right now |
| 12:03 | <nox> | gsnedders: I brainfarted yesterday btw, was running older h5lib tests. |
| 12:03 | <foolip> | littledan__: I imagined something like someAPI({ locale: 'bla' }), where the locale member would truly have no effect until someone figures out something about Indic scripts. If not, please ignore me. |
| 12:03 | <littledan__> | foolip: It's like new Intl.Segmenter("en", { type: "grapheme" }) |
| 12:04 | <littledan__> | you could pass undefined if you felt like it, but the argument may be used to determine some details about grapheme breaking |
| 12:05 | <littledan__> | that'll give you an object that'll let you find breaks in strings |
| 12:07 | <foolip> | littledan__: ok, I will go away now :) |
| 12:08 | <littledan__> | foolip: All these Intl things are really complex, and if you have ideas for how to make it more intuitive for users (which would be great, if we can get applications to use them to a greater extent) then I'm interested |
| 12:08 | <annevk> | littledan__: so grapheme clusters will require a locale to work properly going forward? |
| 12:08 | <annevk> | littledan__: it seems a little weird to "recommend" an argument to a function |
| 12:09 | <foolip> | littledan__: I have no idea, it was just the "future-proofing mechanism" that had me wonder if it was a bit of API that would initially do nothing in implementations |
| 12:09 | <littledan__> | annevk: ...possibly. It'll probably work well in the root locale most of them time, though. |
| 12:09 | <littledan__> | you definitely need a locale for all other kinds of breaks |
| 12:10 | <littledan__> | annevk: ECMA 402 has a consistent convention that, if you use undefined for the locale, then it's whatever locale the user agent selects |
| 12:10 | <annevk> | littledan__: ooh, hopefully that's the same as navigator.language or some such, or is this a new fingerprinting vector? |
| 12:11 | <annevk> | Oh well, I should probably stick my own issues to sort through |
| 12:13 | <littledan__> | https://tc39.github.io/ecma402/#sec-defaultlocale |
| 12:13 | <littledan__> | not sure if it's always the same |
| 12:14 | <littledan__> | There's a proposal to make more data available than navigator.locale currently exposes, through BCP 47--https://github.com/tc39/ecma402/issues/106 . I hope we don't have to hold this up on fingerprinting concerns! |
| 12:55 | <annevk> | littledan__: ideally you would or at least call it out clearly |
| 12:55 | <Domenic> | littledan__: that is good to here that grapheme breaks should include locale; that makes the API nice and symmetric in Segmenter. /cc rniwa bterlson |
| 13:11 | <foolip> | annevk, Domenic, either of you feel like signing off on https://github.com/whatwg/html/pull/1924 since it does change things where multiple choices might have been sane? |
| 13:11 | <littledan__> | annevk: How do other specs do that? |
| 13:12 | <annevk> | littledan__: https://html.spec.whatwg.org/#fingerprinting-vector |
| 13:15 | <littledan__> | Filed https://github.com/tc39/ecma402/issues/110 |
| 13:17 | <Domenic> | foolip: I'd feel OK if we got Blink and WebKit signoff; I think this might be a case where we're spec-churning because I think cdumez filed an issue earlier on the same stuff. |
| 13:24 | <foolip> | Domenic: I see https://github.com/whatwg/html/pull/29 and https://github.com/whatwg/html/pull/1105 |
| 13:24 | <foolip> | Domenic: can you find the cdumez one? |
| 13:24 | <Domenic> | foolip: nah those are probably it, I was probably misremembering |
| 13:25 | <Domenic> | Oh wait |
| 13:25 | <Domenic> | foolip: https://github.com/whatwg/html/issues/1519 |
| 13:26 | <annevk> | That we are still modifying these fairly simple decade-old table methods is... I dunno |
| 13:26 | <jgraham> | foolip: I think you probably convinced / trolled me into implementing those things, when I have a minute |
| 13:27 | <foolip> | jgraham: sure would be great for testing HTML changes :) |
| 13:27 | <jgraham> | Need to fix epic breakage "caused" by a wpt import first |
| 14:24 | <crankharder> | Is there some standard that defines when a browser stops processing javascript on the current page as it receives a 302 response? |
| 14:33 | <annevk> | crankharder: HTML defines that in theory, but lifecycle is defined somewhat poorly at the edges |
| 14:46 | <annevk> | ugh noopener mess :/ |
| 14:46 | <annevk> | really need to start working on browsing context / global object / document lifecycle drama |
| 15:06 | <crankharder> | annevk: is there something i can read on the subject -- or, can you elaborate on the theory? |
| 15:07 | <annevk> | crankharder: https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents deals with navigation, which is presumably what you're talking about |
| 15:08 | <annevk> | crankharder: if you mean something else, you'll have to elaborate a bit |
| 15:49 | <nox> | So <isindex> is dead for good, |
| 15:49 | <nox> | nice. |
| 15:52 | <Domenic> | see, we CAN remove things |
| 15:55 | <Ms2ger> | Like outerText? :) |
| 16:10 | <annevk> | Ms2ger: like synthetic click events |
| 16:10 | <Ms2ger> | Oh yes |
| 16:10 | <Domenic> | annevk: rebased and reviewing the "rewrite activation behavior" now |
| 16:11 | <Domenic> | I still am sad about the asymmetry in the names |
| 16:11 | <annevk> | Domenic: we could put activation behavior in all names |
| 16:12 | <Domenic> | hmm interesting |
| 16:12 | <annevk> | Domenic: easy to change still |
| 16:12 | <Domenic> | legacy pre-activation behavior steps? |
| 16:12 | <Domenic> | I guess pre-activation-behavior |
| 16:12 | <annevk> | Without steps, with legacy was my thinking |
| 16:13 | <Domenic> | that sounds pretty reasonable |
| 16:13 | <annevk> | Prolly tomorrow |
| 16:13 | <Domenic> | I like the original name better since it's more descriptive, but I care more about the symmetry. Also all my feelings in this area are weak so I'm OK any way :) |
| 16:19 | <annevk> | It's just that click is so non-descriptive purpose-wise |
| 16:23 | <Domenic> | yeah I guess but it's specifically about "click" MouseEvents |
| 16:34 | <annevk> | Domenic: I think historically this name came about to sorta stop DOMActivate from happening, as some kind of "accessible" alternative that would not be used |
| 16:35 | <annevk> | Domenic: instead we generalized click further |
| 16:35 | <Domenic> | sounds fun |
| 17:00 | <nox> | Domenic: Could we remove document.write? |
| 17:00 | <nox> | And I'm *absolutely* not saying this because I need to implement it, |
| 17:01 | <nox> | *absolutely* not. |
| 17:01 | <Domenic> | I think Chrome is doing so in cross-origin iframes |
| 17:01 | <Domenic> | (Actually the conditions are more complicated than that...) |
| 17:01 | <Domenic> | https://github.com/WICG/interventions/issues/17#issuecomment-238477265 |
| 17:02 | <Domenic> | OK not even cross-origin iframe related |
| 17:02 | <Domenic> | It just doesn't run document.written scripts sometimes |
| 17:03 | <nox> | Domenic: The Web is so insane you manage to find a serious answer to the obvious troll I made. |
| 17:03 | <Domenic> | Somehow I am actually really proud of this :D |
| 17:03 | <nox> | :D |
| 17:48 | <annevk> | Domenic: have you heard anything on hit regions? |
| 17:48 | <annevk> | Domenic: are we getting rid of them? |
| 17:48 | <annevk> | Domenic: the current monkey patching of the "UI mouse click action" is rather worrisome |
| 17:50 | <annevk> | Domenic: I guess I should check implementations again and then just drive for removing it from the specification for now and let someone else come up with a replacement |
| 17:50 | <annevk> | smaug: ^^ |
| 17:51 | <smaug> | hmm, why is that UI mouse click action worrisome? |
| 17:52 | <smaug> | I thought the issue there was the overengineered hit region stuff, where normal elements could work in practice just fine |
| 17:53 | <annevk> | smaug: I mean, the monkey patching of UI mouse click action is for hit regions |
| 17:53 | <annevk> | smaug: "canvas MouseEvent rerouting steps" |
| 17:53 | <smaug> | annevk: I thought it monkey patches hit testing (which isn't defined anywhere) |
| 17:54 | smaug | reads again |
| 17:54 | <annevk> | smaug: ah yeah, I guess it's more general than just the click action |
| 19:36 | <smaug> | could anyone interpret https://html.spec.whatwg.org/multipage/forms.html#interactively-validate-the-constraints to me |
| 19:36 | <smaug> | "If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error." |
| 19:37 | <smaug> | or in general, what is the expected behavior when elements are hidden |
| 19:55 | <smaug> | mounir: ping |
| 22:12 | <mounir> | smaug: pong |
| 22:13 | <smaug> | mounir: who might know about blink's form validation stuff? |
| 22:13 | <mounir> | I would try tkent |
| 22:13 | <mounir> | he would be the best point of contacts for forms |
| 22:13 | <mounir> | smaug: if it's a quick question, I can read the code :) |
| 22:15 | <smaug> | mounir: unfortunately I don't have a good question yet. It seems like blink doesn't always validate type=url, but I don't quite understand the bug yet |
| 22:15 | <smaug> | could be just some web site issue too |
| 22:17 | <mounir> | can't help much indeed :) |
| 22:24 | <mounir> | fwiw, the invalidity check looks very simple |