| 00:02 | <zewt> | search for "fire a simple event" and "queue a task to fire a simple event" |
| 00:44 | <dgorbik> | esprehn_: how do you think is it best to do this in two steps? First — fix this regression and set the correct namespaces. And second — apply the right styles, this is not covered by tests yet. |
| 00:45 | <esprehn_> | dgorbik: yes, fix the bad casts first |
| 01:10 | <Hixie> | can anyone work out if i'm missing something in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19590 ? (table parsing, the claim is there's a potential infinite loop) |
| 01:29 | <Hixie> | am i misreading the dom spec, or is it fine to have a range whose start is at a document node? |
| 01:57 | <erlehmann> | i have done an art. |
| 01:57 | <erlehmann> | anyone interested in media fragments beside me? :3 |
| 07:11 | <MikeSmith> | I'm starting to wonder if Anne has some moral objection to writing introductory material for his specs. |
| 07:12 | <MikeSmith> | speaking of which I wonder if "Fundamentally, the DOM is one giant memory leak." would make a good addition to the introductory section for the DOM spec |
| 07:12 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0067.html |
| 07:21 | <MikeSmith> | when somebody files something like https://www.w3.org/Bugs/Public/show_bug.cgi?id=18766 but doesn't actually add themselves to the Cc field, I wonder how they know when Hixie or somebody else has commented |
| 08:54 | <annevk> | MikeSmith: I'm just bad at writing introductory material. I think it's because its correctness is hard to measure |
| 08:54 | <MikeSmith> | annevk: yeah |
| 08:54 | <annevk> | MikeSmith: With algorithms you can tell when there's nothing left to remove. With introductory text and examples there's no simple rules to use. |
| 08:56 | <MikeSmith> | it's hard to hit the sweet spot on it too, I think -- between being too brief and being way too long |
| 08:56 | <MikeSmith> | I think in some W3C specs they're really is just way too much introductory info |
| 08:57 | <MikeSmith> | especially given that the specs are supposed to be primarily for implementors who don't need that much info to understand the context |
| 09:45 | <Dashiva> | Is whatwg.org/issues still in use? |
| 11:36 | <Ms2ger> | Poor Hixie... Fixes a bug, gets two in return |
| 15:59 | <MikeSmith> | Ms2ger: yeah "poor Hixie" is for sure a phrase we don't hear people say nearly often enough |
| 16:03 | <MikeSmith> | the Rolling Stones made a song about this |
| 17:24 | <jgraham> | MikeSmith: Curiously enough (I can't get no) satisfaction is the number one complaint about Hixie |
| 17:28 | <Hixie> | MikeSmith: in my experience, the answer is "they don't know when i commented" |
| 17:28 | <Hixie> | Dashiva: it's in use in that that feedback is the feedback i have to deal with |
| 17:28 | <Hixie> | Dashiva: i don't look at the votes much because people haven't ever really used it |
| 17:31 | <Dashiva> | kk |
| 17:32 | GPHemsley | wonders when the whatwgmemes will appear. |
| 17:32 | <GPHemsley> | (Or does this fall under w3cmemes?) |
| 17:32 | <Hixie> | pretty sure w3cmemes is covering whatwg already :-P |
| 17:37 | <gsnedders> | See the latest post. |
| 17:41 | <jgraham> | To be fair there are probably far more people in W3C land that give a shit about infoset compatibility |
| 17:44 | <jgraham> | (but http://w3cmemes.tumblr.com/post/34765672844/meanwhile-in-the-treehouse is clearly about the WHATWG, for example) |
| 17:45 | <Hixie> | the one about bz was about feedback he sent to the whatwg list, too |
| 17:45 | <Hixie> | though of course it applies to feedback he sends everywhere :-) |
| 17:46 | <jgraham> | Yeah, but it could equally have applied to anything he said ever, more or less |
| 17:46 | <jgraham> | So it wasn't such a nice example :) |
| 17:46 | <manu1> | Has anybody else done a technical review of the EME spec yet? It's pretty bad - http://manu.sporny.org/2013/drm-in-html5/ |
| 17:46 | <Hixie> | jgraham: agreed :-) |
| 17:46 | <manu1> | anybody else know of the use case they're trying to address? |
| 17:46 | <manu1> | I assumed it was "reduce content piracy"... but maybe they're after something else? |
| 17:47 | <Ms2ger> | What makes you think they have use cases to address? |
| 17:47 | <Hixie> | the use case is "browser vendor who also has content distribution deals who wants to convince paranoid deluded content producer to provide them with content" |
| 17:47 | <Hixie> | (drm won't reduce piracy (it'll actually increase it)) |
| 17:48 | <manu1> | Ms2ger: I just... you know, assumed that they're trying to solve problem. |
| 17:48 | Ms2ger | sniggers |
| 17:49 | <jgraham> | Mmm DRM *and* plugins? What's not to like? |
| 17:49 | <manu1> | Hixie: yeah, that's the assumption I made while reviewing the spec... the goals section doesn't actually say that, though... so wondered if anyone on this list actually took part in the design of the spec (or had talks about the design of the spec) with the editors. |
| 17:49 | <Hixie> | i had high-level talks with some of the people involved, both in public and in private |
| 17:50 | <manu1> | jgraham: hey, the spec isn't about DRM! It's about plugins, that may or may not implement DRM. So, theoretically, you could use the spec without having any sort of DRM! >_> |
| 17:50 | <Hixie> | but since i disagree with the work at a moral level, i really didn't get very far into the technicalities |
| 17:51 | <manu1> | Hixie: The technical argument is pretty straight-forward if the goal was just presented clearly in the spec. They also went to great lengths to reinvent TLS in the spec, that was pretty awesome. |
| 17:51 | <manu1> | oh, and clear-text decryption keys... that was also pretty awesome. |
| 17:51 | <Hixie> | the technical argument is indeed pretty straight-forward. "what you want to do is mathematically impossible." |
| 17:51 | manu1 | nods. |
| 17:51 | <Hixie> | but what they want to do isn't mathematically impossible |
| 17:52 | <manu1> | which is deliver a placebo to the content providers. |
| 17:52 | <Hixie> | right |
| 17:52 | <Hixie> | except unlike most placebos this one has pretty major negative second-hand side-effects |
| 17:52 | <manu1> | okay, just making sure that is what was going on and that I wasn't missing some vital piece of information... thx, Hixie. |
| 17:52 | <jgraham> | I'm pretty sure that the clearkey thing is smoke and mirrors |
| 17:52 | <Hixie> | i'm probably not the most objective person to verify this for you, fwiw :-) |
| 17:53 | <manu1> | My favorite part of the spec is this image: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/stack_overview.png |
| 17:53 | <jgraham> | Anyway, I haven't looked at this hard so I probably shouldn't comment :) |
| 17:53 | <manu1> | I did look at it in detail this morning - it's definitely smoke and mirrors. |
| 17:54 | <Ms2ger> | It's good to see the HTML WG spends its time on useful things for once. |
| 17:54 | <manu1> | (I say this having implemented a variety of DRM and PKI systems) |
| 17:55 | <espadrine> | that proposal is pretty old. Why wasn't there an outcry earlier? |
| 17:55 | <manu1> | probably because it wasn't being proposed as a First Public Working Draft, espadrine |
| 17:55 | <Hixie> | espadrine: there was huge outcry when they proposed it |
| 17:55 | <Hixie> | espadrine: it even made it as far as the tech press |
| 17:55 | manu1 | missed that fireworks show. |
| 17:56 | <Hixie> | e.g. http://news.cnet.com/8301-30685_3-57384129-264/standards-leader-blasts-html5-video-copy-protection/ |
| 17:57 | <espadrine> | so now that it's a public working draft, they're going to do what, pressure browsers into implementing it? |
| 17:57 | <Hixie> | it's mostly being pushed by browser vendors, as i understand it |
| 17:58 | <espadrine> | well, I haven't heard of any interest in implementing it. Is there any work on that front? |
| 17:59 | <Hixie> | espadrine: companies don't tend to spend engineering effort on writing specs they're not implementing |
| 17:59 | <Hixie> | (but they rarely comment on future products or services for legal and PR reasons, so it's normal for that not to be obvious) |
| 18:00 | <espadrine> | yes, but they wrote Dart's spec, and they weren't very successful in adding Dart (or the primitives to put a non-JS VM in) to WebKit |
| 18:01 | <Hixie> | you asked about "interest in implementing it", not about "success in deploying it" |
| 18:03 | <espadrine> | poor implementers. |
| 18:07 | <Hixie> | bbl |
| 18:12 | Philip` | was testing some stuff on Android involving playing a video on a TV through the HDMI connection, and it refused to display the video because of HDCP, but then he found he could just remove the video buffer's protected-content flag in a user-space library and apparently defeat the whole protection system |
| 18:19 | <SimonSapin> | Philip`: did you really think there was more than this to DRM? |
| 18:19 | <SimonSapin> | I mean, if the user can read it, well, the user can read it |
| 18:19 | <zewt> | Philip`: i think a lot of these "copy protection" mechanisms are actually to trigger legal things, rather than to actually prevent copying |
| 18:20 | <zewt> | eg. making it so flipping a flag in a userspace library is "bypassing copy protection" so they can sue you for that |
| 18:25 | <Philip`> | SimonSapin: In this case it's not hugely trivial for the user to read the video since I think the decoded data never actually passes through the CPU (the graphics processor does all the decryption and decoding and composition, and will refuse to composite into an untrusted buffer when the appropriate flags are set) |
| 18:25 | <Philip`> | but it's not hugely hard either |
| 18:26 | <SimonSapin> | I see |
| 18:28 | <Philip`> | but I guess there's no real motivation to make it any harder than is necessary for legal reasons |
| 20:21 | <zewt> | bleh jquery |
| 20:21 | <Ms2ger> | And a heartfelt bleh from me too |
| 20:21 | <zewt> | what kind of sadistic API has a function named width() that's both a getter and a setter |
| 20:22 | <zewt> | wasted ten minutes trying to figure out where this code is setting an element's width, and it's a width() call that i was skimming over because the name looks like a getter |
| 20:23 | <gsnedders> | zewt: Now imagine a tool that programmatically reduces JS to minimize TCs, and tries removing arguments. |
| 20:23 | <zewt> | javascript minifiers need to die in a fire |
| 20:30 | <zewt> | why does everything with a syntax vaguely like cvs have to slightly change the shorthand for "commit" |
| 20:30 | <zewt> | during cvs i got in the habit of "cvs co"; svn broke that, so i had to relearn "svn ci"; and now git breaks *that* |
| 20:32 | <SimonSapin> | zewt: hum, git aliases? |
| 21:25 | <jgraham> | SimonSapin: git aliases are frightening. As far as I can tell they just encorage you to do things that don't work when you are logged into other machines and prevent you helping other people who need guidance |
| 21:26 | <jgraham> | For cases like this it's just better to learn the tool warts and all |
| 21:26 | <jgraham> | zewt: gsnedders wasn't talking about a JS minifier exactly, but a testcase minifier |
| 21:27 | <SimonSapin> | jgraham: Still, I’ll keep my "graph = log --oneline --date-order --graph --all --decorate" alias |
| 21:27 | <jgraham> | (which does minify js of course but in a manner, and with an intent, that is quite different from most minifiers) |
| 21:29 | <jgraham> | SimonSapin: I guess for essentially synthesising new commands it's more defensible. But still annoying that you can't rely on it |
| 21:29 | <jgraham> | Although, as we learnt this week, the solution to that is to keep all your dotfiles, including your private keys, in github so they are accessible from anywhere |
| 21:30 | <jgraham> | And to anyone |
| 21:31 | <SimonSapin> | crypto reduces all problems to key management problems, and GitHub solves the latter |
| 21:40 | <espadrine> | jgraham: I followed your advice, I feel a lot safer already. |
| 21:45 | <Ms2ger> | SimonSapin, you mean, "hg gl"? |
| 21:45 | <SimonSapin> | maybe |
| 22:49 | <GPHemsley> | Oh, here's another one: how do you pronounce "json"? |
| 22:58 | <gsnedders> | GPHemsley: "Jay-son" is how I've always heard it said. |
| 22:58 | <GPHemsley> | Does "son" rhyme with "bun" or "con"? |
| 22:59 | <gsnedders> | en son/sun |
| 23:04 | <jgraham> | It is canonically pronounced like the name, Jason |
| 23:06 | <jgraham> | Despite this, Kylie is *still* refusing requests to duet with Crockford |
| 23:28 | <zewt> | sometimes i swear browser implementors are just out to annoy authors for fun |
| 23:28 | <zewt> | it seems like webkit (or at least mobile safari) honors tabindex=-1 ... unless all inputs are tabindex=-1, in which case it ignores it entirely |
| 23:29 | <zewt> | so i guess instead i get to play games with @disabled |
