| 00:11 | <gsnedders> | nox: eh, location we need some big discussion about with a bunch of us to decide what we actually want to do with it |
| 00:12 | <gsnedders> | nox: I think we've long ago concluded that the error messages are mostly for helping understand the test rather than meaningful at all |
| 00:13 | <gsnedders> | nox: tl;dr: for now you're best treating the errors as documented, i.e., only the number of lines matters |
| 01:19 | <MikeSmith> | annevk: seems like I probably just that favicon file in my working directory untracked and wound up adding and it committing it by mistake |
| 01:19 | <MikeSmith> | anyway, deleted now |
| 01:32 | <MikeSmith> | annevk: also deleted whatwg.png |
| 05:31 | <annevk> | MikeSmith: ah ok, takk |
| 06:18 | <jamesr___> | jgraham: servo doesn't seem to render http://smfr.org/misc/css/stacking/css-escher.html correctly |
| 06:20 | <jamesr___> | do you plan to implement that insanity? (i think it's required for web compat, but who knows) |
| 06:26 | <annevk> | jamesr___: SimonSapin might be a better target for that question |
| 07:19 | <MikeSmith> | I seem to recall some mention here a while back of somebody working on Navigation Transistions again |
| 07:19 | <MikeSmith> | but can't remember who |
| 07:21 | <MikeSmith> | Chris Lord it seems |
| 07:25 | <MikeSmith> | http://cwiiis.github.io/gaia-navigator/ |
| 07:25 | <MikeSmith> | that wasn't very easy to fine |
| 07:29 | <annevk> | Hmm, is there a simple command line tool that checks whether a file is valid JSON? |
| 07:30 | <annevk> | We now publish https://resources.whatwg.org/biblio.json and since it's draconian it's rather easy to mess up |
| 07:36 | <annevk> | Also, whoever is next with a new standard, please start with an "A" or "G", "I", "K", "O", "P", "R", "T", "V", "W", or "Z" |
| 07:47 | <MikeSmith> | annevk: https://github.com/zaach/jsonlint maybe |
| 07:48 | <MikeSmith> | oh Zach Carter |
| 08:02 | <kochi> | If script calls "input.focus()", is the generated focusin event a 'trusted' event? |
| 08:03 | <kochi> | (background: for writing an automated test, I'm wondering if any way to dispatch 'trusted' event from scripts) |
| 08:03 | <kochi> | http://www.w3.org/TR/2015/WD-uievents-20150428/#trusted-events says |
| 08:04 | <kochi> | "Events that are generated by the user agent, either as a result of user interaction, or as a direct result of changes to the DOM, are trusted" |
| 08:06 | <kochi> | Chrome hasn't implemented the property so far, anyway |
| 08:07 | <kochi> | According to https://developer.mozilla.org/en/docs/Web/API/Event/isTrusted even Firefox and IE are differently implemented |
| 08:09 | <smaug____> | kochi: that mdn page is a bit odd |
| 08:09 | <smaug____> | events created by scripts in web pages are untrusted |
| 08:10 | <smaug____> | not sure what that comment about IE tries to say |
| 08:10 | <annevk> | smaug____: is click() untrusted as well? |
| 08:10 | <smaug____> | or does IE have some bizarre behavior for element.click() |
| 08:10 | <annevk> | yeah I guess it better be |
| 08:10 | <SimonSapin> | jamesr___: Interesting. I filed https://github.com/servo/servo/issues/7293 |
| 08:10 | <smaug____> | click() does create untrusted event |
| 08:11 | <kochi> | hmm, if click() creates untrusted event, it sounds natural to think focus() creates untrusted event. |
| 08:12 | <smaug____> | well click() just dispatches click event |
| 08:12 | <smaug____> | focus() focuses something and that ends up dispatching focus event |
| 08:13 | <smaug____> | (what the spec says about click() is IIRC very different to what all the implementations do) |
| 08:15 | <annevk> | "Fire a click event at the element. If the run synthetic click activation steps algorithm was invoked because the click() method was invoked, then the isTrusted attribute must be initialised to false." |
| 08:15 | <annevk> | seems about right |
| 08:16 | <smaug____> | well, implementations trigger the activation steps during event dispatch |
| 08:17 | <smaug____> | which is why manually dispatching untrusted click event should behave as if click() was called |
| 08:28 | <kochi> | Can a focus event as a result of focus() invocation be though of "a direct result of changes to the DOM"? |
| 08:28 | <kochi> | I guess this part of the sentence is still ambiguos about "who" makes the changes to the DOM, can it be a script? |
| 08:31 | <Ms2ger> | Context? |
| 08:31 | <botie> | hmmm... Context is https://github.com/validator/validator/issues/61 |
| 08:32 | <Ms2ger> | What |
| 08:32 | <kochi> | Ms2ger botie: my context is https://github.com/w3c/webcomponents/issues/293 |
| 08:33 | <Ms2ger> | I have no idea what "closed" even means there |
| 08:33 | <kochi> | I am trying to make a automated test case, but the spec depends on an event to be "trusted", so |
| 08:33 | <kochi> | I was wondering any way I can make a trusted event from script. |
| 08:33 | <kochi> | "closed" means a closed mode shadow root. |
| 08:34 | <kochi> | oops, wrong reference |
| 08:34 | <annevk> | you can't get trusted from script |
| 08:34 | <kochi> | my context is https://github.com/w3c/web-platform-tests/pull/2099 |
| 08:34 | <annevk> | kochi: you probably want to talk to jgraham but it seems that'd require some kind of web driver test |
| 08:35 | <kochi> | okay, so we have to use manual test to generate trusted events? |
| 08:35 | <kochi> | or web driver... |
| 08:36 | <Ms2ger> | And web driver doesn't really work yet, I don't think :/ |
| 08:36 | <Ms2ger> | smaug____, you know if there's a test for click()'s event being untrusted in wpt? |
| 08:37 | <smaug____> | no idea |
| 08:38 | Ms2ger | goes and writes one |
| 08:38 | <kochi> | cool |
| 08:39 | <kochi> | html/editing/focus/focus-management/focus-events.html seems to assume that focus() generates focus event whose isTrusted is true. |
| 08:39 | <annevk> | kochi: mind filing a bug on that? |
| 08:39 | <kochi> | sure |
| 08:40 | <annevk> | kochi: it seems the HTML Standard does say that focus events are always trusted |
| 08:41 | <annevk> | kochi: at least, quickling going through the various algorithms focus() invokes seems to say that |
| 08:41 | <annevk> | kochi: so there might be bug in the HTML Standard too :-/ |
| 08:41 | <smaug____> | focus event is trusted if the focus actually moved |
| 08:42 | <smaug____> | click() and focus() behave quite differently |
| 08:42 | <Ms2ger> | "When a user agent is required to fire a focus event named e at an element t and with a given related target r, the user agent must create a trusted FocusEvent object" |
| 08:42 | <annevk> | right |
| 08:42 | <annevk> | smaug____: o_O |
| 08:43 | <smaug____> | annevk: click() dispatches click event which triggers the activation |
| 08:43 | <annevk> | okay, kochi, apologies, ignore what I said above, and ask smaug____ instead |
| 08:43 | <smaug____> | focus() tries to focus some element, and focusing that element then dispatches focus event |
| 08:44 | <smaug____> | so the focus event is a result of focus() causing focus change |
| 08:45 | <kochi> | So focus event is considered "a direct result of changes to the DOM", and it is trusted. |
| 08:46 | <smaug____> | something like that yes. focus event is fired after some state change |
| 08:47 | <annevk> | wanderview: I fixed 112, anything else you want me to look at soonish? |
| 08:47 | <Ms2ger> | r? https://github.com/w3c/web-platform-tests/pull/2100 |
| 08:51 | <annevk> | Ms2ger: r+ |
| 08:52 | smaug____ | would have reviewed but didn't know how |
| 08:52 | <annevk> | an IRC comment worked last time |
| 08:53 | <Ms2ger> | For something this small, it doesn't really matter |
| 08:53 | <smaug____> | I see |
| 08:53 | <kochi> | I can merge now |
| 08:54 | <kochi> | mm "Merge attempt failed" |
| 08:54 | <kochi> | ah, you did yourself |
| 08:54 | <Ms2ger> | I did |
| 09:03 | <kochi> | smaug____ annevk Ms2ger: thanks all, I replied in https://github.com/w3c/web-platform-tests/pull/2099 |
| 09:23 | <annevk> | kochi: I recommend using https://html.spec.whatwg.org/multipage/ as definitive reference |
| 09:23 | <annevk> | kochi: I believe that's what both Google and Mozilla at least attempt to implement |
| 09:31 | <smaug____> | Indeed. I wouldn't refer to W3C's HTML5* |
| 09:36 | <kochi> | annevk: thanks, updated. |
| 09:38 | kochi | will keep in mind |
| 09:38 | smaug____ | wonders who got the "great" idea to try to merge webapps and html wg |
| 11:52 | <wanderview> | annevk: can you explain what you meant in the issue by "Otherwise cross-origin to same-origin would not be covered"? |
| 11:53 | <MikeSmith> | annevk: as far as railroad diagrams in the URL spec, the plan is that they'd be non-normative, right? |
| 11:53 | <MikeSmith> | https://github.com/whatwg/url/issues/67 I mean |
| 11:54 | <MikeSmith> | I'm pretty certain that is the plan but I would still like to be reassured |
| 11:57 | <wanderview> | annevk: if its cross-origin, shouldn't all future redirect origins be considered "cross-origin" since the request origin is marked as being an opaque value? |
| 12:13 | <wanderview> | I commented in the bug |
| 12:24 | <annevk> | wanderview: say request's origin X and request's current URL's origin is Y |
| 12:24 | <annevk> | wanderview: then you get a redirect that also has origin Y for locationURL |
| 12:24 | <annevk> | wanderview: that scenario would not be covered |
| 12:24 | <annevk> | MikeSmith: yes |
| 12:25 | <annevk> | MikeSmith: normative prose, plus some kind of grammar production thingie to skim through |
| 12:26 | <MikeSmith> | annevk: ok, good to hear |
| 12:26 | <wanderview> | annevk: hmm... I have to step away... but let me think about that... I don't see how CORS flag is set in that case either |
| 12:29 | <annevk> | wanderview: because main fetch would invoke basic fetch with it set because current URL's origin is not same origin with request's origin |
| 12:30 | <wanderview> | annevk: but what about origin X redirect to Y redirect to X... the second X should be considered cross-origin, right? |
| 12:30 | <wanderview> | where is CORS flag set in that chain in time to mark the opaque origin? |
| 12:32 | <wanderview> | I think CORS flag is set after the first redirect (but too late to set the opaque origin) |
| 12:34 | <wanderview> | but I guess maybe thats ok since the opaque origin is set on next redirect before evaluating main fetch again |
| 12:38 | <nox> | annevk: Does the generator for that diagram syntax already exist? |
| 13:23 | <annevk> | nox: yeah, part of Bikeshed |
| 13:23 | <nox> | annevk: Nice. |
| 13:23 | <annevk> | wanderview: right |
| 15:36 | <wanderview> | JakeA++ for "poomorphism" |
| 15:36 | <JakeA> | :D |
| 16:46 | <igrigorik> | annevk: ping :) |
| 16:48 | <annevk> | igrigorik: hey |
| 16:48 | <igrigorik> | https://fetch.spec.whatwg.org/#concept-request - seems to be missing frame-src.. is that intentional? |
| 16:49 | <annevk> | igrigorik: yeah, the idea is that CSP can look at request's client |
| 16:49 | <annevk> | igrigorik: it says as much underneath the table |
| 16:50 | <igrigorik> | ah, figures. that makes sense - thanks. |
| 16:55 | <igrigorik> | annevk: back to our favorite topic of preload :) ... Looking at this new table, I think I can map preload's "as" to {initiator: '', type: as-value, destination: 'subresource'}. that would make preload fetches subject to all the right CSP policies based on specified as type. |
| 16:55 | <igrigorik> | annevk: does that make sense? anything I'm overlooking? |
| 16:55 | <annevk> | yes, security |
| 16:55 | <botie> | security is, like, still what we have the address bar for, navigating based on hacking the URL space not so much |
| 16:56 | <annevk> | heh |
| 16:56 | <annevk> | igrigorik: it needs to be a new thing, but what would be good to see first is preload's processing model in terms of Fetch |
| 16:56 | <annevk> | I don't think we have that yet |
| 16:57 | <annevk> | mkwst said as much anyway in the issue were we added initiator/destination/type |
| 16:59 | <igrigorik> | annevk: preload is <link>, the processing model for which is in the HTML spec itself (https://html.spec.whatwg.org/multipage/semantics.html#the-link-element). I've intentionally stayed away from duplicating that.. |
| 17:01 | <annevk> | igrigorik: I don't understand, HTML doesn't define what preload does |
| 17:02 | <annevk> | igrigorik: see e.g., what HTML defines for "stylesheet" |
| 17:02 | <annevk> | igrigorik: and how that further defers to "creating a stylesheet" etc. which is defined elsewhere |
| 17:12 | <igrigorik> | annevk: right but that's once response is received. by default all of the link's use http://www.w3.org/TR/html5/document-metadata.html#concept-link-obtain to obtain the resource, which is what current preload spec is relying on as well. are you suggesting I pull that out and explicitly define it within preload spec? |
| 17:13 | <annevk> | Where is it stated that all use that? |
| 17:13 | <annevk> | Also, where is it stated that an <img> fetch pulls something out of the preload cache? |
| 17:14 | <annevk> | And where in fetch that cache lookup happens and how? |
| 17:17 | <annevk> | igrigorik: anyway, as far as I know you do need to have a section similar to the "stylesheet" section HTML has |
| 17:17 | <annevk> | igrigorik: and you need a section that monkey patches Fetch and a section that defines the preload cache |
| 17:18 | <annevk> | igrigorik: and then you have a feature that's maybe hopefully defined from first principles |
| 17:19 | <igrigorik> | annevk: perhaps I'm reading it wrong but, the main definition of <link> specifies steps 'to obtain the resource', and none of the other sections (e.g. stylesheet) elaborate further.. e.g. stylesheet specifies 'when to obtain' and what to do 'once obtained'. Hence my comment about all rel's relying on same steps to fetch. |
| 17:21 | <igrigorik> | annevk: re, section: most of that content is already there in the preload spec, perhaps I could shuffle it a bit to make it more clear. the one thing that's unclear to me is whether I now should define my own 'obtain resource' algorithm to work with the new Fetch.. such that I can set initiator/type/destination. |
| 17:22 | <annevk> | igrigorik: right, once you define https://html.spec.whatwg.org/multipage/semantics.html#linkTypes you get the obtain the resource for free, but you still need to define what the UA needs to do with the obtained resource, as the "stylesheet" rel does, for instance |
| 17:23 | <igrigorik> | annevk: yes, fair enough. that's where I need to define the 'preload cache' or some such. |
| 17:23 | <annevk> | igrigorik: and yeah, since you want something different you might need your own obtain the resource algorithm... (though HTML will be modified to use Fetch in due course, you probably still want something slightly different here) |
| 17:23 | <annevk> | igrigorik: yup |
| 17:24 | <annevk> | igrigorik: so preload is in https://w3c.github.io/preload/ |
| 17:24 | <annevk> | igrigorik: where are prefetch/prerender? |
| 17:25 | <igrigorik> | annevk: https://w3c.github.io/resource-hints < these are speculative and have different processing model, which is why we split them into separate spec |
| 17:25 | <annevk> | igrigorik: ait |
| 17:26 | <annevk> | whoa |
| 17:26 | <annevk> | igrigorik: without the trailing slash you end up on http:// |
| 17:26 | <annevk> | igrigorik: that seems like a serious GitHub bug |
| 17:27 | <igrigorik> | annevk: oh wow, that's a.. fun one =/ |
| 17:28 | <annevk> | I'll let them know |
| 17:29 | <igrigorik> | annevk: re, preload + obtain the resource: ok, it sounds like I should define my own in preload. Drilling in on that specifically, in there when I initialize the request I'd set the new fetch request properties to {initiator: '', type: as-value, destination: 'subresource'} -- ya? |
| 17:30 | <igrigorik> | annevk: where 'as-value' is one of https://fetch.spec.whatwg.org/#concept-request-type |
| 17:30 | <annevk> | yes, except you cannot overwrite type for security reasons |
| 17:30 | <annevk> | most likely |
| 17:30 | <annevk> | so we'd have to introduce a new axis that's the same as type except not used by CSP |
| 17:30 | <annevk> | gotta go |
| 17:34 | <igrigorik> | annevk: hmm, but in this case I do want these fetches to be subject to relevant CSP policies. For preload in particular I think it should be fine to set those: fetch initiated by preload is subject to set type+CSP policies, and there is no way to consume the response directly -- that goes into preload cache (to be defined :)). To consume it you need another |
| 17:34 | <igrigorik> | fetch to retrieve it from the cache, which will enforce its CSP rules as well. |