| 00:09 | <Domenic> | I believe the proper term is Web Hypertext Application Technologies Un-Plenary |
| 00:09 | <Domenic> | wait no it was Unconference Plenary |
| 00:33 | <tantek> | Domenic++ |
| 00:33 | <TabAtkins> | +1 |
| 05:55 | <annevk> | rniwa++ for tests |
| 06:03 | <rniwa> | annevk: :) |
| 06:03 | <rniwa> | annevk: i've got a few dozens of tests for shadow DOM and custom elements now: |
| 06:04 | <rniwa> | https://github.com/WebKit/webkit/tree/master/LayoutTests/fast/shadow-dom |
| 06:04 | <rniwa> | https://github.com/WebKit/webkit/tree/master/LayoutTests/fast/custom-elements |
| 06:35 | <philipj_> | annevk: I don't like having prefixes to the commit messages, it uses up valuable space. So I'm also not a fan of "Fix #100:" and like to put this in the description |
| 09:46 | <rniwa> | Domenic: yt? |
| 09:53 | <annevk> | rniwa: it's nearly 5AM if he isn't traveling |
| 10:03 | <zcorpan> | mutation events :-| ... https://www.chromestatus.com/metrics/feature/timeline/popularity/144 at least it's going down |
| 10:05 | <annevk> | I'm hoping esprehn can change the timing of mutation events |
| 10:05 | <annevk> | If that's feasible we should just add them to the standard and forget about them |
| 10:14 | <annevk> | Looks like I'm going to standardize port banning today ๐ |
| 10:14 | <zcorpan> | https://www.chromestatus.com/metrics/feature/timeline/popularity/146 DOMNodeRemovedFromDocument is at 0.0086% now |
| 10:29 | <smaug____> | Hmm, there was some discussion about hitregions in some github bug recently... anyone happen to recall which bug it was |
| 10:29 | <smaug____> | not https://github.com/whatwg/html/issues/849 but some other |
| 10:29 | <smaug____> | (and could we move issue tracking back to some bugzilla instance) |
| 10:31 | <zcorpan> | miketaylr: fyi https://lists.w3.org/Archives/Public/www-style/2016Feb/0169.html |
| 10:32 | <smaug____> | ok, found it. https://github.com/whatwg/html/issues/548 |
| 11:19 | <annevk> | smaug____: we cannot, we migrated away from Bugzilla |
| 11:25 | <annevk> | smaug____: so your suggestion for hit regions is to make the hit region object (is there such a thing?) inherit from EventTarget? |
| 11:26 | <annevk> | smaug____: seems somewhat reasonable |
| 11:26 | <annevk> | smaug____: would its "get the parent" return the <canvas> it's associated with? |
| 11:28 | <smaug____> | I don't think I suggested that |
| 11:31 | <smaug____> | annevk: I'm talking more about these steps: "Let control be the control represented by region for this canvas element, if any." ... "If there is a control, then target the event object at control instead of the canvas element." |
| 11:32 | <smaug____> | so we already dispatch the event on the "hit region control" |
| 11:32 | <smaug____> | and event.region == event.target.id |
| 11:32 | <smaug____> | or something like that |
| 11:33 | <annevk> | Seems indeed redundant then |
| 11:34 | <smaug____> | but Touch handling is something different |
| 11:36 | <smaug____> | but I think mostly the whole .region stuff is busted. |
| 11:36 | <smaug____> | whoever designed the API could explain why it is the way it is |
| 11:37 | <annevk> | I think Hixie_ designed it |
| 13:05 | <zcorpan> | annevk: random thought: it seems slightly weird to have "should" in a defined term |
| 13:12 | <Ms2ger> | mix and csp do the same |
| 13:37 | <zcorpan> | i see Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits as a request header in opera |
| 13:39 | <zcorpan> | and .extensions returns "permessage-deflate" |
| 14:08 | <annevk> | zcorpan: that is weird |
| 14:08 | <annevk> | zcorpan: ugh |
| 14:09 | <annevk> | zcorpan: file an issue? That requires a bunch of changes to various drafts |
| 14:09 | <zcorpan> | ok |
| 14:41 | <annevk> | zcorpan: did you work on WebSocket tests? |
| 14:41 | <annevk> | zcorpan: the README doesn't really say where to find server code |
| 14:41 | <wanderview> | annevk: step 29 here seems to allow HEAD no-cors requests... https://fetch.spec.whatwg.org/#dom-request |
| 14:42 | <zcorpan> | annevk: i did, yeah. the server code is pywebsocket i believe |
| 14:42 | <Ms2ger> | Yep |
| 14:42 | <annevk> | zcorpan: did you test protocols not matching? |
| 14:42 | <annevk> | zcorpan: and where do I find that code in relation to the tests? |
| 14:43 | <annevk> | wanderview: hmm, I wonder if that's accurate |
| 14:43 | <zcorpan> | annevk: trying to find a test that tests the removed protocols thing, but little luck so far |
| 14:43 | <annevk> | wanderview: afaict there's not a single feature on the web that can do HEAD across origins |
| 14:43 | <wanderview> | annevk: why is it bad? if it ends up going to a same-origni you can see status... if you end up going cross-origin you see 0 status |
| 14:43 | <zcorpan> | annevk: the handlers are in websockets/handlers/ |
| 14:43 | <annevk> | wanderview: even if we did allow HEAD though, that doesn't mean cache should be able to modify opaque responses |
| 14:44 | <wanderview> | annevk: at Request constructor time you don't know if you will get an opaque response or not if you fetch() it |
| 14:45 | <wanderview> | annevk: where is the failure for doing the HEAD request cross-origin? |
| 14:45 | <zcorpan> | annevk: hmm here we have something ./constructor/012.html: var ws = new WebSocket(SCHEME_DOMAIN_PORT+'/handshake_no_protocol', 'foobar'); |
| 14:46 | <annevk> | wanderview: I'm saying there might be a bug in Fetch that we allow that, or maybe we decided on allowing it since nobody thought it could do harm |
| 14:46 | <annevk> | wanderview: I'm vaguely remembering it might be the latter |
| 14:46 | <annevk> | wanderview: but that still doesn't mean you should be able to modify an opaque response |
| 14:47 | <wanderview> | annevk: the browser can clearly modify opaque responses and does whenever it sets the bodyUsed by internally draining |
| 14:48 | <wanderview> | annevk: the cache spec is generally problematic here, though, because it does not serialize and deserialize the Response... so it looks like it just has a list of Response objects... its really creating a new one each time it returns |
| 14:48 | <annevk> | zcorpan: contents of handshake_no_protocol_wsh.py are a little weird |
| 14:48 | <zcorpan> | annevk: yeah, it's a hack due to limitations of pywebsocket (or limited understanding) at the time the tests were written |
| 14:54 | <annevk> | zcorpan: thanks |
| 14:54 | <wanderview> | annevk: so we don't think we will ever want to send a password credential without cookies? |
| 14:55 | <annevk> | wanderview: it doesn't seem great to let developers modify opaque responses, although I'd have to page everything in again as to why that might be problematic |
| 14:55 | <annevk> | wanderview: well, that's what mkwst thinks |
| 14:55 | <wanderview> | oh, that's mkwst's irc handle! I kept looking for him here |
| 14:55 | <annevk> | wanderview: I raised that point in the PR |
| 14:56 | <wanderview> | yea |
| 15:00 | <annevk> | Domenic: https://github.com/whatwg/html/pull/840 all good now or still wary? |
| 15:00 | <wanderview> | HTML seems particularly hostile to diff reviewing for some reason |
| 15:01 | <zcorpan> | annevk: just added a comment |
| 15:33 | <annevk> | zcorpan: thanks, so how about I add a check in Fetch |
| 15:33 | <zcorpan> | annevk: wfm |
| 15:34 | <annevk> | zcorpan: "If _protocols_ is not the empty list and _response_'s header list does not contain a header named Set-WebSocket-Protocol, then fail the WebSocket connection" |
| 15:37 | <zcorpan> | annevk: also check if the header is present but doesn't contain any value |
| 15:38 | <zcorpan> | (havne't tested that but it seems it should be equivalent to omitting the header) |
| 15:48 | <annevk> | zcorpan: https://github.com/whatwg/fetch/pull/242 |
| 15:53 | <zcorpan> | r+; need to leave now |
| 16:21 | <mkwst> | wanderview: Hi, sorry. Wasn't looking at IRC. |
| 16:21 | <wanderview> | not a problem |
| 16:21 | <mkwst> | wanderview: No, I don't think it makes sense to separate this kind of credential from any of the other kinds of credentials Fetch already deals with. |
| 16:22 | <wanderview> | yea, sorry... I finally found the discussion in the PR |
| 16:22 | <mkwst> | That is, if I'm trying to authenticate a session, I'm going to want to manage HTTP state along with the authentication information I'm sending over. |
| 16:23 | <mkwst> | (and sorry about the IRC handle. It seemed like a BRILLIANT idea in the heady, vowelless days of Web 2.0.) |
| 16:35 | <Ms2ger> | Pff, even I have a vowel |
| 16:48 | Ms2ger | realizes he's had this name for over a decade now |
| 17:59 | <gabr13l> | o/ WHATWG crew |
| 18:00 | gabr13l | used to be cgcardona FWIW |
| 18:05 | <annevk> | gabr13l: good evening |
| 18:06 | <gabr13l> | hi annevk |
| 18:30 | <wanderview> | mkwst: btw, I'm still concerned about Matt's feedback here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ |
| 18:30 | <wanderview> | mkwst: I'm asking the person interested in implementing the spec in gecko to post to dev-platform so we can come to some concensus within mozilla |
| 18:52 | <MikeSmith> | hey gabr13l |
| 18:52 | <gabr13l> | hi MikeSmith |
| 18:56 | <smaug____> | annevk: trying to understand why people are against the 4th param version of addEventListener |
| 18:57 | <smaug____> | any new arguments ? |
| 18:57 | <smaug____> | other than "I don't like it" |
| 18:57 | <smaug____> | the API happens to be so commonly used that we need to be _very_ careful with all the compatibility issues |
| 18:58 | <smaug____> | and 4th param approach should be safer than 3rd param approach |
| 18:58 | <smaug____> | (and I'd really prefer if we spent less time on this and more time on designing some new way to add listeners) |
| 18:59 | <smaug____> | (since I assume that will take several months to get right) |
| 19:56 | <TabAtkins> | smaug____: If we can *actually commit* to doing that, and not just (as I expect) say "Yeah, we'll fix this in a new API" and then never develop it, then I'm okay with the stupid 4th-arg approach. |
| 19:56 | <TabAtkins> | I'm just pretty sure that no one will actually spend the time to design a new API, or if they do, it'll get shot down as not worth the implementation effort for a minor usability benefit. |
| 19:57 | <TabAtkins> | See: what has happened with createElement for the last several years. |
| 19:58 | <smaug____> | what has happened with createElement? |
| 19:58 | <smaug____> | it hasn't really changed |
| 19:58 | <smaug____> | this way radically |
| 20:00 | <TabAtkins> | People keep asking for a *usable* version of it, that lets you set attributes/properties/children. |
| 20:00 | <TabAtkins> | What every single DOM wrapper library provides, because the current DOM API is really terrible in usability. |
| 20:00 | <TabAtkins> | (I have one in Bikeshed - E.h1({attrs}, children...), for example.) |
| 20:01 | <TabAtkins> | But even tho the ideas get well-developed, no impls ever bite, because it doesn't actually provide anything *new*. |
| 20:01 | <TabAtkins> | And afaik, the same is true of a better-designed event-listener API - it's just "more usable", not "new functionality". |
| 20:02 | TabAtkins | is heading to lunch |
| 20:36 | <rbyers> | TabAtkins: if you or annevk or someone can commit to getting a new API into the spec, I'm happy to commit to implementing and shipping it in blink. |
| 20:41 | <Domenic> | rbyers: TabAtkins: annevk: https://github.com/straker/html-tagged-template/ looks like the best bet for me |
| 20:41 | <Domenic> | (modulo https://github.com/straker/html-tagged-template/issues/6 ) |
| 20:45 | <annevk> | Domenic: I think he meant a better event listener API |
| 20:46 | <Domenic> | ah, right, that would make sense :P |
| 20:46 | <annevk> | smaug____: there is no backcompat issue |
| 20:47 | <rbyers> | annevk: I talked a bit with smaug offline, it's all the Firefox ESR users (9-12 months old) that he's worried about - so forwards compat, but not back compat. |
| 20:48 | <rbyers> | .. that said, it's still possible there's a back compat issue - we just haven't found any concrete examples yet (and it's now in Chrome stable, so if there are a non-trivial number we should hear soon). |
| 20:50 | <annevk> | Those users will be in trouble anyway with each attractive new feature |
| 20:50 | <smaug____> | addEventListener is very different thing than some new attractive feature |
| 20:51 | <annevk> | This API will be around much longer than twelve months, it's important to do right by it |
| 20:52 | <smaug____> | and hacking 3rd param isn't more correct than 4th param approach. The 4th param approach is even less hacky since it doesn't add this bizarre boolean or dictionary thing |
| 20:52 | <smaug____> | this is of course very subjective |
| 20:55 | smaug____ | wonders what cloneRecord.[[TransferList]] means |
| 20:55 | <smaug____> | in the spec |
| 21:11 | <Domenic> | Am I not following enough links or is XHTML parsing rather under-defined |
| 21:11 | <Domenic> | Like where does it say for XHTML that <a> tags -> HTMLAnchorElement and such |
| 21:16 | <zcorpan> | Domenic: it's under-defined. there's no spec for how to turn an XML byte stream into a DOM at all. |
| 21:17 | Domenic | flips some tables |
| 21:19 | <zcorpan> | iirc there's Infoset that defines a mapping for the Infoset, but there's no explicit mapping between Infoset and DOM |
| 21:22 | <zcorpan> | fun fact: https://www.w3.org/TR/xml-stylesheet/ is defined in terms of Infoset |
| 21:26 | <gsnedders> | zcorpan: as is XPath and XSLT |
| 22:52 | <JonathanNeal> | Should a <picture> element display like an <img>? In that itโs an inline element that behaves like an inline-block element? |
| 22:56 | <zcorpan> | JonathanNeal: no <picture> displays like a <span> |
| 22:57 | <zcorpan> | it's the child <img> that shows the image |
| 22:59 | <JonathanNeal> | @zcorpan, this is the expected result? http://codepen.io/anon/pen/KzMmyX |
| 22:59 | <zcorpan> | JonathanNeal: yes |
| 23:01 | <zcorpan> | JonathanNeal: you can style the <img> as usual |
| 23:01 | <zcorpan> | HTH |
| 23:01 | zcorpan | -> bed |