| 02:19 | <caitp> | TabAtkins: has there been any mail regarding the :target pseudo-class lately? I don't remember seeing any, but you'd probably be more on top of that? |
| 02:19 | <caitp> | as far as I know that should still work, right? |
| 05:11 | <zcorpan> | Hixie: so is the current content model ok or should it be "zero or more source elements optionally intermixed with script-supporting elements followed by one img"? |
| 06:30 | <zcorpan> | UA string is still race to the bottom. when will it stop? should we standardize on one fixed string? |
| 06:33 | <zcorpan> | Hixie: how can i run your pipeline? |
| 06:48 | <sangwhan> | If everyone got rid of Mozilla/5.0 in their UA string that would probably save enough bytes transmitted to give one small country free internet |
| 06:54 | <roc> | it sure would, because the entire Web would shut down |
| 07:10 | zcorpan | notices annevk changed "authors" to "developers" in the fetch spec |
| 07:15 | <MikeSmith> | author-developers |
| 07:36 | <foolip> | Ms2ger: you there? |
| 07:36 | <Ms2ger> | foolip, sir! |
| 07:36 | <foolip> | Ms2ger: do you have any juicy info on the compat situation with HTMLImageElement.x/y in Gecko? |
| 07:37 | <Ms2ger> | We tried removing it, it broke something |
| 07:37 | <foolip> | see this thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zpLuYu8tmdA/uA_7TQSQDzQJ |
| 07:37 | Ms2ger | looks if he can find the site |
| 07:37 | <foolip> | I'm trying to figure out if there's any change to Blink that could bring us closer to agreement between spec and implementations |
| 07:37 | <foolip> | these are the relevant Gecko bugs: |
| 07:38 | <foolip> | https://bugzilla.mozilla.org/show_bug.cgi?id=98292 |
| 07:38 | <foolip> | https://bugzilla.mozilla.org/show_bug.cgi?id=116843 |
| 07:38 | <foolip> | https://bugzilla.mozilla.org/show_bug.cgi?id=587021 |
| 07:39 | <foolip> | https://bugzilla.mozilla.org/show_bug.cgi?id=731832 too |
| 07:39 | <Ms2ger> | Yep, 731832 was the one that made us back it out |
| 07:40 | <foolip> | http://web.archive.org/web/20120107051245/http://www.crownhill.com/ looks modern :) |
| 07:40 | <Ms2ger> | Yep, that's the one |
| 07:41 | <Ms2ger> | Code that used it in http://web.archive.org/web/20110807212111/http://www.crownhill.com/buttons_1/xaramenu.js |
| 07:41 | <Ms2ger> | "if(NS4)return;" |
| 07:42 | <foolip> | if(NS6){if(mal==0){x=event.target.x-bd;y=event.target.y;dx=event.target.offsetWidth;dy=event.target.offsetHeight;} is the relevant bit, no? |
| 07:42 | <Ms2ger> | Yep |
| 07:43 | Ms2ger | got distracted |
| 07:43 | <foolip> | and ar NS6=(!document.all&&document.getElementById) |
| 07:43 | <foolip> | var |
| 07:43 | <foolip> | that's some pretty weird logic :) |
| 07:44 | <Ms2ger> | If that's the weirdest you've seen... ;) |
| 07:45 | <foolip> | what I really wanted to ask is if you can figure out what GetXY() in https://github.com/mozilla/gecko-dev/blob/master/content/html/content/src/HTMLImageElement.cpp actually means |
| 07:45 | <foolip> | in my testing it's usually like offsetLeft/offsetTop, but not always |
| 07:46 | <foolip> | is this layer thing something that maps to a CSS concept? |
| 07:46 | <Ms2ger> | I don't know |
| 07:47 | <Ms2ger> | I think roc explained or was going to explain it in the W3C bug to add it to the spec |
| 07:47 | <foolip> | ok, I'll see if I can find that bug |
| 07:47 | <foolip> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17844 |
| 07:49 | <Ms2ger> | Comment 16 there was what I remembered |
| 07:49 | <foolip> | I guess that means I should ask roc about the details |
| 07:50 | <Ms2ger> | Also https://bugzilla.mozilla.org/show_bug.cgi?id=887660 |
| 07:58 | <MikeSmith> | hsivonen: Any chance you can re-deploy v.nu and h5.v.nu this week? I fixed a bug that had broken <picture> validation. |
| 08:03 | <annevk> | zcorpan: seems to be preferred by some set of people |
| 08:31 | <annevk> | JakeA: Googleman, what does "impacts MVP" mean? |
| 08:32 | <annevk> | JakeA: oh wait, I know, minimal viable product |
| 08:32 | <JakeA> | yeeep |
| 08:37 | <tobie> | lean spec writing |
| 08:37 | <tobie> | you should do workshops. there's money to be made. |
| 09:28 | <hsivonen> | MikeSmith: chances for redeploying this week are good |
| 09:32 | <jgraham> | hsivonen: You sound like a magic 8 ball ;) |
| 09:43 | <sangwhan> | anyone here with knowledge about gecko's KeyboardEvent implementation? |
| 09:43 | sangwhan | nudges smaug____ |
| 09:51 | <Ms2ger> | mayasuki |
| 09:59 | <smaug____> | sangwhan: pong |
| 09:59 | <smaug____> | what about it |
| 10:00 | <smaug____> | but yes, masayuki knows it best |
| 10:00 | <smaug____> | sangwhan: aren't you even in the same timezone as masayuki |
| 10:05 | <sangwhan> | smaug____: except i don't know masayuki. is he here or do i have to find him on irc.moz? |
| 10:05 | <zcorpan> | Hixie: fixed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25585 but possibly that section is a bit confused now, and it doesn't cover img srcset, and there's overlap with the Introduction examples |
| 10:07 | <sangwhan> | Basically i have this odd test that only passes in gecko: http://tests.sangwhan.com/tests/generated_keyevent.html |
| 10:07 | <sangwhan> | Can't decrypt d3e fast enough to figure out if that's correct or not |
| 10:07 | <sangwhan> | smaug____: ^ |
| 10:10 | <MikeSmith> | hsivonen: cool |
| 10:12 | <MikeSmith> | sangwhan: masayuki not on #whatwg afaik. not sure if he's on mozilla irc much either. seems like he communicates most through bug comments.. |
| 10:12 | <smaug____> | sangwhan: in moznet |
| 10:12 | <smaug____> | and yes, MikeSmith is right |
| 10:13 | <smaug____> | sangwhan: note, as far as I know, only Gecko implements large parts of the spec |
| 10:14 | <smaug____> | sangwhan: oh, that test is odd |
| 10:14 | <smaug____> | it tests legacy keyCode |
| 10:14 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/webidl/KeyboardEvent.webidl#50 |
| 10:14 | <smaug____> | which aren't, AFAIK, defined to be in the dictionary by any spec |
| 10:15 | <smaug____> | but we had to support them, at least for now |
| 10:16 | <sangwhan> | smaug____: yes, it is odd. came from a external source, and i have no idea if it should work or not |
| 10:16 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/webidl/KeyEvent.webidl and http://mxr.mozilla.org/mozilla-central/source/dom/webidl/KeyboardEvent.webidl explain that kind of part of Gecko's behavior |
| 10:18 | <MikeSmith> | sangwhan: btw I think they have a telcon every wednesday morning at 9am JST, on #webapps on irs.w3.org, and masayuki usually calls into that |
| 10:18 | <smaug____> | Well, spec says only "Legacy keyboard event implementations include three additional attributes, keyCode, charCode, and which." |
| 10:18 | <smaug____> | sangwhan: you could file a spec bug to clarify this |
| 10:31 | <jgraham> | glwt |
| 10:34 | <MikeSmith> | https://twitter.com/ronkorving/status/496582799181094914 |
| 10:34 | <MikeSmith> | "Why the hell doesn't documentFragment support innerHTML? This is nuts." |
| 10:36 | <zcorpan> | foolip = rambo |
| 10:36 | <roc> | foolip: what exactly do you need to konw? |
| 11:05 | <annevk> | MikeSmith: we tried to define it at one point and got stuck iirc |
| 11:19 | <MikeSmith> | annevk: stuck on what, I wonder. maybe there's an open bug |
| 11:19 | MikeSmith | checks |
| 11:19 | <annevk> | MikeSmith: there's something about ShadowTree or whatever it is called these days and innerHTML too |
| 11:20 | <Ms2ger> | Yeah, there was something |
| 11:20 | <Ms2ger> | Broke jQuery, perhaps? |
| 11:24 | <MikeSmith> | founs https://www.w3.org/Bugs/Public/show_bug.cgi?id=16904 |
| 12:15 | <Ms2ger> | zcorpan, r? https://critic.hoppipolla.co.uk/r/2180 |
| 12:18 | <zcorpan> | Ms2ger: done |
| 12:18 | <Ms2ger> | Thanks |
| 12:19 | Ms2ger | merges |
| 12:35 | <Domenic> | Why don't we just standardize UA string? |
| 12:40 | <jgraham> | The entire world would collapse |
| 12:40 | <Ms2ger> | Domenic, there's a reasonable argument that they're useful for statistics on the server side, at least |
| 12:41 | <Domenic> | I mean, standardize it to one of the existing ones, not to something sane |
| 12:41 | <jgraham> | There's also a reasonable argument that not everything can be feature detected |
| 12:41 | <Domenic> | I guess |
| 12:41 | <Ms2ger> | Also, people are unlikely to stop having browser-specific code altogether |
| 12:41 | <jgraham> | But, more importantly, people *do* use it |
| 12:41 | <Domenic> | just seems inevitable |
| 12:41 | <jgraham> | And it turns out that changing it breaks sites, really badly |
| 12:41 | <Ms2ger> | More likely, they'd use things like var NS6=(!document.all&&document.getElementById) |
| 13:02 | <foolip> | roc: I emailed, as you noticed :) |
| 13:02 | <foolip> | now I've installed Netscape 4 to see how it originally behaved, since that's what both the initial Gecko and WebKit implementation pointed to |
| 13:02 | <foolip> | In case anyone has forgotten, NS4 was awesome |
| 13:02 | <Ms2ger> | I wonder if its source code ever escaped |
| 13:28 | <annevk> | JakeA: 9AM PDT is what? |
| 13:28 | <annevk> | found it |
| 13:28 | <Ms2ger> | 6pm .nl |
| 13:28 | <JakeA> | annevk: 17:00 for me, 18:00 for you I guess |
| 13:28 | <annevk> | Ms2ger: .ch |
| 13:28 | Ms2ger | has no idea what .ch is |
| 13:28 | <Ms2ger> | Timezone-wise |
| 13:28 | <annevk> | Ms2ger: same |
| 13:29 | <Ms2ger> | Okay, wasn't sure |
| 13:36 | <annevk> | jgraham: you like discussing this stuff: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26405 |
| 13:36 | annevk | can't come up with suitable terms that'll stick |
| 13:38 | <tobie> | Votes for a URL primitive. |
| 13:38 | <tobie> | ^ that would make parsing JS SOOOO much fun. |
| 13:44 | <annevk> | I'm not sure what you mean tobie, but that doesn't seem to relate to that bug |
| 13:47 | <tobie> | annevk: never mind me. I very often forget to add quotes around urls when writing JavaScript. |
| 13:48 | <tobie> | annevk: …which makes me think it would be kind of neat if the language of the Web supported URL primitives. |
| 13:48 | <annevk> | url`http://....` could be something I suppose |
| 13:49 | <annevk> | Not sure what the latest is on those kind of strings |
| 13:49 | <tobie> | Yeah. The syntax is so enticing. I can't wait. </sarcasm> |
| 13:50 | <tobie> | Anyway, why don't you call them URL strings and URL objects? |
| 13:52 | <annevk> | Yeah, URL input and URL objects was what I had so far |
| 13:52 | <tobie> | input's kind of weird imho. |
| 13:53 | <gsnedders> | tobie: hey, ES4X is what we really want for parsing |
| 13:53 | <annevk> | Well, it's input to the parser |
| 13:54 | <tobie> | yeah, but that's very specific to the URL spec. |
| 13:55 | <tobie> | If you want to talk about setting window.location to a URL xxx you probably want to use URL string (instead of input). |
| 13:55 | <jgraham> | FWIW I also said — string and — object |
| 13:59 | <zcorpan> | why not "URL" and {URL} |
| 14:13 | <jgraham> | IETF approve of your scare quotes |
| 14:13 | <Ms2ger> | [[URL]] |
| 14:13 | <zcorpan> | remember to register for tpac everyone |
| 14:13 | <zcorpan> | or are you guys not going? |
| 14:13 | <tobie> | zcorpan: would you call those handlebar URLs or 'stache URLs? |
| 14:13 | <zcorpan> | tobie: fiskmås |
| 14:13 | <annevk> | Probably not going to TPAC |
| 14:40 | <tobie> | JakeA: trying to wrap my head around the SW/cache streaming. Why are we teeing/cloning the streams instead of piping them through the client and to the cache? e.g. response.body.pipe(e.response).pipe(cache) or something |
| 14:43 | <annevk> | tobie: see Fetch for why you need to tee |
| 14:44 | tobie | looks. |
| 14:44 | <JakeA> | tobie: isn't that treating the browser renderer as a transform stream that returns just the same value? |
| 14:47 | <caitp> | some time ago, some guy started applying the word streams to things and telling people that it simplified things --- and then everyone jumped on the streams bandwagon waving their pipes everywhere |
| 14:47 | <caitp> | and that's why we're doing it |
| 14:47 | <tobie> | JakeA: well, doesn't the renderer immediately buffer the response stream and deserializes into something else? A JS string, a rasterized image, etc? (No idea what I'm talking about.) |
| 14:48 | <tobie> | caitp: the emperor's fully dressed, thank you. |
| 14:54 | <JakeA> | tobie: it'll transform it into dom nodes, video frame(s) etc etc. It won't buffer the whole response before transforming begins unless the format requires it |
| 14:56 | <tobie> | JakeA: makes sense. |
| 15:16 | <tobie> | annevk: where is teeing defined? |
| 15:16 | <annevk> | nowhere |
| 15:18 | <tobie> | ah |
| 15:19 | <tobie> | annevk: are there any plans for it to be defined somewhere? |
| 15:19 | <JakeA> | tobie: https://github.com/whatwg/streams |
| 15:19 | <annevk> | yeah, the plan is to have stream primitives for the platform and a stream API on top |
| 15:20 | <annevk> | hopefully the stream terminology can be reused by things that don't necessarily expose it in an API |
| 15:24 | <tobie> | oh, so teeing throttles the source's writes to the slowest of its destinations? Isn't that an issue when writing to cache and the client at the same time? |
| 15:25 | <tobie> | annevk: not sure what you mean by stream primitives in that case. |
| 15:27 | <annevk> | tobie: the underlying model I guess |
| 15:28 | <tobie> | annevk: thanks for clarifying. |
| 15:29 | <JakeA> | tobie: teeing throttles to the fastest of the destinations and holds the content in memory for the slowest, I believe |
| 15:29 | <tobie> | JakeA: upon reading the spec again, it seems that's voluntarily unspecified. |
| 15:30 | JakeA | shines the Domenic symbol into the cloudy sky |
| 15:31 | <tobie> | But the example implementation throttles all connections, though. |
| 15:33 | <tobie> | JakeA: I feel like the goal for SW/cache was to abstract away the underlying streams completely, and that they |
| 15:33 | <tobie> | arg |
| 15:34 | <tobie> | JakeA: …'re now totally leaking through. |
| 15:34 | <JakeA> | tobie: the goal was more to prepare for streams, but be able to ship sooner than that |
| 15:57 | <JakeA> | http://www.buzzfeed.com/jimwaterson/pictures-of-politicians-when-they-were-younger |
| 15:57 | <JakeA> | Well, that was the wrong channel |
| 15:57 | <JakeA> | but enjoy that anyway |
| 15:59 | <caitp> | would love to, but it turns out that 802.11n makes it very difficult to enjoy much of anything |
| 16:08 | <JakeA> | Hixie: I keep typing ArrayBugger, just in case you're looking for more specs to Britainify |
| 16:10 | <jgraham> | I think that how we all feel about js arrays |
| 16:11 | <gsnedders> | jgraham: that they're the best thing ever, and you really want JS engines to optimize them into typed arrays? |
| 19:25 | <Hixie> | if anyone has ideas of examples we could add to the HTML spec of how to use HTML elements or APIs in Web apps (as opposed to documents), please add them to https://www.w3.org/Bugs/Public/show_bug.cgi?id=25747 |
| 20:23 | <TabAtkins> | caitp: No, nothing in particular about :target. Why? |
| 20:23 | <caitp> | i didn't think so, it was just a bug someone had filed, it's been addressed |
| 20:23 | <caitp> | just wanted to make sure :> |
| 20:58 | <Domenic> | So apparently DOCTYPE serialization is a mess |
| 20:59 | <Hixie> | DOCTYPE serialisation is nice and easy |
| 21:00 | <Hixie> | you just output the constant string '<!DOCTYPE HTML>' |
| 21:00 | <Hixie> | :-) |
| 21:00 | <Domenic> | it is only observable via XHR, and browsers all do the more complicated thing |
| 21:08 | <Hixie> | anyone got IE around who can tell me the output of http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3099 ? |
| 21:10 | <Hixie> | Domenic: i've no idea what that issue is about, can you elaborarte? |
| 21:10 | <Hixie> | elaborate |
| 21:11 | <Domenic> | Hixie: so I maintain jsdom, which is a server-side implementation of the DOM. We are trying to figure out when the user asks us "save this document to a file" how we should serialize it |
| 21:11 | <Hixie> | replace the DOCTYPE with '<!DOCTYPE HTML>' |
| 21:12 | <Domenic> | So, two minor problems: 1) that is not what browsers do when you serialize via XHR; 2) that is not what DOM S&P says |
| 21:12 | <Domenic> | (it is what HTML says) |
| 21:12 | <Hixie> | why are either of those problems? |
| 21:12 | <Domenic> | they are minor problems. e.g. we should probably fix DOM S&P |
| 21:12 | <Domenic> | and we should either fix browsers or fix the XHR spec to reflect browsers |
| 21:13 | <Hixie> | i don't understand the relevance of either (1) or (2) to what a server does |
| 21:13 | <Domenic> | they aren't really problems for us |
| 21:13 | <Domenic> | for me |
| 21:13 | <Domenic> | they are problems for the web that I have uncovered in the midst of this investigation |
| 21:15 | <jgraham> | Isn't DOM S&P the one that W3C forked and added lots of complexity to for no readon |
| 21:15 | <jgraham> | *reason |
| 21:15 | <Domenic> | to be fair, they seem to have fixed bugs or holes in some csaes |
| 21:15 | <Domenic> | Ms2ger hasn't had time to reincorporate those back into the original |
| 21:17 | <Hixie> | Domenic: oh the server side of this is irrelevant? |
| 21:17 | <Hixie> | now i'm even more confused |
| 21:17 | <Hixie> | what is the question i'm supposed to be answering? |
| 21:18 | <Domenic> | Hixie: sorry to confuse. I was just paging you guys in to let you know about a problem that we discovered, not to ask you to help us fix our code. |
| 21:18 | <Hixie> | what's the problem though? |
| 21:19 | <Domenic> | the two abovementioned problems. DOM P&S contradicting HTML; XHR contradicting reality |
| 21:23 | <Hixie> | ah |
| 21:23 | <Hixie> | i wonder if anything uses the HTML spec's definition at this point |
| 21:25 | <Domenic> | I believe XHR says to use HTML's, but browsers do not do that |