| 01:46 | <a-ja> | can anyone think of a reason why validator should consider require-sri-for in csp header to be an error? |
| 01:50 | <MikeSmith> | a-ja: possibly because I haven't updated the validator with the latest spec changes |
| 01:51 | <MikeSmith> | 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 |
| 01:52 | <MikeSmith> | https://github.com/shapesecurity/salvation |
| 01:53 | <a-ja> | MikeSmith, ....looking |
| 01:54 | <a-ja> | issue 144 fixed 3 months ago, eh? |
| 01:58 | <MikeSmith> | Yeah I'm using version 2.0.1, which was released in February |
| 02:00 | <MikeSmith> | please file an issue at https://github.com/validator/validator/issues if you have time |
| 02:00 | <a-ja> | MikeSmith, think I'll pass that URL on to April King for possible use at observatory.mozilla.org |
| 02:03 | <MikeSmith> | Ah yeah I like that Observatory thing |
| 02:03 | <a-ja> | MikeSmith, https://github.com/validator/validator/issues/382 |
| 02:03 | <MikeSmith> | But Observatory already does CSP header checking, right? |
| 02:04 | <MikeSmith> | thanks for raising the issue |
| 02:04 | <a-ja> | MikeSmith, found a csp parser error with it the other day....which is why i thought of it now |
| 02:04 | <MikeSmith> | Ah |
| 02:04 | <a-ja> | it's been fixed |
| 02:05 | <MikeSmith> | Ok |
| 02:07 | <MikeSmith> | I will try to update the validator to the latest Salvation version today |
| 02:08 | <MikeSmith> | and hope they did not make any breaking changes to their API that will require me to rewrite my code |
| 02:10 | <a-ja> | MikeSmith, sorry....got a call. sounds good. tks |
| 06:48 | <tobie> | can't agree more with jyasskin. Nothing beats a PR, and new issues show up as you start writing things down. |
| 07:13 | <annevk> | That is kinda why we keep discussing things there |
| 09:51 | <tobie> | 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. |
| 09:55 | <heycam> | tobie: I need to move it to an org to be able to do that |
| 09:56 | <tobie> | heycam: oh, really? That sucks. |
| 09:56 | <heycam> | tobie: yeah :( |
| 09:56 | <heycam> | tobie: I can either add a hook now for you, or we can discuss moving again ... |
| 09:57 | <tobie> | heycam: I'll look into the hook url and payloads I need. |
| 09:57 | <tobie> | heycam: you're still around for a little bit? |
| 09:57 | <heycam> | tobie: ok thanks, sorry for the inconvenience |
| 09:58 | <heycam> | tobie: no I have to leave the office about now :) |
| 09:59 | <tobie> | heycam: ok, will email you later so you get this by tomorrow morning |
| 09:59 | <heycam> | tobie: no problem, will add them first thing in the morning |
| 09:59 | <tobie> | ty |
| 11:43 | <smaug> | could someone explain why there are MessageEvent and ServiceWorkerMessageEvent interfaces? |
| 11:47 | <annevk> | smaug: I think primarily because source could be something else |
| 11:47 | <annevk> | smaug: I suggested we should just merge those though |
| 11:48 | <smaug> | yeah, feels a bit silly to have similar events |
| 11:48 | <smaug> | which are now even inconsisten |
| 11:48 | <smaug> | t |
| 11:48 | <smaug> | one accepting null ports, one doesn't |
| 11:48 | <smaug> | etc |
| 11:49 | <annevk> | smaug: it seems like Hixie_ blocked it in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28199 |
| 11:49 | <annevk> | smaug: well, he didn't really |
| 11:49 | <annevk> | smaug: it seems nobody studied that in sufficient detail :/ |
| 11:50 | <annevk> | "studied" |
| 11:50 | <smaug> | filed https://github.com/w3c/ServiceWorker/issues/989 |
| 11:51 | <smaug> | of course there is also https://github.com/w3c/ServiceWorker/issues/988 |
| 11:51 | <annevk> | smaug: oh, I filed https://github.com/w3c/ServiceWorker/issues/990 |
| 11:52 | <annevk> | smaug: ok, marked mine as dupe |
| 11:53 | <smaug> | I wonder what to implement now |
| 11:53 | <smaug> | whether .ports should be nullable or not |
| 11:54 | <smaug> | (or in other words, whether I can review+ the patch which makes MessageEvent to follow the latest spec) |
| 11:58 | <annevk> | I think so, unless there's some weird reason we can't change ServiceWorkerMessageEvent |
| 11:58 | <annevk> | But that seems unlikely |
| 11:58 | <smaug> | not sure |
| 11:58 | <smaug> | or, hmm |
| 11:59 | <smaug> | is the ServiceWorkerMessageEvent.ports always set to some value when UA dispatches those events |
| 12:01 | <smaug> | I guess so |
| 12:01 | <smaug> | at least to [] |
| 12:45 | <annevk> | 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/? |
| 12:55 | <smaug> | this focusin/out is such a nice mess too :) |
| 12:56 | <annevk> | smaug: sigh yes |
| 13:02 | <smaug> | in blink it is possible to have events for the same target in order: blur, focus, focusin, focusout |
| 13:02 | <smaug> | and after that the element is focused |
| 13:02 | <smaug> | even though the last even it got was focusout |
| 13:03 | <annevk> | This is what you get when UI events refuses to define a processing model for years on end |
| 13:03 | <annevk> | 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 |
| 13:04 | <smaug> | well, this isn't even UI events |
| 13:05 | <smaug> | this is webkit/blink implementing something totally random |
| 13:05 | <smaug> | against even those vague hints UI events spec have about the behavior |
| 13:08 | <annevk> | The other problem with focus is that it's in part defined by HTML |
| 13:12 | <annevk> | smaug: pre and post-click-dispatch steps |
| 13:12 | <annevk> | smaug: is that basically an extra iteration over event's path? |
| 13:12 | <annevk> | smaug: before we call any listeners, and after all listeners are invoked? |
| 13:12 | <annevk> | smaug: and we only do after if the canceled flag is still unset? |
| 13:12 | <smaug> | so in Gecko "pre" is about creating path |
| 13:13 | <smaug> | we may do some other stuff there too |
| 13:13 | <smaug> | like that type=checkbox state change |
| 13:13 | <annevk> | yeah, that would become part of pre-click-dispatch |
| 13:13 | <annevk> | is there anything else? |
| 13:13 | <smaug> | and post is using the path, and is a separate iteration after normal dispatch |
| 13:13 | <annevk> | I guess it could be combined with creating the path, but it doesn't necessarily have to be |
| 13:15 | <smaug> | (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) |
| 13:15 | <rbyers> | 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. |
| 13:15 | <annevk> | rbyers: it's really hard to write comprehensive tests if you don't know the processing model |
| 13:16 | <smaug> | rbyers: you can't really have good implementations without specs |
| 13:16 | <annevk> | rbyers: considering them each in isolation is somewhat problematic |
| 13:16 | <rbyers> | Right we need to do them all together |
| 13:16 | <smaug> | (and yes, having good specs require 2-3 implementations at leasts) |
| 13:16 | <annevk> | rbyers: and why many efforts fail (e.g., the one around contenteditable which also focused only on tests) |
| 13:16 | <rbyers> | We can write tests from the perspective of what developers expect to happen / what sites are relying on today. |
| 13:17 | <rbyers> | I agree it would be a mistake to focus only on tests |
| 13:17 | <annevk> | that's way too simplistic, imo |
| 13:17 | <rbyers> | But in the UI events space tests have been almost entirely neglected. |
| 13:17 | <rbyers> | So we have a lot of catch-up to do there before all three can really evolve together |
| 13:17 | <annevk> | tests and impls have too |
| 13:17 | <annevk> | specs and impls have too* |
| 13:18 | <annevk> | nothing there has meaningfully improved for a long time |
| 13:18 | <annevk> | I'm extremely skeptical you can write comprehensive tests by studying what websites do |
| 13:19 | <rbyers> | Not in isolation, no of course not |
| 13:19 | <smaug> | yeah, without some model one will miss tons of edge cases in tests |
| 13:19 | <rbyers> | We have some model in the spec today, it's just weak |
| 13:20 | <rbyers> | I'm not opposed to someone rewriting the spec to make more sense if one of you is volunteering ;-) |
| 13:20 | <annevk> | There's no real model in the spec imo |
| 13:20 | <annevk> | I guess at some point someone will have to, since the current approach doesn't seem to be working |
| 13:21 | <annevk> | And it's starting to hurt other things |
| 13:21 | <rbyers> | (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) |
| 13:21 | <annevk> | It's a little annoying that all the cleaning up falls to us |
| 13:22 | <smaug> | 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. |
| 13:22 | <annevk> | rbyers: if it actually falls to me I'll do it somewhere where I'm comfortable |
| 13:23 | <rbyers> | It's not true that there haven't been real improvements here BTW |
| 13:23 | <rbyers> | mouseover/out/enter/leave behavior used to be completely different between a number of engines |
| 13:23 | <rbyers> | and we saw real world bugs as a result |
| 13:24 | <rbyers> | the spec got more precise and blink overhauled it's behavior to match. Now blink, gecko and Edge are at least pretty consistent. |
| 13:25 | <rbyers> | 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 |
| 13:27 | <smaug> | 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. |
| 13:27 | <smaug> | I guess we should document somewhere the behavior |
| 13:27 | <smaug> | (well, there will be some wpts) |
| 13:28 | <rbyers> | ugh |
| 13:28 | <rbyers> | Please cc dtapuska on your plans in gecko - he's leading a new engineer in trying to fix our behavior. |
| 13:28 | <smaug> | all these events are so regression prone. |
| 13:29 | <rbyers> | So if the spec'd behavior isn't web compatible, then it would be good to know that.... |
| 13:29 | <smaug> | rbyers: but, if you're actively now fixing the bugs and possibly even making focusin/out follow the spec, Gecko would do that too |
| 13:29 | <rbyers> | Ah, good. Yeah it's happening just taking time while some new folks ramp up |
| 13:30 | <smaug> | rbyers: I guess only MS might know whether the spec'ed behavior is web compatible |
| 13:30 | <smaug> | since they had it something like that in EI |
| 13:30 | <smaug> | but switched to closer to webkit/blink model in Edge |
| 13:33 | <Ms2ger> | "We're starting on the (hopefully not too convoluted) process of updating the Cookies RFC" |
| 13:34 | <Ms2ger> | Lol |
| 13:36 | <smaug> | lunch |
| 14:04 | <wanderview> | JakeA: are we re-creating cookies for this issue? https://github.com/w3c/ServiceWorker/issues/920#issuecomment-252657496 |
| 14:04 | <wanderview> | an origin scoped thing that gets set on network requests automatically |
| 14:05 | <wanderview> | by "thing" I mean header |
| 14:05 | <wanderview> | obviously there are some differences too... but the similarities we striking to me reading through the last few comments there |
| 14:06 | <JakeA> | wanderview: yep. I'm a little sad about that. See https://github.com/w3c/ServiceWorker/issues/920#issuecomment-245621515 and the following few comments |
| 14:07 | <JakeA> | It certainly makes the API less tidy |
| 14:07 | <wanderview> | 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?) |
| 14:08 | <wanderview> | I dunno, just a random though |
| 14:08 | <wanderview> | thought |
| 14:12 | <JakeA> | wanderview: https://github.com/w3c/ServiceWorker/issues/920#issuecomment-247144874 is Facebook's objection |
| 14:13 | <wanderview> | 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) |
| 14:13 | <annevk> | Domenic: the "initialized" pattern you like so much stems from the lack of internal slots |
| 14:14 | <annevk> | 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 |
| 14:14 | <JakeA> | wanderview: I'm open to that. It's very specific right now though, it's specifically these preload requests |
| 14:15 | <annevk> | wanderview: avoid cookies because? |
| 14:15 | <wanderview> | annevk: see JakeA's link to FB's objection to cookies |
| 14:16 | <JakeA> | annevk: https://github.com/w3c/ServiceWorker/issues/920#issuecomment-247144874 this is what Nate from Facebook was talking about at the F2F |
| 14:16 | <annevk> | wanderview: sorry, I meant to ask why you'd like to avoid that |
| 14:16 | <wanderview> | 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 |
| 14:19 | <wanderview> | 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?) |
| 14:19 | <JakeA> | wanderview: I hadn't thought much about it. I guess it could count towards origin storage |
| 14:20 | <wanderview> | 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? |
| 14:20 | <JakeA> | wanderview: no it's async |
| 14:20 | <wanderview> | ok, good |
| 14:20 | <wanderview> | thanks |
| 14:21 | wanderview | was thinking of fxos code that stuck pre-rendered HTML for the page in a cookie for fast first load. |
| 14:21 | <JakeA> | hah |
| 14:23 | <wanderview> | 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 |
| 14:23 | <annevk> | wanderview: I see, but this has none of that |
| 14:23 | <annevk> | wanderview: main problem with cookies imo is that they're not origin-bound, which this is |
| 14:24 | <wanderview> | ok... I was not saying to use cookies... |
| 14:24 | <JakeA> | Also they only want it sent on the preloads |
| 14:29 | <wanderview> | 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 |
| 14:29 | <wanderview> | JakeA: although maybe this is just a consequence of not going whole hog on static routing |
| 14:30 | wanderview | wonders if Europeans understand the phrase "whole hog". |
| 14:32 | <wanderview> | oh... it seems its common in Britain as well: https://britishhogroasts.co.uk/go-the-whole-hog/ |
| 14:41 | <JakeA> | wanderview: since the preload is a service worker thing, it makes sense to tie it to the registration (like push subscriptions) |
| 14:41 | <JakeA> | wanderview: I think static routes will end up being tied to the service worker rather than the registration fwiw |
| 14:41 | <JakeA> | 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 |
| 14:42 | <wanderview> | JakeA: I think the same could be said about Cache API... but we made it its own thing... just seems similar to me |
| 14:43 | <JakeA> | wanderview: we nearly made caches tied to a sw, but it became really ugly when you wanted a cache to last longer |
| 14:44 | <JakeA> | 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 |
| 14:45 | <wanderview> | 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 |
| 14:46 | <JakeA> | 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? |
| 14:48 | <wanderview> | 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 |
| 14:49 | <wanderview> | JakeA: but this is all just brainstorming... I'm not really objecting to the current API proposal |
| 14:50 | <JakeA> | 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 |
| 14:50 | <JakeA> | But I suppose there's no point in a nice API if it isn't useful |
| 14:51 | <wanderview> | 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 |
| 14:51 | <wanderview> | similar to how you can load Cache objects from window today |
| 14:51 | <JakeA> | wanderview: I think that would clash with having multiple registrations on the same origin |
| 14:52 | <wanderview> | JakeA: well, the API would need some kind of URL matching... perhaps the same matching algorithm specified by Cache API |
| 14:53 | <wanderview> | but maybe the intent is really to glob resources under the scope |
| 14:53 | <wanderview> | I dunno... again... just random thoughts |
| 14:55 | <JakeA> | 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 |
| 14:58 | <wanderview> | JakeA: I'm thinking something like this: https://gist.github.com/wanderview/d268442914398a66613682957dd2f8ff |
| 15:00 | <JakeA> | wanderview: how would that only relate to preload requests? |
| 15:06 | <wanderview> | JakeA: let met add that now... someone was at the door |
| 15:08 | <wanderview> | JakeA: ok, reload the gist |
| 15:09 | <JakeA> | wanderview: ohhh, that's actually pretty neat |
| 15:09 | <wanderview> | JakeA: using the http cache matching semantics doesn't really provide scope-like path matching, though |
| 15:10 | <wanderview> | but that could be adapted in some way |
| 15:11 | <wanderview> | although for Cache API we set substring matching was a de-opt |
| 15:11 | <wanderview> | and removed it |
| 15:11 | <wanderview> | ^set^said |
| 15:12 | <JakeA> | Hah, I was just trying to remember what we called that option |
| 15:13 | <wanderview> | woah... shots fired at npm https://code.facebook.com/posts/1840075619545360 |
| 15:13 | <JakeA> | 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. |
| 15:13 | <wanderview> | JakeA: np, have a good night! (I assume you were still thinking about Sunday's debate in the US!) |
| 15:14 | <wanderview> | I'll stick the idea in the github issue |
| 15:56 | <wanderview> | 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? |
| 15:56 | <wanderview> | JakeA: ^^^ |
| 15:57 | <wanderview> | I'll file an issue to clarify |
| 16:00 | <wanderview> | annevk: JakeA: filed this... https://github.com/w3c/ServiceWorker/issues/991 |
| 16:13 | <annevk> | wanderview: dunno, will study later |
| 17:23 | <annevk> | wanderview: sooo, briefly looked at the Cache API algorithms |
| 17:23 | <annevk> | wanderview: they appear broken |
| 17:27 | <wanderview> | annevk: ok, we'll have to discuss with JakeA tomorrow I guess |
| 17:27 | <annevk> | wanderview: yeah, we basically shouldn't be invoking IDL operations |
| 17:27 | <annevk> | wanderview: and definitely not from algorithms that run "in parallel" |
| 17:28 | <annevk> | wanderview: but I also think HTTP doesn't just look at the first header |
| 17:28 | <annevk> | wanderview: for HTTP there's no difference between multiple headers or one header with a comma-separated value |
| 17:28 | <annevk> | wanderview: except for cookies (another reason folks dislike them) |
| 17:29 | <gsnedders> | how does "Add links to tests from requirements (beta)" work? |
| 21:04 | <Domenic> | TabAtkins: where's you and fantasi's old old form control styling proposal? |
| 21:48 | <hober> | Domenic: here's my handwavy one from a few years ago https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html |
| 21:49 | <Domenic> | hober: oh cool, thanks! |
| 21:49 | <hober> | np |