| 00:00 | <Hixie> | (if it _is_ "a lot of people" then you're right, we should investigate this further.) |
| 00:01 | <Clubbed> | tab, i'm building a webos, personally i want, but is not absolutely necessary the styling, but if i want to put a special control like a text input in my toolbar, or a checkbox in my contextmenu? |
| 00:01 | <Clubbed> | how i do it |
| 00:01 | <Clubbed> | ? |
| 00:01 | <Hixie> | a "webos"? |
| 00:01 | <Clubbed> | i will use an absolutely positioned div to emulate context menu |
| 00:01 | <Clubbed> | and a <ul> |
| 00:02 | <Clubbed> | for the toolbar |
| 00:02 | <Clubbed> | just old html4 |
| 00:02 | <Hixie> | sounds good |
| 00:02 | <Hixie> | what's the problem |
| 00:03 | <Clubbed> | the problem is that like me other people never will accept <menu> |
| 00:03 | <Clubbed> | they will continue to use divs |
| 00:03 | <Hixie> | what is your evidence that you are in the majority here? |
| 00:03 | <Hixie> | i've provided what i consider evidence that this is likely a minority position |
| 00:03 | <Hixie> | what is your counter-evidence? |
| 00:04 | <Clubbed> | uhm sorry i cannot understand this |
| 00:04 | <Clubbed> | my english is poor |
| 00:04 | <Clubbed> | try to write simply sorry |
| 00:04 | <Clubbed> | *simpler |
| 00:04 | <Hixie> | why do you think you more people want styling than not want styling |
| 00:05 | <Hixie> | more people want their scrollbars to be not styled than want them to be styled, if we look at the number of people styling their scrollbars |
| 00:05 | <Hixie> | so why do you think the opposite will be true for menus |
| 00:06 | <Clubbed> | uhm actually i think the same for the two cases |
| 00:07 | <Clubbed> | but styling is not adding an icon |
| 00:07 | <Clubbed> | my style can not be overriden, for example on <select> |
| 00:07 | <Clubbed> | but |
| 00:07 | <Clubbed> | in <option></option> of selects i want to put buttons |
| 00:07 | <Clubbed> | textareas |
| 00:07 | <Clubbed> | i want to put multiple icons |
| 00:08 | <Clubbed> | thats the point |
| 00:09 | <Hixie> | why? |
| 00:10 | <Clubbed> | why i can need it... |
| 00:11 | <Clubbed> | if the standard is the standard desktop toolkit |
| 00:11 | <Clubbed> | UIs will never go on |
| 00:11 | <Clubbed> | always the same |
| 00:12 | <TabAtkins> | The tools necessary to innovate in UI development already exist - use javascript and CSS, plus some accessibility help like ARIA. |
| 00:13 | <TabAtkins> | Then, *after* we've established that something new is wanted by a lot of people, we can add it to the language. |
| 00:13 | <TabAtkins> | Trying to guess what requirements people will have for new innovations is doomed to failure, and will just result in a lot of useless bloat in the spec that will end up getting in people's way more than it helps them. |
| 00:14 | <Clubbed> | ok but html5 is new, html4 is the experiment |
| 00:15 | <TabAtkins> | Sure, for some things it was. Now HTML5 is the experiment for a bunch of new things. |
| 00:16 | <Clubbed> | anyway ok... i will continue to use divs xD |
| 00:17 | <TabAtkins> | You'll have to for a while anyway, until browsers support <menu>. |
| 00:19 | <Clubbed> | ive written implementation for menu using css bindings but specs, as you see lol, does not match my needs of a really good tool kit |
| 00:20 | <Clubbed> | anyway i will match aria's things if possible |
| 00:22 | <Clubbed> | ah another question... what WG will do about clipboard |
| 00:23 | <Clubbed> | something like drag&drop? |
| 00:24 | <Clubbed> | i know security issues about clipboard |
| 00:28 | <KaOSoFt> | http://tech.slashdot.org/story/10/04/12/1816205/Google-Rebuilds-Docs-Platform |
| 00:34 | <Clubbed> | tabatkins -> http://img199.imageshack.us/img199/3540/googleep.png |
| 00:35 | <Clubbed> | going to bed |
| 00:35 | <Clubbed> | good night |
| 00:36 | <Hixie> | i suppose we could have told him that tab and i work for google |
| 00:36 | <TabAtkins> | Eh, no reason. |
| 00:37 | <Hixie> | in case he comes back, the image he pasted is a good use case, but one we can easily support in the future by adding more features to <menu> |
| 00:37 | <Hixie> | it doesn't argue for arbitrary styling or anything like that |
| 00:37 | <TabAtkins> | Man, I'm tired of writing this counter-proposal for Issue 100. It's annoying have to parse out actual objections from a wall of text, and further to separate objections to @srcdoc from the (much more numerous) objections to @sandbox itself. |
| 00:40 | <Hixie> | it's hard to write change proposals in general at the moment since we don't have much to go on in terms of figuring out how they'll be handled by the chairs |
| 00:41 | <Hixie> | in fact iirc all we have is the microdata one |
| 00:42 | <Hixie> | where a long list of good reasons didn't convince the chairs |
| 00:42 | <Hixie> | it's hard to know if a shorter list or a longer list would have had a different result |
| 00:48 | <JonathanNeal> | Was there a dialog element? |
| 00:48 | <JonathanNeal> | And was it removed? |
| 00:49 | <Hixie> | yes and yes |
| 00:51 | <JonathanNeal> | should embed be considered a new element? |
| 00:54 | <TabAtkins> | No, it's existed for a long time. |
| 00:56 | <JonathanNeal> | Hmm, it was listed @ http://www.w3.org/TR/html5-diff/#new-elements |
| 00:56 | <JonathanNeal> | Anyway, I was just trying to update the wikipedia page for new elements. |
| 00:57 | <TabAtkins> | It's new in the sense that it didn't exist in HTML4. But it was certainly used back then. |
| 00:58 | <JonathanNeal> | I ended up just re-ordering two of them to make them alphabetical (you can't have all but two in order!) and removed dialog. |
| 01:00 | <JonathanNeal> | I think the deprecated list could be larger too. |
| 01:06 | <JonathanNeal> | okay, updated both... so productive :-P |
| 01:09 | <TabAtkins> | Sent Issue 100 counter proposal. Now to look at Issue 92 and see if it's objectionable or not... |
| 01:17 | TabAtkins | finds no real reason to object to Issue 92. |
| 01:22 | <Hixie> | i wish i understood 92 |
| 01:22 | <TabAtkins> | Basically, the example table you've used is unrealstic and contrived. She's proposing a better example table. |
| 01:23 | <Hixie> | but that's not what the bug she escalated it from is asking for |
| 01:23 | <TabAtkins> | Complex enough to justify explanatory text about the headers, but still relatively simple to understand. |
| 01:23 | <TabAtkins> | Indeed, the bug is something different entirely. |
| 01:23 | <Hixie> | o_O |
| 01:23 | <TabAtkins> | Yeah, dunno. |
| 01:24 | <Hixie> | any idea which section she's trying to replace? |
| 01:24 | <Hixie> | i don't know what she means by "table element description section" |
| 01:25 | <TabAtkins> | In the description of the <table> element. |
| 01:25 | <Hixie> | oh |
| 01:25 | <Hixie> | what the whole thing? |
| 01:25 | <TabAtkins> | I'd have to look again. I *think* it's just the example table and related verbage? |
| 01:25 | <Hixie> | oh i see, she's trying to readd the summary="" attribute without telling anyone about it |
| 01:26 | <TabAtkins> | Well, yeah. |
| 01:26 | <TabAtkins> | Oh man, skipped over that entire paragraph. |
| 01:27 | <Hixie> | wow her example is terrible |
| 01:27 | <TabAtkins> | I think it's a pretty good table to use, at least. |
| 01:27 | <Hixie> | except it doesn't need a tabel description |
| 01:27 | <Hixie> | since it can be entirely derived from the table structure |
| 01:28 | <Hixie> | and she put a footer in a table cell |
| 01:28 | <Hixie> | ok well we'll see what the chairs do with this |
| 01:30 | <Hixie> | i like how she managed to file a bug to remove an example on the grounds that it is extraneous, and turned it into a change proposal that instead adds a new attribute and a bigger example |
| 01:33 | <TabAtkins> | I don't find it fundamentally wrong to have a CP arguing for a *better* example as a suggested fix for an issue saying the example is bad and should be removed. |
| 01:33 | <TabAtkins> | "should be removed" is a possibe solution, sure, but so is making the example less bad. |
| 01:37 | <Hixie> | if all she was doing is suggesting a better example, i wouldn't have rejected the bug |
| 01:37 | <Hixie> | she didn't ask for a better example, nor provide one |
| 01:38 | <Hixie> | and then she escalated this editorial bug and turned it into a way to smuggle the summary="" attribute back in |
| 01:39 | <Hixie> | (also, the proposedw table isn't better -- it doesn't need a table description at all, since it can be entirely derived from the table structure, and it has a footer in a cell) |
| 01:39 | <Hixie> | i wish we did have a better table though |
| 01:42 | <Hixie> | (another reason her table is a poor one is that even if it was one that needed a table description, it is far too long to repeat several times showing different ways of exposing the table description) |
| 02:46 | <MikeSmith> | boblet: I removed the Details section from the doc for nav |
| 02:46 | <MikeSmith> | I can re-add something there again later |
| 04:00 | <othermaciej> | hi everyone |
| 04:29 | <MikeSmith> | othermaciej: hey |
| 04:30 | <othermaciej> | hi MikeSmith! |
| 04:31 | <MikeSmith> | catching up with some unread mail and just reading about new webkit multiprocess stuff now |
| 04:42 | <othermaciej> | oh yeah that is neat stuff :-) |
| 04:46 | <wirepair> | whats this now? |
| 04:46 | <wirepair> | ah like chrome |
| 04:47 | <wirepair> | wonder if they will sandbox, or just keep split |
| 04:48 | <othermaciej> | split first |
| 04:49 | <wirepair> | yeah looks like they make hints at sandboxing |
| 04:49 | <wirepair> | "This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multicore CPUs" |
| 04:49 | othermaciej | is one of them |
| 04:49 | <wirepair> | oh ;> |
| 04:50 | <wirepair> | sorry i just kind of lurk here, not really up to speed with who everyone is and where they are at ;> |
| 04:51 | <othermaciej> | no worries |
| 04:51 | <othermaciej> | but you can ask questions if you want, here or on #webkit :-) |
| 04:51 | <wirepair> | good to know thanks ;> |
| 05:30 | <MikeSmithX> | the cafeteria at work is serving whale meat this semester |
| 05:35 | <othermaciej> | MikeSmithX: :- |
| 05:35 | <othermaciej> | :-( |
| 05:36 | <MikeSmithX> | yeah |
| 05:37 | <wirepair> | make them all watch that movie ;> |
| 05:37 | <wirepair> | or ask them if they are eating the meat for research |
| 08:30 | <Hixie> | MikeSmithX: your input on bug 9467 would be very welcome |
| 08:32 | <MikeSmith> | me looks around for Yudai |
| 08:32 | <MikeSmith> | Yudai, http://www.w3.org/Bugs/Public/show_bug.cgi?id=9467 |
| 08:33 | <MikeSmith> | Hixie: fwiw, "on" and "kun" are different phonetic readings for kanji |
| 08:33 | <MikeSmith> | I still don't understand the question there either, though |
| 08:33 | MikeSmith | looks more |
| 08:33 | <hsivonen> | argh. html5test.com tests SQL database and encumbered codecs as part of its "HTML5" score |
| 08:34 | <Hixie> | MikeSmith: well if you don't understand it, i'm certainly going to be way out of my depth :-) |
| 08:34 | <hsivonen> | so stuff like this emerges: http://geektechnica.com/2010/04/chrome-passes-html5-test-with-flying-colors/ |
| 08:34 | <Hixie> | MikeSmith: hopefully they'll comment further... |
| 08:34 | <Hixie> | yeah that test is a disaster |
| 08:34 | <othermaciej> | hsivonen: it also appears to have totally buggy tests |
| 08:35 | <Hixie> | i commented on reddit to that effect, but not sure what else can be done about it |
| 08:35 | <MikeSmith> | Hixie: I think you could just change it from "kanji reading" to "phonetic reading" |
| 08:35 | <othermaciej> | for example, it tells me my Safari supports Ogg Vorbis but not MP3 or AAC |
| 08:35 | <Hixie> | MikeSmith: k |
| 08:36 | <othermaciej> | also seems to think we support the <mark> element |
| 08:36 | <MikeSmith> | hsivonen: btw, I think I found a bug in the v.nu assertions code that is causing processChildContent() from ever being called at all |
| 08:36 | <hsivonen> | MikeSmith: oops... |
| 08:37 | <MikeSmith> | but it also seems like maybe the processChildContent stuff is dead code, anyway |
| 08:37 | <hsivonen> | which reminds me, that I was planning on redeploying V.nu yesterday |
| 08:37 | <hsivonen> | so I guess I should do it now |
| 08:37 | <Yudai> | I'm still stacking on rebuilding :) |
| 08:38 | <MikeSmith> | hsivonen: eclipse warns me: "The method isChildren() from the type Assertions.StackNode is never used locally ... The local variable parentName is never read ... The local variable add is never read" |
| 08:39 | <MikeSmith> | hsivonen: if something breaks when you rebuild, it may be because I forgot to commit something from my workspace |
| 08:39 | <MikeSmith> | Yudai is try to build from current source and says his build is failing |
| 08:40 | <Yudai> | MikeSmith: wait a moment |
| 08:40 | <hsivonen> | I'm building now on Ubuntu using OpenJDK |
| 08:41 | <hsivonen> | the build works for me |
| 08:41 | <MikeSmith> | cool |
| 08:42 | <hsivonen> | hmm. I think I'll land my option/datalist fix in the parser repo even though it lacks review for Gecko |
| 08:42 | <MikeSmith> | hsivonen: btw, I don't know if you saw, but Sean Fraser was trying to put together a ruby gem of v.nu and raised a bug to report that the build initially failed for him |
| 08:43 | <MikeSmith> | because of the known issue of needing to run the build twice after a initial/fresh checkout |
| 08:43 | <hsivonen> | yeah, the build script needs polishing |
| 08:43 | <hsivonen> | I'm personally annoyed at having to set JAVA_HOME |
| 08:43 | <MikeSmith> | yeah |
| 08:44 | <wirepair> | mike,you manage the html5.validator.nu? |
| 08:44 | <MikeSmith> | no |
| 08:44 | <hsivonen> | wirepair: I do |
| 08:44 | <wirepair> | ah, are you takign steps to block repeated requests/requests to localhost? |
| 08:45 | <wirepair> | just out of curiousity ;>, i think i spoke with hixie about this |
| 08:45 | <hsivonen> | whoa. what requests to localhost? |
| 08:45 | <wirepair> | so if anattacker does |
| 08:45 | <MikeSmith> | Hixie: somebody may likely complain about "phonetic reading", but I don't know any other way to explain it easily (without going into further confusing/esoteric/useless-in-this-context details about various possible readings of kanji in Japanese) |
| 08:45 | <wirepair> | http://localhost:8080 .... |
| 08:45 | <Hixie> | MikeSmith: k |
| 08:45 | <wirepair> | are you blocking things like that |
| 08:46 | <wirepair> | i was using it to validate google, and i notice it gave me google frances' site, so i realized the validator could basically be used as a proxy |
| 08:48 | <MikeSmith> | Hixie: http://dev.w3.org/html5/spec/dom.html#inter-element-whitespace means that <figcaption> </figcaption> does not contain content other than inter-element whitespace, right? |
| 08:48 | <MikeSmith> | because "Empty text nodes and text nodes consisting of just sequences of those characters are considered inter-element whitespace" |
| 08:49 | <Hixie> | yes, unless i'm missign something |
| 08:49 | <MikeSmith> | OK |
| 08:52 | <MikeSmith> | hsivonen: btw, I'm curious if you might remember why you have ignorableWhitespace implementation in the Checker code calling the characters method |
| 08:53 | <hsivonen> | MikeSmith: it's always legal per SAX to delegate ignorableWhitespace to characters if you aren't ignoring anything |
| 08:53 | <MikeSmith> | oh, OK |
| 08:53 | <MikeSmith> | didn't know that |
| 08:54 | <hsivonen> | wirepair: no, localhost isn't blocked |
| 08:54 | <wirepair> | hsivonen may want to do that ;> |
| 08:54 | <MikeSmith> | wirepair is a security maven |
| 08:54 | <hsivonen> | wirepair: localhost isn't supposed to have any services whose protection is IP-based |
| 08:54 | <wirepair> | so no jetty manager |
| 08:54 | <wirepair> | jmx-console... |
| 08:54 | <wirepair> | etc/ |
| 08:54 | <wirepair> | ? |
| 08:55 | <wirepair> | MikeSmith nah just a concerned citizen in this case ;> |
| 08:55 | <hsivonen> | wirepair: there's not supposed to be any of those things |
| 08:55 | <wirepair> | hsivonen cool, as long as you aren't worried |
| 08:55 | <hsivonen> | wirepair: validator.nu uses Jetty as a library |
| 08:55 | <hsivonen> | wirepair: validator.nu starts a Jetty HTTP listener |
| 08:56 | <hsivonen> | wirepair: Jetty doesn't start validator.nu |
| 08:56 | <wirepair> | gotcha |
| 08:57 | <hsivonen> | but I agree it would be proper defense in depth to block localhost |
| 08:57 | <hsivonen> | I have a vague recollection that I had some kind of hand-wavy localhost blocking |
| 08:57 | <hsivonen> | but I removed it |
| 08:57 | <wirepair> | hehe, yeah also be on the look out for people abusing it |
| 08:58 | <wirepair> | not fun to have people requesting www.nsa.gov/somescript.jsp?blah=1'; drop tables terrorists;-- ;D |
| 08:58 | <hsivonen> | if I readd it, I want to make sure the blocking actually works for IPv6 localhost and octal IPv4 localhost |
| 09:01 | <wirepair> | actually, if it were me i'd probably add an X-Forwarded-For: <origin ip> |
| 09:01 | <wirepair> | not sure if you are doing that already |
| 09:31 | <annevk> | gears of war 3 not until April 2011 |
| 09:31 | <annevk> | sad day |
| 09:35 | <annevk> | did people see this: http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ |
| 09:35 | <zcorpan> | i wonder what the multiple sources they refer to |
| 09:36 | <Hixie> | annevk: you should play Bad Company 2 if you have a PS3 |
| 09:37 | <MikeSmith> | annevk: didn't see that yet |
| 09:38 | <MikeSmith> | maybe the "multiple sources" are the same ones that said the Macbook refresh would happen today |
| 09:38 | <MikeSmith> | and they same ones who have been saying that for 2 months or whatever |
| 09:39 | <hsivonen> | let's see if the V.nu redeployment worked... |
| 09:39 | <hsivonen> | yay. it worked |
| 09:41 | zcorpan | wonders when xml-stylesheet checking will be deployed |
| 09:41 | <hsivonen> | zcorpan: has MikeSmith landed the code? |
| 09:41 | <zcorpan> | dunno |
| 09:41 | <MikeSmith> | no, I have not yet |
| 09:41 | <MikeSmith> | sorry |
| 09:41 | <MikeSmith> | hsivonen: I still need to make some refinements based on your review |
| 09:42 | <hsivonen> | MikeSmith: ok |
| 09:42 | <MikeSmith> | I will try to get back to that asap |
| 09:42 | <hsivonen> | anyway, the live v.nu should now match what's in the repos |
| 09:42 | <zcorpan> | cool |
| 09:44 | <hsivonen> | offtopic: has anyone purchased support from Canonical? |
| 09:45 | <annevk> | oh hey, Apple approved Opera Mini |
| 09:45 | <hsivonen> | their sales dept apparently isn't planning on telling me if a particular kind of problem is in scope of their support contract |
| 09:45 | <annevk> | hsivonen, ask @mpt on twitter? |
| 09:45 | annevk | is using Ubuntu without support |
| 09:45 | <hsivonen> | so I'm wondering if their support is has been any good for anyone else |
| 09:46 | <annevk> | well, if I have a real problem I can look up some phone numbers of people at the office that can help me out in case the interwebs has no answer |
| 09:47 | <zcorpan> | annevk: time for a blog post? |
| 09:49 | <annevk> | regarding Opera Mini you mean? |
| 09:49 | <zcorpan> | yeah |
| 09:49 | <annevk> | would make an easy filler for my one post a workday challange |
| 09:54 | <hsivonen> | validator.nu goes down for a kernel update |
| 09:55 | <hsivonen> | ...and back |
| 09:56 | <MikeSmith> | annevk: btw, do you know of any way to get free wifi at Schiphol? |
| 09:56 | <MikeSmith> | the prices that they wifi provider there charges are crazy |
| 09:57 | <MikeSmith> | it's a relatively great airport otherwise |
| 10:01 | <annevk> | in the lounge... |
| 10:02 | <annevk> | you could sit outside the lounge and pick up the single, the password is klm100413 (for today) iirc |
| 10:02 | <annevk> | or maybe just kl |
| 10:02 | <MikeSmith> | ah, cool |
| 10:02 | <annevk> | s/single/signal/ doh |
| 10:03 | <MikeSmith> | yeah, I did actually try that when I was there -- the signal part |
| 10:03 | <MikeSmith> | just didn't know what password to try |
| 10:06 | <MikeSmith> | role values are case sensitive? |
| 10:07 | <hsivonen> | html5.validator.nu going down for kernel update |
| 10:08 | <hsivonen> | MikeSmith: IIRC, yes. They were born in the XML world. |
| 10:08 | <jgraham> | You make them sound like orcs |
| 10:11 | <hsivonen> | ...and html5.validator.nu is back |
| 10:12 | <zcorpan> | hmm. r5032 is scary. i thought button was scoping at least in ie and opera? |
| 10:13 | <hsivonen> | zcorpan: button is crazy in IE |
| 10:13 | <hsivonen> | zcorpan: and magic in Opera |
| 10:13 | <hsivonen> | zcorpan: or if it's not magic, Opera allows links inside a <button> to be clicked |
| 10:14 | <hsivonen> | is there .deb for Opera 10.50 beta? |
| 10:15 | <annevk> | yeah |
| 10:15 | <annevk> | http://snapshot.opera.com/unix/snapshot-6306/ is the latest public build |
| 10:16 | <annevk> | well, it's not beta, but it's .deb and the latest build publicly available (10.51 actually) |
| 10:16 | <hsivonen> | annevk: thanks |
| 10:18 | <Hixie> | what should window.stop() do? |
| 10:19 | <Hixie> | cancel the fetching algorithm for the browsing context? |
| 10:19 | <hsivonen> | the menus in Opera 10.5x on Gnome are *much* nicer-looking than the old Windows 95-style menus |
| 10:20 | <mpt> | annevk, hsivonen, I don't work in the support department, sorry |
| 10:21 | <hsivonen> | mpt: ok. I guess I'll have to buy a 160-euro lottery ticket to make at least some progress |
| 10:21 | <micheil> | hey, which browsers support websockets? |
| 10:21 | <micheil> | / do websockets like working from localhost? |
| 10:22 | <jgraham> | micheil: I don't know of any browser that implements the new handshake |
| 10:22 | <jgraham> | But I'm not sure |
| 10:22 | <jgraham> | No reason they shouldn't work on localhost |
| 10:22 | <annevk> | Chrome has support for -75 I think |
| 10:22 | <jgraham> | Ah, cool |
| 10:22 | <micheil> | I'm having trouble getting chrome to even send or receive data, none of the events get called |
| 10:22 | <micheil> | I know it connects.. but then all is silent |
| 10:23 | <jgraham> | Does the handshake fail? |
| 10:23 | <jgraham> | Does anyone here know how you test if subversion has compiled in support for gnome-keyring? |
| 10:24 | <micheil> | no, I've removed the handshake from my code atm |
| 10:24 | <micheil> | although, I have an oddity |
| 10:24 | <hsivonen> | hmm. Opera 10.5x on Ubuntu doesn't use my anti-aliasing settings |
| 10:24 | <micheil> | I connected to a websocket I have access to on pusherapp.com (ws://ws.pusherapp.com:8080) |
| 10:25 | <micheil> | and it worked fine |
| 10:25 | <jgraham> | Well if chrome really does support the handshake and you don't have it then it would fail |
| 10:25 | <micheil> | eg, onopen was fired, although, try doing that from localhost:7000 for the websocket address and it fails to fire onopen |
| 10:25 | <hsivonen> | zcorpan: hmm. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/454 doesn't make the link clickable in Opera |
| 10:27 | <zcorpan> | hsivonen: indeed. doesn't seem to be clickable in firefox either |
| 10:27 | <hsivonen> | zcorpan: why are the links on http://www.gf-hunters.de/ clickable in Opera? |
| 10:28 | <hsivonen> | Inspect Element tells me that the links are nested inside the <button> |
| 10:28 | <micheil> | actually, probably the source of the error: http://code.google.com/p/chromium/issues/detail?id=36652 |
| 10:28 | <hsivonen> | zcorpan: at least making <button> non-scoping wouldn't be randomly novel, since it isn't scoping in WebKit |
| 10:29 | <hsivonen> | (aside: Firefox really needs to bring FireBug into the main product. Having Inspect Element work out-of-the-box is very convenient.) |
| 10:30 | <annevk> | btw, you can subscribe to http://my.opera.com/desktopteam/blog/ for Opera build updates; automatic updates is not enabled for non-stable releases unfortunately |
| 10:30 | <hsivonen> | annevk: thanks. |
| 10:30 | hsivonen | notes that Chrome beta channel integrates very nicely into the Ubuntu Update Manager |
| 10:30 | <mpt> | hsivonen, http://www.ubuntu.com/support/services/desktopcomparison |
| 10:31 | <annevk> | hsivonen, yeah indeed, we should do that too, but we only do it for stable releases :/ |
| 10:34 | <zcorpan> | hsivonen: i think that has to do with our hack where layout doesn't match the dom |
| 10:35 | <hsivonen> | zcorpan: well, then, that's not a suitable solution for the spec |
| 10:36 | <zcorpan> | hsivonen: indeed |
| 10:37 | <zcorpan> | hsivonen: i also noticed that opera closes button (but not object) for <ul><li><button><li> |
| 11:09 | <annevk> | zcorpan, done |
| 11:15 | <annevk> | funny: http://twitter.com/sgalineau/status/12070054472 |
| 11:18 | <micheil> | jgraham: I've finally got chrome connecting to my server.. |
| 11:19 | <asmodai> | Mmm, so next month VP8 will be made available under an OS-license. Interestink. |
| 11:24 | <annevk> | asmodai, indeed |
| 11:25 | <hsivonen> | annevk: when I follow the link from the tweet in Minefield, Bing warns me that my browser might not work well with Bing Maps and encourages me to install IE or Firefox |
| 11:26 | <annevk> | ugh, me too |
| 11:26 | annevk | didn't follow the link |
| 11:27 | <asmodai> | annevk: But what I understand Google wants to push Theora as lowest common denominator and then also make VP8 available |
| 11:28 | <hsivonen> | bah. Bing Maps 3D requires IE and .NET |
| 11:28 | <hsivonen> | still the old Microsoft |
| 12:02 | <Philip`> | Would it be possible to use parts of VP8 to improve Theora? |
| 12:03 | <Philip`> | (It's too late to change the file format but maybe there's new patented encoder techniques it could use, or something) |
| 12:28 | <micheil> | Hixie: hey, um, how should servers respond if the key3 is empty? eg, the client isn't using the new websocket authentication stuff |
| 12:41 | <jgraham> | micheil: Presumably you should drop the connection |
| 12:41 | <micheil> | which means no client could connect |
| 12:41 | <jgraham> | Well all clients have to send the 8 bytes |
| 12:41 | <micheil> | chrome doesn't. |
| 12:41 | <jgraham> | Yeah, because they need to change their implementation |
| 12:42 | <jgraham> | It is a breaking change |
| 12:42 | <micheil> | and so far it's only one of the major browsers supporting any form of things.. |
| 12:42 | <jgraham> | Right, which is why we can still make breaking changes |
| 12:43 | <jgraham> | Anyway if you were to go against spec and support clients that don't do the handshake, you would be exposes to the security issues the handshake is supposed to prevent |
| 12:44 | <jgraham> | *exposed |
| 12:44 | <micheil> | yeah, true |
| 12:44 | <micheil> | another thing is to try and get the flash fallbacks up to speed |
| 12:46 | <jgraham> | Has anyone developed a test client yet? |
| 12:47 | <jgraham> | Like telnet with a handshake |
| 12:49 | <jgraham> | Oh it looks like the go langauge has a ws client in the stdlib or something |
| 12:49 | <beowulf> | Hixie: ps3 username? |
| 12:49 | <jgraham> | http://golang.org/src/pkg/websocket/client.go |
| 12:49 | <jgraham> | (with the handshake stuff) |
| 13:59 | <zcorpan> | hmm, i guess script shouldn't be a raw text element in #writing |
| 14:29 | <annevk> | heh, just as I say what the fuck apple they release new macbooks |
| 14:33 | <zcorpan> | they were waiting for you |
| 14:34 | <annevk> | makes sense |
| 14:36 | <MikeSmith> | o |
| 14:36 | <MikeSmith> | cool |
| 14:37 | <MikeSmith> | I've not had the opportunity for a long time to purchase a first-generation piece of hardware that is likely to be highly unstable |
| 14:37 | <MikeSmith> | and maybe even catch on fire |
| 14:38 | <myakura> | MikeSmith: They didn't update 13-inch models. |
| 14:39 | <MikeSmith> | hmm, ueah, I see that now |
| 14:39 | <MikeSmith> | so no i5 for 13-inch |
| 14:39 | <MikeSmith> | that sucks |
| 14:40 | <micheil> | MikeSmith: it's a pitty that the prices seem to have gone up a bit. (even on the educational store) |
| 14:40 | <MikeSmith> | I don't want to lug around a 15-inch machine around all my drinking spots in Kagurazaka |
| 14:41 | micheil | wouldn't go for anything smaller then 15" |
| 14:42 | <MikeSmith> | micheil: we are at the mercy of our benevolent hardware providers in Cupertino |
| 14:42 | <MikeSmith> | we should just be happy that they continue to allow us to buy their products at exorbitant prices |
| 14:43 | <myakura> | annevk: I talked with guys organizing the HTML5 event in Fukuoka the other day and heard that they would like you to talk about the current status of CSS. Can you do that? |
| 14:43 | <micheil> | heh he |
| 14:43 | <annevk> | myakura, I saw that on wave, seems doable |
| 14:43 | <micheil> | MikeSmith: at any rate, you can't buy the i7 speced machine on the educational stores atm, it's a 404 |
| 14:44 | <annevk> | myakura, I thought they did update the 13'' models, don't they have way more battery life? |
| 14:44 | <myakura> | annevk: cool. |
| 14:44 | <MikeSmith> | micheil: that's just a sign that you have been judged unworthy |
| 14:44 | <micheil> | :P |
| 14:45 | <annevk> | myakura, see http://www.apple.com/pr/library/2010/04/13mbp.html |
| 14:45 | <myakura> | annevk: whoa. |
| 14:46 | Dashiva | looks at 700 emails in whatwg and w3c folders |
| 14:49 | <zcorpan> | Hixie: i thought philipj and hsivonen argued for removing auto-localizing <time> |
| 14:50 | <hsivonen> | How Apple-like to say i5 and i7 without saying which ones in those families |
| 14:50 | <Dashiva> | "CSS pixels are by definition square (well, technically they're by definition circular)" |
| 14:51 | <hsivonen> | I'm glad I already bought an "i7" desktop while Apple wasn't delivering, so now I don't need to think which MacBook Pro model to get |
| 14:51 | <annevk> | zcorpan, Hixie, yeah, I thought the idea was to kill that and leave it to CSS |
| 14:52 | <Lachy> | It's a shame that the 17" MacBook Pro still has the useless express card slot instead of an SD card reader like the other models. |
| 14:52 | <annevk> | funny that the 17'' is not the most advanced |
| 14:52 | <annevk> | oh, you can get that via options |
| 14:54 | <hsivonen> | looks like I'd have to pay over 1000 euros more to get less CPU in the portable Mac case than I paid in the desktop non-Mac case |
| 14:54 | Philip` | prefers defining pixels as samples of a band-limited continuous function over a square grid |
| 14:54 | <hsivonen> | but to Apple's credit, "anti-glare" is back as an option |
| 14:56 | <Philip`> | Incidentally, hexagonal pixels (i.e. sample points in a hexagonal grid) are a better idea than square pixels, since (I think) they maximise the representable frequency for a given number of pixels |
| 14:57 | <Dashiva> | I've always wondered how three subpixels per pixel fit into a square grid |
| 14:58 | <Philip`> | That's just a square grid with 3x the horizontal resolution |
| 14:58 | <annevk> | hsivonen, but you no longer have a laptop? |
| 14:58 | <Philip`> | (where "square" obviously means "rectangular") |
| 14:59 | <Dashiva> | But the subpixels aren't rectangular in their light-emitting part, are they? |
| 14:59 | <hsivonen> | annevk: I still have my old MacBook, too. |
| 15:00 | <hsivonen> | annevk: but I need the portability a couple of times a year |
| 15:00 | <hsivonen> | annevk: and I need fast Firefox compiles every day |
| 15:00 | <annevk> | fair enough |
| 15:01 | <hsivonen> | the saddest part of my Ubuntu migration is that I need to keep the Mac running in order to make email work |
| 15:01 | <hsivonen> | I really, really need to get a better overall email solution |
| 15:02 | <hsivonen> | also, I haven't found a GraphicConverter replacement for Ubuntu |
| 15:03 | <Philip`> | Dashiva: The ones on my monitor are rectangular if I look through a magnifying glass |
| 15:04 | <Dashiva> | Oh really? Interesting |
| 15:04 | <Philip`> | What other shape would they be? |
| 15:04 | <annevk> | hsivonen, Opera? ;) |
| 15:04 | <Dashiva> | I figured they'd be rounded square-ish |
| 15:05 | <Philip`> | I don't think the shape should matter anyway - what's important is that there's a regular offset between the grids of (sub)pixel samples |
| 15:05 | <hsivonen> | annevk: what I want is roughly: |
| 15:05 | <hsivonen> | 1) IMAP server |
| 15:05 | <hsivonen> | 2) SMTP server that records the outgoing addresses in my email |
| 15:06 | <hsivonen> | 3) server side filtering for the IMAP server so that the recorded previous outgoing addresses are whitelisted |
| 15:06 | Philip` | notes that his magnifying glass is one that came from a Christmas cracker many years ago, so he can't see precisely whether the coloured subpixels have sharp corners or not |
| 15:07 | <hsivonen> | 4) an as Ajaxy/HTML5-y as it gets webmail client that uses the IMAP and SMTP servers but still works in Fennec, too |
| 15:07 | <hsivonen> | these requirements seem like no-brainers to me |
| 15:07 | <hsivonen> | but it seems I want a solution that isn't available |
| 15:14 | <annevk> | sounds nice |
| 15:21 | <annevk> | whoa, only eleven open bugs |
| 15:21 | <annevk> | way to go Hixie |
| 15:23 | <Philip`> | Why has http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Apr/ had no updates since April 2? |
| 15:24 | <annevk> | no idea |
| 15:24 | <annevk> | MikeSmith, ^^ |
| 15:28 | <MikeSmith> | Philip`: no idea |
| 15:29 | <MikeSmith> | bugzilla borkedness, I suppose |
| 15:29 | <MikeSmith> | I will check |
| 15:41 | <MikeSmith> | ah, they changed the sender name of the bugzilla user |
| 15:41 | <MikeSmith> | used to be bugzilla⊙wwo |
| 15:41 | <MikeSmith> | and now it's bugzilla⊙jwo |
| 15:42 | <MikeSmith> | why it changed I have no idea |
| 15:45 | <MikeSmith> | I think it should be fixed now |
| 15:56 | <TabAtkins> | Anyone know what plh's timezone is? |
| 16:00 | <Philip`> | TabAtkins: plh knows; you could ask him once he's awake |
| 16:01 | <TabAtkins> | I'll just tell him my timezone in this email and let him work out when the best time to call is, then. |
| 16:35 | <TabAtkins> | Babbage quote ftw! |
| 16:44 | <zcorpan> | TabAtkins: re unbalanced </iframe>s, that's not really the case |
| 16:44 | <zcorpan> | TabAtkins: since iframe is a rawtext element, it can't contain "<iframe></iframe>" |
| 16:48 | <gsnedders> | What's a sane terminal emulator for X11 with useful features like, uh, "find"? |
| 16:48 | <zcorpan> | TabAtkins: but having it as text content of the iframe would involve knowing the legacy situation with <!-- |
| 16:49 | <Philip`> | gsnedders: Konsole? |
| 16:49 | <zcorpan> | wonder if we should add type="" to <pre> so that it can be exposed better to ATs |
| 16:53 | <gsnedders> | Philip`: That don't mean installing almost all of KDE? |
| 17:03 | <AryehGregor> | gsnedders, doesn't it only mean you need Qt or whatever? |
| 17:03 | <AryehGregor> | You don't need KDE's window manager or anything. |
| 17:03 | <AryehGregor> | (I hope) |
| 17:04 | <gsnedders> | kdebase4, kdelibs4… |
| 17:05 | <gsnedders> | Almost 100MB of stuff |
| 17:05 | <jgraham> | Anything from KDE needs all of KDE, always |
| 17:06 | <AryehGregor> | Well, if you're using Linux for a while, you'll probably have at least one KDE app installed. |
| 17:06 | <AryehGregor> | At least, I do. |
| 17:06 | <AryehGregor> | Random things like KCacheGrind. |
| 17:06 | <jgraham> | And a good goal in life is to have zero KDE stuff anywhere |
| 17:06 | <AryehGregor> | :P |
| 17:06 | <jgraham> | Because it is uniformly ugly |
| 17:06 | <TabAtkins> | That's an interseting definition of "good". |
| 17:06 | <AryehGregor> | It seems like GNOME Terminal really doesn't have "Find" anywhere that I can see. |
| 17:06 | <AryehGregor> | Interesting. |
| 17:07 | <jgraham> | No, it doesn't |
| 17:07 | jgraham | never noticed before |
| 17:07 | <AryehGregor> | jgraham, yeah, KDE apps look awful, at least if you're using GNOME. |
| 17:07 | <Philip`> | I don't understand why people want to avoid installing useful applications just because it'll use up a whole 0.01% of your disk space for dependencies |
| 17:07 | <AryehGregor> | Maybe they look better if the whole desktop is KDE. |
| 17:07 | <jgraham> | (but it would be useful I guess) |
| 17:07 | <gsnedders> | AryehGregor: Amazingly few terminal emulators do |
| 17:07 | <AryehGregor> | jgraham, you'd think so, but I don't think I've ever needed it in my whole time using terminals. |
| 17:07 | <gsnedders> | Sadly Konsole is the only good terminal emulator for X, AFAIK |
| 17:07 | <TabAtkins> | KDE apps do indeed look fine in KDE. I used Kubuntu for a while. |
| 17:07 | <jgraham> | AryehGregor: My experience is that it looks equally bad if the whole desktop is KDE. Worse even because there is necessarily more of it |
| 17:08 | <AryehGregor> | Interesting. |
| 17:08 | gsnedders | restrains jgraham |
| 17:08 | <gsnedders> | No being a GNOME fanboi. |
| 17:08 | <AryehGregor> | I prefer GNOME's minimalist philosophy, except of course when the default behavior is stupid *and* unchangeable. |
| 17:08 | <AryehGregor> | metacity is evil. |
| 17:08 | <AryehGregor> | When you have multiple monitors, it positions new windows on some random monitor of its choosing, not the current monitor. |
| 17:08 | <gsnedders> | But it's open source, what does it matter!!!11!!!!!!1!!eleventy!! |
| 17:08 | <jgraham> | (the problems I have are things like the fact that every app has about a million buttons) |
| 17:09 | <jgraham> | (to cover every usecase that every user ever had) |
| 17:09 | <AryehGregor> | Which gives you no control over where it goes when it's, e.g., fullscreen, or otherwise can't be moved between windows. Unless you want to break out wmctrl on the command line. |
| 17:09 | <AryehGregor> | jgraham, wait, you think this is bad but you work for Opera? |
| 17:09 | <jgraham> | (so it is impossible to actually do any of the things) |
| 17:09 | <jgraham> | AryehGregor: No comment :p |
| 17:10 | <gsnedders> | 10.50 doesn't have many buttons by default! |
| 17:10 | <jgraham> | AryehGregor: Anyway everyone uses compiz these days, no? |
| 17:10 | <AryehGregor> | Compiz doesn't work with nv, does it? So I don't. |
| 17:10 | <jgraham> | and compiz has a shed load of options if you install the control panel thing |
| 17:10 | <jgraham> | Far too many |
| 17:10 | <AryehGregor> | If it works with nouveau, then I guess I will in a couple of weeks when I go to 10.04. |
| 17:10 | <TabAtkins> | I spent an entire day playing with the options before shutting off almost all of them. |
| 17:11 | <AryehGregor> | Yeah, I remember that. I used to use it. |
| 17:11 | <jgraham> | But you need it to get the grid plugin working |
| 17:11 | <AryehGregor> | But Compiz interferes with Wine, and Wine is the only reason I'd bother installing a proprietary video driver. |
| 17:11 | TabAtkins | knows how to productively spend his time. |
| 17:11 | <jgraham> | And everything that is good about the grid plugin is (almost) everything that is bad about window mangement on OSX |
| 17:11 | <jgraham> | Actually that may be unfair |
| 17:12 | <jgraham> | There is a lot more wrong with window mangement on OSX than just the inability to place winwos nicely |
| 17:12 | <jgraham> | But that is really the main thing |
| 17:14 | <AryehGregor> | Window management on Windows always seemed to Just Work for me. |
| 17:15 | <TabAtkins> | It was never great, but it worked. Not nearly enough support for things nicely snapping to edges of other things. |
| 17:15 | <AryehGregor> | I finally got it to work okay on Linux, but the dual-monitor window placement of metacity is really annoying. I went to Xfce for a while and it worked much better. |
| 17:15 | <AryehGregor> | Yeah, that's a nice feature in Linux. |
| 17:15 | <AryehGregor> | Xfce panels are also way better than GNOME ones. |
| 17:15 | <AryehGregor> | Like, you can actually place them on non-primary monitors. |
| 17:15 | <AryehGregor> | And the icons don't randomly jump around every time you restart. |
| 17:15 | AryehGregor | tries to remember why he switched back to GNOME |
| 17:18 | <jgraham> | gsnedders: A gnome-terminal developer claims to be working on a patch for find btw |
| 17:18 | <gsnedders> | jgraham: Dude, it's already 2010. I don't care. |
| 17:18 | <gsnedders> | If you can't have find in 2010... |
| 17:19 | <jgraham> | You might get it by the end of 2010 |
| 17:21 | <jgraham> | You could install xsel, do select all and on a second terminal do xsel | less |
| 17:22 | <jgraham> | Although it crahsed when I tried that... |
| 17:25 | <micheil> | anyone know if the body in the WebSocket initialization should be in utf8 or ascii encoding? |
| 17:26 | <micheil> | the spec doesn't specify: "After the first 0x0D 0x0A 0x0D 0x0A byte sequence, indicating the end of the fields, the client sends eight random bytes. These are used in constructing the server handshake." |
| 17:27 | <TabAtkins> | You mean the "8 random bytes" part? |
| 17:27 | <micheil> | yeah |
| 17:27 | <TabAtkins> | Bytes dont' have an encoding. They're bytes. 8 bits. |
| 17:27 | <micheil> | how should the server interpret them? |
| 17:28 | <TabAtkins> | As bytes. |
| 17:28 | <micheil> | uhh.. |
| 17:28 | <TabAtkins> | They're not characters, and shouldn't be interpreted as such. |
| 17:28 | <micheil> | righteo.. |
| 17:28 | <jgraham> | micheil: They are 8 random numbers in the range 0 to 255 |
| 17:29 | <jgraham> | s/numbers/integers/ |
| 17:29 | <micheil> | jgraham: okay. I just have a few ways of implementing things |
| 17:29 | <micheil> | jgraham: I ended up removing the http parser I wrote and using the one from node's core |
| 18:00 | <Dashiva> | Good reason not to let code examples use smart quotes: client.open(’GET’, ‘demo.cgi’); |
| 18:02 | <TabAtkins> | Nothing should ever use smart quotes. >_< |
| 18:02 | <micheil> | TabAtkins: apart from typographers. |
| 18:02 | <micheil> | and writers. |
| 18:03 | <micheil> | programmers, probably not. |
| 18:03 | <TabAtkins> | Let me clarify. Nothing should ever use smartquotes in content. |
| 18:03 | <TabAtkins> | You can intelligently transform quotes into smartquotes at display time. |
| 18:07 | <Dashiva> | TabAtkins: Can you really, if there's code involved? |
| 18:07 | <TabAtkins> | Clearly, anything in <code> shouldn't have that applied. |
| 19:25 | AryehGregor | speculates about the rumored upcoming VP8 announcement |
| 19:26 | <TabAtkins> | Though I wouldn't leak anything if I *did* know anything, I still wish I knew something about it too. |
| 19:32 | <AryehGregor> | The question is, will it be like "Here's a cool demo, it might be practically more useful than some other codecs in some cases in the medium term maybe"? Or more like "We just released VP8 support in the Chrome dev channel, and YouTube is migrating to it over the next few years"? |
| 19:32 | <AryehGregor> | It can't be too awesome, or they wouldn't have seen fit to fund Theora on ARM. |
| 19:32 | <AryehGregor> | But it can't be too useless either, or they wouldn't have bought it. |
| 19:32 | <TabAtkins> | That's not necessarily true. We're a big org. Sometimes the left and right arm are both doing awesome things. |
| 19:32 | <AryehGregor> | Like Android vs. Chrome OS. |
| 19:32 | <AryehGregor> | Yeah, true. |
| 19:32 | <TabAtkins> | Yes. |
| 19:33 | <AryehGregor> | Some of the Theora people I know say that it's really an issue of having a mature, high-quality decoder, more than the format itself, that H.264 is better than Theora only because it has a more mature encoder, and that therefore VP8 isn't going to be a huge deal, but Theora can be made better with some more resources. |
| 19:33 | <AryehGregor> | At least, I saw that once. |
| 19:33 | <TabAtkins> | I've heard chatter to that effect too. |
| 19:34 | <TabAtkins> | Apparently Moz funding Theora dev made a big difference recently. |
| 19:36 | <AryehGregor> | But maybe VP8 uses some brilliant new technique that leapfrogs the existing stuff? I don't know why Google would buy it if it didn't think it could be better than Theora in the fairly near term. |
| 19:36 | <TabAtkins> | Yeah, honestly have no idea. |
| 19:36 | <TabAtkins> | Our <video> people aren't in Mountain View, anyway. |
| 19:36 | <othermaciej> | I have heard that Theora has some technical limitations which make it hard to be efficient at large (HD) video sizes |
| 19:37 | <othermaciej> | like motion vectors are limited to 8 pixels or something like that |
| 19:37 | <othermaciej> | which is fine at 320x200 but not so much at 1024x768 |
| 19:37 | <othermaciej> | note: not a codec expert |
| 19:37 | <AryehGregor> | Interesting. |
| 19:38 | <AryehGregor> | I've also heard that some codecs have very particular advantages and disadvantages. |
| 19:38 | <AryehGregor> | Like Theora can evidently be decoded a lot faster in software than H.264 can. |
| 19:38 | <AryehGregor> | And so on. |
| 19:38 | <AryehGregor> | Oh well, we'll see. |
| 19:38 | <AryehGregor> | Speculation is only fun up to a point. |
| 19:38 | <othermaciej> | I believe that is true, about sw decoding complexity |
| 20:07 | <micheil> | Hixie: are you about? |
| 20:11 | <jgraham> | It kinda makes sense that you would fund theora on mobile devices and something new for non-mobile if all of the above were true |
| 20:11 | <jgraham> | Since mobile devices typically don't need to do HD |
| 20:12 | <jgraham> | micheil: (I suggest you just ask and Hixie will reply when he is around) |
| 20:13 | <micheil> | okay, well, with websockets, and sending the body on the request without a Content-Length or Transfer-Encoding seems to go against RFC2068 |
| 20:13 | <micheil> | "The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers" |
| 20:14 | <jgraham> | So the hypothetical architecture is one where the HTTP server handles the entire request including the random bytes and then passes it off to a websockets handler |
| 20:15 | <micheil> | yeah, sorta |
| 20:15 | <jgraham> | Couldn't you just treat it like a request with no body and then have the WS server read 8 bytes from the network to get the random bytes? |
| 20:15 | <jgraham> | I mean at some point you have to hand over to WS-specific code |
| 20:16 | <micheil> | no. because the body is separated from the headers with \r\n\r\n |
| 20:21 | <jgraham> | So you only have a problem if the HTTP layer reads the headers, notices it is a websocket client, hands over to the websocket server, but also reads the body (even though the headers don't say there is a body) and doesn't make that avaliable to the WS server |
| 20:22 | <jgraham> | It's not clear to me why that would happen |
| 20:22 | <jgraham> | (it seems you could get into trouble with either design) |
| 20:24 | <micheil> | hmm.. |
| 20:24 | <micheil> | well, I've found a really hacked fix, not sure if it'll work though |
| 20:32 | <micheil> | I'm beginning to think it was easier to write my own header handler |
| 20:32 | <jgraham> | If you have the choice I expect it is |
| 20:33 | <jgraham> | I *think* parsing the initial headers is not that hard |
| 20:36 | <micheil> | I just hope every browser / client that implements websockets get's it write. |
| 20:36 | <micheil> | *right |
| 20:36 | <micheil> | jgraham: do you think it'd be possible for the body to be separated from the request at any stage? |
| 20:37 | <micheil> | ie, rather then it being: "GET ... \r\n .... \r\n\r\nBODY\r\n\r\n" |
| 20:38 | <micheil> | it gets received as "GET ... \r\n ... \r\n\r\n" and then later "BODY\rn\r\n" |
| 20:45 | <franksalim> | micheil, that is entirely possible |
| 20:45 | <micheil> | damn |
| 20:45 | <micheil> | not the answer I was hoping for |
| 20:46 | <KaOSoFt> | Good morning. |
| 20:47 | <micheil> | In which case I have no idea how I'm going to handle the http headers / meta for websocket connections.. |
| 20:49 | <franksalim> | micheil, i don't understand why you can't hand the stream over to the websocket server |
| 20:49 | <micheil> | uh. I'm writing the server |
| 20:50 | <micheil> | so, how I go about parsing the headers from the clients is fairly important |
| 20:50 | <franksalim> | i mean your server |
| 20:50 | <franksalim> | to clarify: hand the stream from the http code that parsed the request headers to the websocket code |
| 20:50 | <micheil> | oh, wait, my WebSocket server is reading the stream, it's a matter of parsing the headers |
| 20:51 | <micheil> | umm.. because, I'm implementing my server on top of network sockets, not a http server |
| 20:51 | <franksalim> | so you are parsing everything from byte 1 in your own websocket code |
| 20:51 | <micheil> | yes |
| 20:52 | <franksalim> | does your server understand websocket and http or just websocket |
| 20:52 | <Hixie> | beowulf: HixieThePixie http://bfbc2.statsverse.com/stats/ps3/HixieThePixie |
| 20:52 | <micheil> | it understands the websocket, however, needs to handle the http request sent for the websocket client initialisation |
| 20:53 | <franksalim> | and you are using an http library for that or writing your own header parsing code? |
| 20:53 | <Hixie> | micheil: anything i can help with re websockets? (i haven't read the backlog) |
| 20:53 | <micheil> | it'd be much better if the websocket spec said that the Content-Length field needed to be set |
| 20:53 | <micheil> | Hixie: that ^^ |
| 20:54 | <Hixie> | Content-Length: 0? |
| 20:54 | <Hixie> | i thought that was implied by the GET |
| 20:54 | <micheil> | it'd have to be Content-Length: 8 |
| 20:54 | <micheil> | for the 8 bits |
| 20:54 | <Hixie> | the 8 bytes aren't part of the GET request |
| 20:54 | <micheil> | and no, it's not implied by the GET |
| 20:54 | <Hixie> | they're the first 8 bytes after the upgrade |
| 20:55 | <micheil> | 0x0D 0x0A == \r\n, yeah? |
| 20:55 | <Hixie> | yep |
| 20:55 | <Hixie> | (unless you're using perl on windows) |
| 20:55 | <Hixie> | (or have changed the \n magic variable) |
| 20:55 | <Dashiva> | ... you're kidding |
| 20:55 | <Hixie> | (iirc $/) |
| 20:55 | <micheil> | in which case, the key3 value would be the body of the HTTP request |
| 20:56 | <Hixie> | GETs don't have bodies if they don't have a Content-Length |
| 20:56 | <Hixie> | just handle it in the same code you're going to use to handle the websocket frames |
| 20:56 | <micheil> | um.. although, the request will probably look like.. |
| 20:58 | <micheil> | http://gist.github.com/365024 |
| 20:59 | <micheil> | Hixie: or am I wrong in thinking that? |
| 21:00 | <Hixie> | there's no \r\n after the 8 bytes |
| 21:00 | <micheil> | okay, well, any rate, leave off one and it would work? |
| 21:00 | <Hixie> | the first byte after the 8th byte will be a 0x00 byte from the first frame |
| 21:02 | <micheil> | okay |
| 21:02 | <micheil> | so, removing the two \r\n\r\n at the end of that data, and it's right? |
| 21:02 | <micheil> | eg, ...le.com\r\n\r\n^n:ds[4U |
| 21:04 | <micheil> | hmm.. |
| 21:04 | <Hixie> | looks right |
| 21:04 | <Hixie> | but i haven't checked the details |
| 21:04 | <Hixie> | there's some examples in the spec if that helps |
| 21:05 | <micheil> | yeah, I'm constantly cross-referencing stuff |
| 21:05 | <Hixie> | cool |
| 21:06 | <micheil> | I'm wanting to make sure this client is spec-compliant |
| 21:06 | <micheil> | I'm still not sure if I want it to drop connections not using Sec-* (ie, all current webbrowser clients) |
| 21:11 | <micheil> | Hixie: any opinions on that? |
| 21:14 | <micheil> | Hixie: at any rate, thanks for the clarification and help :) |
| 21:14 | <Hixie> | well right now the spec isn't done |
| 21:14 | <Hixie> | so anything you do is going to need to change again before long |
| 21:14 | <micheil> | true |
| 21:15 | <Hixie> | whether you temporarily support the other work-in-progress implementations is up to you |
| 21:15 | <micheil> | hmm.. I could add a useStrict flag in the options for the server as to whether to reject or allow clients not sending Sec-* |
| 21:16 | <micheil> | hmm.. to bed: it's 6:22am.. |
| 21:18 | <franksalim> | micheil, goodnight |
| 22:40 | <TabAtkins> | echo? |
| 22:46 | <Dashiva> | Is Shelley still going on about SQL injection as a problem with @srcdoc?! |
| 22:46 | <TabAtkins> | Yes. Yes she is. |
| 22:48 | <Dashiva> | I'm having trouble maintaining a belief in good faith intentions |
| 22:49 | <TabAtkins> | Not quite sure how an author can simultaneously be absolutely brain-dead stupid enough to think that using @srcdoc somehow protects against SQL injection from form-submitted data, but simultaneously be intelligent enough not to eat his own keyboard. |
| 22:49 | <TabAtkins> | Yeah, no, good-faith has long been abandoned in my mind. |
| 23:02 | <Philip`> | In a process where there's no penalty for making bad arguments, and you believe a proposal should be accepted, it seems only rational to provide as many arguments as you can think of regardless of their quality because maybe somebody will accidentally believe some of them |
| 23:03 | <Hixie> | yeah, that's pretty much the problem here |
| 23:05 | <Dashiva> | <Philip`> In a process where there's no penalty for making bad arguments, and you believe a proposal should be accepted, it seems only rational to provide as many arguments as you can think of regardless of their quality because maybe somebody will accidentally believe some of them |
| 23:05 | <Dashiva> | For you, othermaciej :) |
| 23:05 | <TabAtkins> | Which unfortunately creates more work for everyone, as there's more crap to wade through, and then you still have to debunk the crap arguments. |
| 23:05 | <othermaciej> | Dashiva: pardon? |
| 23:05 | <Philip`> | (Of course a process that penalises good arguments because of nearby bad arguments would be irrational, because things should be decided based on the merits of good arguments) |
| 23:05 | <Philip`> | (so there's no good solution) |
| 23:08 | <Dashiva> | othermaciej: Talking about how there's no reason to not make bogus arguments to bog down "the others" |
| 23:09 | <othermaciej> | the only penalty for bad arguments is that readers may pay less heed to your good arguments |
| 23:10 | <Dashiva> | They don't have a choice with change proposals involved |
| 23:10 | <TabAtkins> | othermaciej: That's not a real penalty, as your bad arguments will still generate work for others. |
| 23:10 | <Dashiva> | You must address everything to be sure bad stuff doesn't happen |
| 23:11 | <othermaciej> | TabAtkins: the chairs have rejected Change Proposals before for lacking rationale |
| 23:11 | <othermaciej> | TabAtkins: but we're reluctant to do a really deep analysis |
| 23:12 | <Dashiva> | If you create a proposal with one real argument and ten bogus arguments, that's a lot of extra work for counter-proposals |
| 23:12 | <othermaciej> | we'll only reject if the rationale is completely missing, or just transparently inadequate (e.g. tautological or does not actually cover all changes in the proposal) |
| 23:12 | <TabAtkins> | othermaciej: That's not stopping bad arguments from dominating a change proposal. A single good argument in rationale is enough to carry a bunch of bad arguments, all of which have to be addressed. ;_; |
| 23:12 | <othermaciej> | TabAtkins: well, a counter-proposal doesn't necessarly have to address every single argument from any Change Proposal it is opposed to |
| 23:13 | <TabAtkins> | And since the CP accept/reject mechanism is completely opaque, we have no idea how important it is to address any particular argument. |
| 23:13 | <othermaciej> | it just has to make the case that the status quo is better than the change |
| 23:13 | <othermaciej> | the chairs would likely mention if it seems like there are points worth addressing that haven't been |
| 23:14 | <othermaciej> | anyway, I get a sense that you are somewhat dissatisfied, but I'm not sure if you have a specific proposal for what the chairs might do differently |
| 23:14 | <TabAtkins> | Not right now, no. |
| 23:14 | <Dashiva> | Perhaps allow striking of obviously invalid arguments |
| 23:16 | <TabAtkins> | Something along that line might work. The essential problem is that, since the accept/reject process is a single opaque step at the end, there's no way to know *where* to apply energy. |
| 23:17 | <TabAtkins> | Feedback as things move along would at least allow CP authors to know which arguments to strengthen, and counter authors to know which ones don't need to be addressed. |
| 23:18 | <TabAtkins> | Not sure precisely how to address or obtain "more feedback", but I feel it's the basic weakness in the Issue process. |
| 23:18 | <murz> | You can use HTML5 elements on a page that uses an HTML4 or XHTML1.1 declaration, right? All that really matters it that the browser supports the element, the DTD is mostly just to trigger standards mode and to tell validators which rules to use? |
| 23:19 | <TabAtkins> | There's no practical difference, no. |
| 23:19 | <TabAtkins> | DTDs are *entirely* to trigger standards mode. |
| 23:20 | <paul_irish> | that's a great question. people also are commonly curious if javascript or RTL things change with different doctypes. |
| 23:23 | <TabAtkins> | level all |
| 23:27 | <annevk> | actually, DOCTYPEs are, DTDs are irrelevant |
| 23:47 | <MikeSmith> | TabAtkins: is "level all" a secret masonic code phrase or something? |
| 23:47 | <Dashiva> | It's the password to the secret whatwg treehouse |
| 23:47 | <TabAtkins> | Damn, was hoping that wasn't actually posted to everything. |
| 23:48 | <MikeSmith> | in full effect |
| 23:48 | <TabAtkins> | I've been trying to configure irssi to not show joins and quits. |
| 23:48 | <MikeSmith> | ah |
| 23:48 | <othermaciej> | TabAtkins: the chairs give feedback on form, the WG participants themselves hopefully give technical feedback on the actual validity / convincingness of the arguments |
| 23:49 | <TabAtkins> | othermaciej: That doesn't address my concern, which is that the chairs make the final decision on validity/convincingness of arguments, but we have no way of knowing how valid/convincing a given argument is going to be, and thus we must devote energy to *every* argument, even the stupid ones. |
| 23:50 | <othermaciej> | TabAtkins: on the Microdata issue, I believe the Chairs gave specific feedback before we went to a poll on which arguments did not seem sufficiently addressed by the other side |
| 23:50 | <Hixie> | and tab didn't convince you, so clearly he didn't have enough information on how to convince you :-) |
| 23:51 | <othermaciej> | that's like saying if you lose a case in court, you must not have known enough about the law |
| 23:51 | <TabAtkins> | I'm not talking about the Microdata issue. At the moment, I'm talking about Issue 100, where there are a number of completely irrelevant or even nonsensical arguments, that I nonetheless had to address. |
| 23:51 | <TabAtkins> | I actually wrote more for several points before deciding to just be terse and say they were irrelevant. |
| 23:51 | <othermaciej> | your first audience for your Change Proposal should be the Working Group |
| 23:51 | <othermaciej> | so write whatever you think is useful to persuade WG members in general |
| 23:52 | <TabAtkins> | I will. But my final audience is the chairs. |
| 23:52 | <othermaciej> | we want polls / written decisions to be the last resort |
| 23:52 | <othermaciej> | though I don't think we'll be so fortunate as to have 0 more of them |
| 23:52 | <Dashiva> | So what about all the "kill element x" proposals, that got massive pushback from the wg? |
| 23:53 | <othermaciej> | clearly the author of those did not do a good job of persuading the WG, at least so far |
| 23:53 | <Dashiva> | They aren't very likely to end in amicable resolution |
| 23:53 | <Dashiva> | Doesn't that ensure a chair decision or poll? |
| 23:53 | <TabAtkins> | Where "very likely" is defined as "0". ^_^ |
| 23:53 | <TabAtkins> | s/very likely/not very likely/ |
| 23:53 | <othermaciej> | depends on whether the one supporter of those proposals agrees to back down after seeing the counter |
| 23:53 | <othermaciej> | if not, we'll decide what to do next |
