| 05:36 | <MikeSmith> | Domenic_: what do gulp and browserfy have to do with streams? |
| 08:36 | <zcorpan> | hsivonen: iirc https://code.google.com/p/chromium/issues/detail?id=329531 applies to gecko, too |
| 08:40 | <hsivonen> | zcorpan: thanks |
| 08:48 | <MikeSmith> | zcorpan: "I propose we don't address this" from sof.. why? because it will break things? |
| 08:49 | <zcorpan> | MikeSmith: s/will/is not proven not to/ |
| 08:49 | <MikeSmith> | ok |
| 08:49 | <Ms2ger> | From ap? |
| 08:50 | <MikeSmith> | sigbjorn from oepra |
| 09:20 | <annevk> | SimonSapin: I thought :scope was still a thing |
| 09:20 | <annevk> | SimonSapin: I thought it moved to Selectors or some such, TabAtkins? |
| 09:25 | <Ms2ger> | http://dev.w3.org/csswg/selectors/#scope-pseudo |
| 09:34 | <annevk> | \o/ Chrome is going to remove obsolete DOM stuff. Sadly they still refer to it as DOM4 |
| 09:39 | <MikeSmith> | annevk: I think that's just because Dominic didn't get the memo that it should be called something else |
| 09:39 | <annevk> | MikeSmith: he does refer to the WHATWG copy so there's that, indeed |
| 09:40 | <annevk> | I had to commute today and be in at 9AM. That shit is hard |
| 09:44 | <MikeSmith> | annevk: hard to find a parking space big enough for your cadillac |
| 09:44 | <annevk> | Can of sardines is nothing compared to the Circle line |
| 09:46 | <annevk> | Central line, that is, still getting used to the terminology |
| 09:46 | <MikeSmith> | could be worse: You could be living in Mountain View |
| 09:48 | <Ms2ger> | Or Tokyo? :) |
| 09:48 | <MikeSmith> | heh |
| 10:10 | jgraham | wonders where annevk is |
| 10:10 | <annevk> | jgraham: http://theodi.org/ |
| 10:11 | <jgraham> | Why? |
| 10:15 | <hsivonen> | annevk: whoa. the Thunderbird compose encoding menu is worse than I expected |
| 10:16 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=943252#c9 |
| 10:18 | <annevk> | jgraham: the W3C TAG is meeting there |
| 10:19 | <jgraham> | annevk: Oh, sucks to be you |
| 10:20 | <annevk> | hsivonen: ugh |
| 10:27 | <annevk> | hsivonen: sorry I haven't been responsive lately, it's not going to get much better until mid-March or so |
| 10:27 | <annevk> | hsivonen: I plan to focus on Encoding stuff next week |
| 10:33 | <hsivonen> | annevk: OK. |
| 10:33 | <hsivonen> | FWIW, I'm inclined to think that Thunderbird shouldn't bother the user with composition encoding UI at all |
| 10:33 | <hsivonen> | but my first goal is getting cruft out of m-c. not redesigning TB |
| 10:40 | <annevk> | I think email inevitably ends up being a web thing, so I'm not too worried about Thunderbird |
| 10:45 | <hsivonen> | annevk: the reason why I end up writing essays for the TB bugs is that the mailnews dependencies make it hard to remove code that's dead code in Firefox |
| 10:46 | <annevk> | Understood, the dependencies are sad, especially so long after the Firefox fork |
| 10:46 | <annevk> | The RDF-in-Gecko apologists are also making me somewhat sad |
| 10:49 | <hsivonen> | annevk: that thread took an unexpected turn |
| 10:49 | <krijn> | MikeSmith: thanks voor the retweets! :) |
| 10:57 | <annevk> | hsivonen: the last guy also frequently comments on www-tag, not unexpected |
| 10:58 | <annevk> | hsivonen: felt similar to how suddenly a bunch of XSLT apologists found out blink-dev exists |
| 11:04 | <hsivonen> | and this RDF stuff doesn't even have anything to do with the Semantic Web while XSLT has something to do with using XSLT |
| 11:07 | <annevk> | I guess there's a point to be made that the dev.platform discussion is worse :-) |
| 11:07 | <annevk> | http://w3ctag.github.io/capability-urls/2014-01-03.html is pretty awesome by the way |
| 11:11 | <MikeSmith> | krijn: yup |
| 11:24 | <krijn> | MikeSmith: :| |
| 11:25 | <MikeSmith> | nice to use twitter for something useful |
| 11:31 | <MikeSmith> | "The nightmare scenario would be that the web platform ceases to be a platform at all, and simply becomes an amalgamation of JS bindings to various operating system APIs of varying capability" |
| 11:31 | <darobin> | hahaha |
| 11:31 | <darobin> | MikeSmith: where that from? |
| 11:32 | <MikeSmith> | darobin: https://groups.google.com/a/chromium.org/d/msg/blink-dev/4jBAnIVwrt0/v2qzjSNn_E8J |
| 11:32 | <darobin> | oh, I haven't read that thread yet — it seemed to hold promise :) |
| 11:34 | <MikeSmith> | darobin: maybe but I much prefer the "should we use auto?" thread on webkit-dev |
| 11:35 | <darobin> | haha, I started muting that one |
| 11:37 | <darobin> | MikeSmith: Jon Rimmer does have a very good point though |
| 11:38 | <darobin> | I mean, we've been talking about providing some sort of low level access to hardware, of the USB API kind, instead of creating dedicated APIs for all sorts of things |
| 11:38 | <darobin> | which makes a lot of sense in many ways — but what happens if the generic hardware API starts to become meaningless? |
| 11:40 | <annevk> | MikeSmith: has there been any recent interesting webkit-dev thread? |
| 11:40 | <annevk> | MikeSmith: given the way Apple works I expect most of it to be on secret-webkit-dev |
| 11:45 | <darobin> | annevk: it does feel that way reading the list |
| 11:46 | <MikeSmith> | darobin: bingo (about if generic hardware API starts to become meaningless) |
| 11:46 | <MikeSmith> | annevk: there have been some interesting ones yeah |
| 11:46 | MikeSmith | looks back |
| 11:47 | <annevk> | darobin: you need something more generic than USB or Bluetooth |
| 11:47 | <annevk> | darobin: it needs to be on the level of "implement a driver for a connected device" |
| 11:48 | <darobin> | annevk: yeah, but that still likely relies on OS-level assumptions. Also, I am always suspicious of that level of abstraction |
| 11:48 | <annevk> | darobin: which I guess comes down to having something similar to USB or Bluetooth for the web, and if your device wants to be compatible it needs to support that |
| 11:48 | <annevk> | darobin: you need to start from the assumption that the web is the OS |
| 11:48 | <darobin> | annevk: or there is a browser mapping of that to USB |
| 11:49 | <darobin> | annevk: yeah, I started from that assumption a long time ago :) |
| 11:49 | <MikeSmith> | annevk: anyway the src-N thread on webkit-dev was gold. looking forward to more like that |
| 11:49 | <darobin> | but still, it needs to be resilient to architectural changes |
| 11:49 | <annevk> | MikeSmith: fair |
| 11:49 | <annevk> | darobin: might just be called HTTP in the end |
| 11:49 | <MikeSmith> | QUIC |
| 11:49 | <darobin> | annevk: that's all very handwavy :) |
| 11:50 | <darobin> | hardware is, well, hard |
| 11:50 | <MikeSmith> | oops I mean SPDY |
| 11:50 | <annevk> | darobin: once you go down the route of two pieces that need to be connected over a network, you end up there pretty quickly |
| 11:51 | <annevk> | darobin: at first you think you need to have something low-level because nothing is capable, like WAP to HTML, and at some point you realize you were wrong |
| 11:51 | <darobin> | annevk: I know, and in fact there's very interesting work in that area. Though at this point they've made rather brutal optimisations |
| 11:52 | <darobin> | annevk: I will be amused when this all leads to EXI being supported in the browser (it's a common component in ZigBee's HTTP hardware stuff) |
| 11:52 | <darobin> | (it's one of the "brutal optimisations") |
| 11:54 | <MikeSmith> | darobin: somebody told me HTTP2 people were looking at EXI for imspiration for header compression |
| 11:55 | <darobin> | MikeSmith: I'm not sure if I'd want them to go that way, but it could in fact yield interesting results |
| 11:55 | <MikeSmith> | and today I see https://github.com/twitter/hpack but haven't looked at it the code |
| 11:55 | <darobin> | I suspect the complexity might be excessive though |
| 11:55 | <MikeSmith> | darobin: I dunno, Hiro told me that. Nakajima. and he's following it alll pretty closely |
| 11:56 | <darobin> | one of the advantages of using EXI is that people can compete on encoder quality while remaining interoperably decodable |
| 11:56 | <MikeSmith> | yeah that would be a good advantage |
| 11:56 | <darobin> | MikeSmith: I had mentioned it to the SPDY folks a long time ago when they had started working on this but they were dismissive |
| 11:56 | <zcorpan> | at least the "punch in the face" thread was a bit funny |
| 11:56 | <MikeSmith> | a lot has changed since then I guess |
| 11:57 | <darobin> | well, I guess that if someone involved in it has understood that the "X" in "EXI" is accidental, then advocacy can make headway from there |
| 11:58 | <darobin> | if EXI ever makes it into HTTP2 I think I'll retire |
| 11:58 | <MikeSmith> | zcorpan: "punch in the face" thread? |
| 11:58 | <MikeSmith> | https://twitter.com/pmarca/status/419257504913448960 btw |
| 11:58 | <darobin> | that's enough evil for a single lifetime |
| 11:59 | <zcorpan> | MikeSmith: http://www.w3.org/mid/01EDE259-9B0C-47BE-BA09-536877558EDD⊙gc |
| 12:00 | <MikeSmith> | zcorpan: ah yeah that guy was telling it like it is, really |
| 12:02 | <darobin> | yeah that was pretty funny :) |
| 12:02 | <darobin> | jgraham: I'm done reviewing https://critic.hoppipolla.co.uk/r/526, I'll leave the python bits to someone else |
| 12:03 | <jgraham> | darobin: Given the number of comments that's probably just as well :p |
| 12:03 | <darobin> | heh |
| 12:03 | <jgraham> | I might have to quibble over some style issues, but generally great work, thanks |
| 12:03 | <darobin> | well I did read the Python code, but I don't have much to say beyond the fact that I find it weird you find it easier to include a complete HTML serialiser rather than just use a template :) |
| 12:03 | <darobin> | jgraham: you're more than welcome :) |
| 12:04 | <darobin> | I can see where the style issues are coming from; I mean, it's JS written more or less as if it were Python |
| 12:58 | <Ms2ger> | jgraham, I agree with darobin for once (on ||) :) |
| 13:00 | <jgraham> | Sigh |
| 13:00 | <jgraham> | Well if everyone disagrees with me I will change it, but I don't think it's at all clearer |
| 13:00 | <MikeSmith> | uh oh things are heating up on that review. I feel a "punch in the face" message possibilty |
| 13:01 | <jgraham> | So I don't understand *why* people like it. Because it's slightly shorter? Because it feels clever? |
| 13:02 | <MikeSmith> | idiomatic |
| 13:02 | <jgraham> | ("slightly shorter" is honestly the best legitimate reason I can come up with, so if there is a better one I would like to know) |
| 13:03 | <Ms2ger> | Doesn't evaluate the x in x ? x : y twice |
| 13:03 | <jgraham> | MikeSmith: But I don't understand why it's idiomatic |
| 13:03 | <Ms2ger> | And the comparison with python doesn't make sense, it isn't "condition and value_if_true or value_if_false" but "value_if_true and value_if_true or value_if_false" |
| 13:04 | <jgraham> | Ms2ger: That isn't an actual problem in any case here and could be solved with the use of a variable if it was |
| 13:04 | <MikeSmith> | jgraham: I don't either in this case, really. |
| 13:04 | <jgraham> | Ms2ger: In python people have written value_if_true or value_if_false |
| 13:04 | <jgraham> | It works in exactly the same way |
| 13:04 | <Ms2ger> | Well yes |
| 13:04 | <Ms2ger> | Let's do that, then :) |
| 13:04 | <jgraham> | But these days I would expect anyone to use the ternary operator in Python |
| 13:05 | <jgraham> | (in either case) |
| 13:05 | <jgraham> | Certianly I would always write value_if_true if value_if_true else value_if_false |
| 13:05 | <Ms2ger> | I know you would :) |
| 13:06 | <Ms2ger> | I'm not convinced about anyone, though |
| 13:13 | <darobin> | whoa, I hadn't realised Ms2ger agreed with me |
| 13:13 | <darobin> | I might have to change my mind |
| 13:14 | <Ms2ger> | :D |
| 13:14 | <jgraham> | Good, then maybe we can end up with code that isn't only accessible to seasoned js veterans :p |
| 13:15 | <darobin> | oh please, this is an entry-level idiom |
| 13:15 | <jgraham> | But seriously, I am bored of arguing about this |
| 13:15 | <jgraham> | If you are prepared to forego this change resolve the issues |
| 13:15 | <darobin> | jgraham: hey! you're the one who just reopened the argument :) |
| 13:15 | <jgraham> | Otherwise I will change it |
| 13:16 | <darobin> | jgraham: IIRC the only problem I care about strongly is the asynchrony one |
| 13:16 | <darobin> | because that's actually a bug |
| 13:17 | <darobin> | the rest is IIRC just good practice stuff |
| 13:17 | <jgraham> | So the only other thing in the review that I recall thinking is better as-is was some of the public-vs-private stuff |
| 13:18 | <darobin> | public-vs-private? |
| 13:18 | <darobin> | oh you mean putting all your variables as attributes? |
| 13:18 | <jgraham> | Weren't there some things that you complained were only used from within the class? |
| 13:18 | <darobin> | oh, yes |
| 13:19 | <darobin> | it's not so much that I mind, but in reviewing the code if I see a method exposed I expect it to be something that's used from outside somehow |
| 13:19 | <darobin> | so for instance I'd wonder why load() doesn't take a path |
| 13:19 | <darobin> | it looked like you split out the init code into methods rather systematically, but it's not clear that they could actually meaningfully be used on their own |
| 13:20 | <jgraham> | I don't think they can, but the system was nice |
| 13:20 | <darobin> | jgraham: I don't reckon this is code that will get used by other code as a library, so it likely doesn't really matter in the long run |
| 13:20 | <jgraham> | No, I don't think anyone else will be using this for anything |
| 13:20 | <darobin> | but you never know, so I reviewed as I'd review any piece of JS |
| 13:21 | <jgraham> | Yep, like I said it's much appreciated |
| 14:28 | <zcorpan> | yoav: your way to write attributes is backwards (to what i'm used to, anyway) :-) |
| 14:29 | <yoav> | zcorpan: that sounds very likely :) |
| 14:31 | <yoav> | I normally don't use the @ thing to write attributes, so when I do, I get it wrong |
| 14:33 | <yoav> | zcorpan: Regarding https://github.com/ResponsiveImagesCG/picture-element/issues/89 , it requires direct changes in the HTML spec, right? Or are there existing hooks that can allow that? |
| 14:34 | <zcorpan> | yoav: i don't think it requires changes to the HTML spec in particular |
| 14:37 | <zcorpan> | yoav: the bug is asking to change "When asked to update the list of source sets for a given picture element picture, user agents must do the following:" to "When asked to update the list of source sets for a given img element img, user agents must do the following:" and then write the algorithm in terms of that |
| 14:37 | <zcorpan> | yoav: the difference is subtle, i guess |
| 14:38 | <yoav> | zcorpan: Yeah, I missed that |
| 14:40 | <yoav> | If no external hooks are required, I agree with you on this issue |
| 15:08 | <Ms2ger> | "USPTO.GOV still has URLs that return HTTP/0.9 responses." |
| 15:08 | <Ms2ger> | Yay, back-compat |
| 17:00 | <gsnedders> | Ms2ger: Compat with HTTP/0.9 is actually wonderful. Try and parse the response as HTTP/1.1; if you fail, treat it as HTTP/0.9. |
| 19:19 | <Hixie> | why does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2725 not work in firefox and safari? |
| 19:19 | <Hixie> | am i being dumb? |
| 19:25 | <jory> | Hixie: Seems like it's working in FF, AFAICT. |
| 19:25 | <Hixie> | what do you get? |
| 19:26 | Hixie | updates his nightly |
| 19:26 | <Hixie> | i get no message back even on the latest nightly |
| 19:39 | <jory> | Hixie: Actually, on reading what the code is actually supposed to do, it's not working in Chrome or FF... looks like setting <body.onmessage> doesn't actually set up your listener properly. |
| 19:39 | jory | remembers that consistency does not imply functioning, cause things can be consistently broken too |
| 19:41 | <zcorpan> | Hixie: i think offsetWidth is not useful to test since it has an explicit "am i rendered?" path and returns 0 |
| 19:42 | <Ms2ger> | Hixie, zero with setting the IDL attribute in Fx |
| 19:49 | <Hixie> | jory: i get a message in chrome, at least |
| 19:49 | <Hixie> | zcorpan: yeah, possible. not sure what is right to test. |
| 19:49 | <Hixie> | zcorpan: see thread in whatwg |
| 19:49 | <Hixie> | Ms2ger: ? |
| 19:51 | <Ms2ger> | document.body.onmessage = ... works |
| 19:51 | <jory> | Hixie: Yeah, it works in Canary, just not the... normal... one. |
| 19:51 | <jory> | Public one? I don't know what the term for the standard issue is. |
| 19:53 | <Hixie> | Ms2ger: weird |
| 19:53 | <Hixie> | jory: ah yeah, i'm only testing dev here |
| 19:54 | <Hixie> | i believe they call their variants stable, beta, dev, and canary i think |
| 19:57 | <zcorpan> | Hixie: maybe window.matchMedia. it returns null in firefox when the frame is invisible. blink returns the right object with .matches == true for '(width:0px)' as the query |
| 19:57 | <Hixie> | ah, not familiar with that API |
| 19:58 | <Hixie> | like i said in the thread, though, i'm happy to spec stuff if nobody wants to own this on the CSS side. |
| 19:58 | <zcorpan> | yeah i'm just popping in here to be clever :-) |
| 20:00 | <Hixie> | :-) |
| 20:01 | <zcorpan> | svg <switch> might also work |
| 20:03 | <zcorpan> | or maybe that didn't do media queries |
| 20:19 | <zcorpan> | MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20140107#l-387 - something in particular in the thread being gold? (pointer?) |
| 22:37 | <Ms2ger> | Hixie, dom.spec.whatwg.org appears to be down |
| 22:37 | <Ms2ger> | annevk-cloud, ^ |
| 22:38 | <krijn> | Haha, noobs! |
| 22:38 | <Ms2ger> | Also, how do you spec "in the DOM"? |
| 22:52 | <Hixie> | Ms2ger: wfm |
| 22:53 | <Hixie> | Ms2ger: how do you mean, "in the DOM"? |
| 22:53 | <Hixie> | Ms2ger: if you mean "in a document", HTML has some macros for that |
| 22:53 | <Ms2ger> | Furthest ancestor is the document |
| 22:53 | <Ms2ger> | And seems to be up now, yes |
| 22:54 | <Ms2ger> | And "in a document" was what I was looking for |
| 23:26 | <dbaron> | Hixie, so a number of years ago I remember thinking that the intent of the IDN (and maybe also IRI) specs was that different "slots" (places where a URI went) would have to specify individually whether they accepted the new features. Looking back now, I can't seem to find any backing for this understanding in the specs. Do you remember having a similar understanding, or was I just overinterpreting? |
| 23:28 | <Hixie> | i have the same understanding |
| 23:28 | <Hixie> | i don't really see how else it could work, i mean, you can't force places that only ever accepted ASCII to suddenly accept Unicode. |
| 23:29 | <dbaron> | looking at the specs now... it seems like IDN defines an "IDN-aware slot" concept... but that IRI then says IRIs can have unicode hostnames and essentially says they're IDN-aware |
| 23:29 | <Hixie> | IRIs are always IDN-aware. but not everywhere accepts IRIs. |
| 23:29 | <dbaron> | hmmm... pretty sure <a href="..."> deals with Unicode these days |
| 23:30 | <dbaron> | even though it didn't at one point |
| 23:30 | <Hixie> | well <a href=""> just references the URL standard, which bypasses all of the URI and IRI specs. |
| 23:30 | <dbaron> | right... I'm trying to finish a blog post about versioning that I started 7 years ago |
| 23:30 | <Hixie> | heh |
| 23:30 | <dbaron> | and one of the points I wanted to make about how some of those specs were doing it wrong |
| 23:31 | <dbaron> | but I'm having trouble finding evidence for that |
| 23:31 | <dbaron> | I think the thing we thought they were doing was wrong, but I'm no longer convinced it's what they say. |
| 23:31 | <Hixie> | with <a href=""> we added idn support by first updating all the software, basically. Also, we always accepted IRIs there, in a poorly-defined (until recently) way |
| 23:31 | <Hixie> | i dunno what doing it right would really look like for IDN. it's a tough space. |
| 23:31 | <Hixie> | there's better examples of "doing it wrong" for this kind of thing. |
| 23:32 | <Hixie> | XHTML2, e.g., but also XML 1.1 |
| 23:32 | <dbaron> | I was going to use XML 1.1 |
| 23:32 | <Hixie> | also people are always wanting to add versions to their protocols even though you can never really do anything with them |
| 23:32 | <dbaron> | though if I could use URI/IRI it would lead to much easier-to-read examples |
| 23:32 | <Hixie> | e.g. websocket ended up with some version nonsense |
| 23:33 | <Hixie> | despite my best efforts |
| 23:33 | <Hixie> | (sigh IETF) |
| 23:34 | <Hixie> | URI and IRI had lots of problems, but versioning isn't one of them, i think |
| 23:34 | <Hixie> | IDNA vs Unicode is a better example of versioning issues |
| 23:35 | <Hixie> | but anne is the one to ask about taht |
| 23:37 | <dbaron> | k, thanks for the help |