| 03:11 | <Guest54349> | hi |
| 03:11 | <Guest54349> | anyone here?? |
| 05:51 | <Hixie> | odd, why does ::first-line not work on a div with display:table-row? |
| 05:51 | <Hixie> | surely it should still select the first line in the first cell, even though those are implied? |
| 10:09 | <matjas> | is bugzilla.validator.nu dead forever or is it still “temporary”? |
| 10:42 | <Ms2ger> | matjas, that would be a question for hsivonen |
| 10:53 | smaug____ | wonders why streams API is using promises for everything |
| 10:55 | <darobin> | thoughtcrime! |
| 11:01 | smaug____ | will file bugs |
| 11:04 | <zcorpan> | jgraham: wptserve crashed on startup. not every time though. python(53333) malloc: *** error for object 0x7fd151ea8938: incorrect checksum for freed object - object was probably modified after being freed. |
| 11:06 | <jgraham> | zcorpan: :-o |
| 11:07 | <jgraham> | zcorpan: Which python version? |
| 11:07 | <zcorpan> | jgraham: i think 2.7 |
| 11:07 | <zcorpan> | 2.7.2 |
| 11:08 | <Ms2ger> | Nice |
| 11:09 | <smaug____> | just a little security bug in python ? |
| 11:10 | <jgraham> | Which version of OSX is this? The latest one? The mac I have access to seems to have 2.7.5 |
| 11:10 | <zcorpan> | maybe i was just BEING HACKED!!11 |
| 11:10 | <zcorpan> | except i didn't notice any bipperly boops like on TV so i guess not |
| 11:10 | <zcorpan> | 10.8.3 |
| 11:11 | <jgraham> | zcorpan: Also, did you see that I maybe fixed the OSX problems you were having on Friday? |
| 11:11 | <jgraham> | So the latest master ought to work |
| 11:11 | <zcorpan> | yeah, this is the latest |
| 11:11 | <zcorpan> | which works when it doesn't crash, so that's good |
| 11:12 | <annevk> | seems other people worked this weekend |
| 11:13 | <jgraham> | zcorpan: This seems to be 10.9 |
| 11:13 | <jgraham> | Fancy upgrading? ;) |
| 11:13 | <zcorpan> | maybe, but not today :-) |
| 11:14 | <jgraham> | Bah |
| 11:14 | <jgraham> | Well in any case this is "clearly" a bug in python |
| 11:15 | <jgraham> | I'm not sure how much time I should spend trying to work around it |
| 11:16 | <zcorpan> | if you were to work around it you'd first need to know what triggers it, and at that point it seems more productive to file a bug on python instead |
| 11:17 | <zcorpan> | i can try restarting the server a number of times and see if it reproduces |
| 11:18 | <zcorpan> | ah, got it again |
| 11:18 | <zcorpan> | INFO:mod_pywebsocket.standalone.WebSocketServer:Bind on: (2, 1, 6, '', ('127.0.0.1', 58727)) |
| 11:18 | <zcorpan> | python(53431) malloc: *** error for object 0x7fd2d4001f48: incorrect checksum for freed object - object was probably modified after being freed. |
| 11:18 | <zcorpan> | *** set a breakpoint in malloc_error_break to debug |
| 11:18 | <zcorpan> | INFO:mod_pywebsocket.standalone.WebSocketServer:Listen on: (2, 1, 6, '', ('127.0.0.1', 58727)) |
| 11:19 | <jgraham> | Well I can't reporduce it with 2.7.5 |
| 11:20 | <jgraham> | Which kind of suggests that the python bug has been fixed |
| 12:08 | <MikeSmith> | matjas: I don't think bugzilla.validator.nu is intentionally down. as far as I know, hsivonen intends for it to be up |
| 12:40 | <hsivonen> | matjas, MikeSmith: sorry. thanks for the report. I made a DNS configuration mistake that caused bugzilla.validator.nu to drop off DNS |
| 12:41 | <hsivonen> | it should be back in 3 hours or so as DNS caches expire |
| 14:21 | <matjas> | hsivonen: thanks! |
| 14:23 | <annevk> | Hmm, I hate the distinction between "URL" and "parsed URL" |
| 14:41 | <werle> | annevk: I was and still am quite confused by it |
| 14:41 | <annevk> | werle: Hixie wanted URL to mean a string that's parsed into a parsed URL |
| 14:41 | <werle> | I've been learning to just think of the specs as black boxes that define expected i/o |
| 14:41 | <annevk> | werle: I wanted URL to mean the abstract thing |
| 14:42 | <werle> | yes |
| 14:42 | <werle> | that makes more sense |
| 14:42 | <annevk> | but yeah, specs are basically i/o agreements |
| 14:43 | <werle> | :) yeah |
| 14:43 | <werle> | I've been doing C implementations of url and utf8 and that is the only true way to think about it instead of literal implementation |
| 14:44 | jgraham | agrees with Hixie |
| 14:44 | <jgraham> | I don't think that making URL mean a datastructure makes much sense |
| 14:44 | gsnedders | agrees with annevk |
| 14:45 | <annevk> | now fight |
| 14:45 | <werle> | haha |
| 14:45 | <MikeSmith> | "URL object" maybe..? |
| 14:45 | <gsnedders> | I cannot agree with jgraham, as a mater of principle. |
| 14:45 | <jgraham> | If gsnedders agress with annevk then I am sure I am right :p |
| 14:45 | <gsnedders> | *matter |
| 14:45 | <werle> | I kind of see both sides of the argument :) (switzerland) |
| 14:47 | <annevk> | In particular I don't think we need the distinction. We call "<x>Y</x>" an element. We also call HTMLUnknownElement in a tree an element. |
| 14:48 | <annevk> | It's not a big deal. Both "http://example.org"; and it's parsed http://example.org/ equivalent can be a URL. |
| 14:48 | <annevk> | And if you need a distinction you'd qualify with syntax/writing/model/parsed/... |
| 14:49 | <annevk> | This is what I've done for most other terms in the URL standard. Didn't want to have port and parsed port, domain and parsed domain, etc. |
| 14:49 | <annevk> | At some point I might remove parsed URL and call it a day. |
| 14:51 | <jgraham> | annevk: It seems like there is a pretty fundamental difference between a string representation of a URL and a data structure representing the components. Whereas the port and so on are the same kind of object in both cases, but in the parsed case might have a more limited set of allowed values |
| 14:52 | <annevk> | jgraham: hmm. A host is either a list of labels or an IPv6 address, which is either a largish number or a list of them... |
| 14:53 | <annevk> | jgraham: there's modelling all the way down |
| 14:54 | <jgraham> | annevk: host is a bit of a strange case and I think I would prefer two/three seperate terms in the spec |
| 14:55 | <annevk> | jgraham: it's not like people actually use terms in that way |
| 14:55 | <jgraham> | If you ought to implement the two things as different datatypes then they should have different names imo |
| 14:55 | <annevk> | jgraham: so I'm not sure it'll help communication |
| 14:55 | <annevk> | jgraham: e.g. consider my element example above |
| 14:56 | <annevk> | jgraham: I haven't heard people talk about parsed URLs in practice; people are confused with relative/absolute URLs already |
| 14:56 | <jgraham> | I think if I call a string an element I am implicitly talking about its parsed repreesentation |
| 14:57 | <annevk> | I think the same is true for URLs |
| 14:57 | <jgraham> | annevk: I don't think normal people need to care much about parsed URLs |
| 14:57 | <annevk> | they shouldn't care much about URLs at all |
| 14:57 | <jgraham> | It's a term for implementors who benefit from more precision |
| 15:01 | <annevk> | Yeah I don't think implementors would care much about that distinction. See above for one of them ;-) |
| 15:02 | <annevk> | I suspect they'd just use natural terms to explain the difference, just like the spec does with writing vs model vs API |
| 15:03 | <annevk> | Having a lot of jargon can actually make a conversation harder to follow. |
| 15:05 | <jgraham> | Well I am an implementor in this case, so we are one all in anecdotes-from-implementors |
| 15:19 | <Ms2ger> | Zing |
| 15:20 | darobin | thinks the precision is only needed if there are cases in which one could confuse the two |
| 15:21 | <werle> | jgraham: +1 |
| 15:41 | <annevk> | hober: http://i.imgur.com/dJQD877.jpg |
| 15:47 | <zewt> | nonblocking connect() to unix domain sockets is totally broken in linux? :| |
| 15:47 | <zewt> | open source go go go |
| 15:48 | <jgraham> | zewt: Patches welcome? :p |
| 15:48 | <zewt> | yeah no |
| 16:04 | <annevk> | hsivonen: http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Nov/0001.html |
| 16:11 | <hsivonen> | annevk: I considered giving that feedback. Then after discussing it some more with experts and thinking more, I decided not to give that feedback. |
| 16:11 | <jgraham> | hsivonen: Are you prepared to elaborate on why? |
| 16:11 | <jgraham> | It seems extrodinary sensible feedback to me |
| 16:12 | <jgraham> | *extrodinarily |
| 16:12 | <jgraham> | Oh, something |
| 16:13 | <hsivonen> | jgraham: I couldn't think of what I'd like the API to look like considering the use cases |
| 16:14 | <hsivonen> | jgraham: I'd need to refresh my memory to see what the use cases were |
| 16:14 | <hsivonen> | but I have to step outside right about now, so I can't refresh my memory now |
| 16:15 | <jgraham> | At the very least the feedback that "subtle" is a terrible name is good, even if the API ends up having lots of footgun potential for other reasons |
| 16:15 | <smaug____> | stepping outside is often a good way to refresh memory :) |
| 16:15 | <karlcow> | annevk: In the case of 304 Not Modified, the server can strip most of all headers except those necessary for the caching. What a client should do if this resource was containing previously CORS headers, and not in the 304 Not Modified: Error or just take the information which is relevant for the caching. |
| 16:15 | karlcow | was trying to find a relevant bug on Mozilla bugzilla without success |
| 16:16 | <hsivonen> | jgraham: I did give feedback that reflected my unhappiness about the notion that regular JS app developers would use the API |
| 16:16 | <hsivonen> | I know enough to recognize the API as a footgun |
| 16:17 | <hsivonen> | worse for those who don't know enough to recognize it as a footgun |
| 16:17 | <annevk> | hsivonen: renaming "subtle" to "unsafe" would be a start |
| 16:17 | <hsivonen> | annevk: sure |
| 16:17 | <annevk> | karlcow: good question, not sure |
| 16:17 | <annevk> | karlcow: what happens today? |
| 16:17 | <karlcow> | It seems it fails in Firefox and works in Chromium |
| 16:20 | <annevk> | I would kind of lean towards Firefox' behavior here given that it matches what we require for redirects. |
| 16:20 | <annevk> | 304 in Fetch is a red box at the moment for different reasons, but it seems this would be an additional one. |
| 16:22 | <karlcow> | yup I guess formal tests would be needed. |
| 16:22 | <karlcow> | for the record Related http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-25#section-4.1 |
| 16:28 | <Ms2ger> | https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vXuOTK5M0hM |
| 16:29 | <annevk> | Ms2ger: was an interesting read at the start of the day |
| 16:31 | <SimonSapin> | annevk: is your day starting now? |
| 16:31 | <Ms2ger> | annevk, want to summarize? |
| 16:31 | <annevk> | SimonSapin: no |
| 16:33 | <annevk> | Ms2ger: OMG TTML; abarth: no new complexity please; OMG OMG TTML; abarth: *sigh*; glenn: I'm on the AC! Mozilla has said nothing; annevk: we have actually. |
| 16:33 | <abarth> | annevk: thanks for commenting on that thread |
| 16:33 | <Ms2ger> | Heh |
| 16:33 | <Ms2ger> | Go annevk |
| 16:33 | <abarth> | annevk: it sounds like we have a similar perspective on this topic :) |
| 16:33 | <annevk> | yeah |
| 16:34 | <SimonSapin> | and what did Mozilla say? (hum.) |
| 16:35 | <annevk> | SimonSapin: http://lists.w3.org/Archives/Public/www-archive/2013May/0034.html is our statement |
| 16:36 | <annevk> | SimonSapin: https://groups.google.com/d/topic/mozilla.dev.platform/m9K94yLq9-U/discussion has more |
| 16:36 | <SimonSapin> | thanks |
| 17:56 | <Hixie> | annevk: "<x>Y</x>" isn't an element. it's a string with two tags and some text. |
| 17:57 | <Hixie> | annevk: if you talk about the element <x>, you mean the object that can be parsed from <x>, not the <x> itself |
| 17:57 | <Hixie> | annevk: in general, people don't talk about the strings, though |
| 17:57 | <Hixie> | annevk: whereas with URLs, people talk about the strings all the time |
| 17:58 | <Hixie> | annevk: URLs are treated as opaque strings quite often, in fact (e.g. if you tell someone to "go to http://example.com/";, you aren't trying to tell them to "use an HTTP GET request at the address that the host name "example.com" resolves to", you're telling them to give that string to a UA and let the UA deal with it) |
| 18:15 | <dglazkov> | good morning, Whatwg! |
| 19:31 | <ytrezq> | dglazkov: It's the evening here..... :p |
| 19:49 | <Hixie> | is http://wiki.whatwg.org/wiki/WorkerCanvas the proposal that has the most vendors on board? is anyone implementing anything like that? |
| 19:50 | <Ms2ger> | I think something is happening in Gecko |
| 19:53 | <Ms2ger> | Hixie, https://bugzilla.mozilla.org/show_bug.cgi?id=709490 |
| 21:27 | <Hixie> | someone used a term on the whatwg list that i didn't understand |
| 21:27 | <Hixie> | so i did a google search for that term |
| 21:27 | <Hixie> | their e-mail to the whatwg list was the first hit :-( |
| 21:30 | <TabAtkins> | What was the term? |
| 21:30 | <TabAtkins> | (Also, that happens constantly on the XKCD forums. Some obscure math or science question pops up, you go to google for it, and if it's been at least 10 minutes since it's been posted, the thread is already the top hit for it.) |
| 21:46 | <Hixie> | TabAtkins: "2D pixel-based graphics" |
