| 00:07 | <paul_irish> | z-index, of course requires an element to be positioned, but positioned elements often don't play well with transformed elements. but i want to manage z-order of my transformed elements. is it worth considering z-index apply to tranformed elements or should vendors address issues of positioned transformed elems? |
| 01:28 | <Hixie> | man, can you imagine how the last 10 years on the web would have been if html4 had defined the semantics of elements to the level of care and detail that y'all are making me put into the elements' definitions now? |
| 01:28 | Hixie | updates the wording of the definition of <article> once again |
| 01:31 | <TabAtkins> | Hixie: Good or bad? |
| 01:32 | <TabAtkins> | paul_irish_: How does z-index and transformations play badly together? |
| 01:32 | <micheil> | Hixie: you could put in a claus that every time the spec gets updated for a minor word change that a kitten gets killed. |
| 01:32 | <Hixie> | TabAtkins: good, i hope |
| 01:33 | <Hixie> | micheil: that would be bad given how many minor mistakes i make |
| 01:33 | <aho> | padding + transform is really weird imo |
| 01:33 | <micheil> | heh, it was more a reference to yesterday |
| 01:33 | <micheil> | http://drp.ly/1rhtfH |
| 01:33 | <aho> | eg 0 10px + 90° = 10px 10px ish |
| 01:34 | <aho> | (is it really supposed to be like this?) :> |
| 01:42 | <TabAtkins> | aho: Yes. transforms don't alter the geometry of the object - it still takes up exactly as much space as it did before. So, the space previously taken up by the horizontal padding still exists, but the element also appears to now have "vertical" padding. |
| 01:48 | <myakura> | looks like http://www.whatwg.org/specs/web-apps/current-work/complete/ is gone. something gone wrong? politics? |
| 01:50 | <TabAtkins> | It's not gone on purpose. |
| 02:25 | <Hixie> | myakura: fixed |
| 03:34 | <myakura> | Hixie: Thanks! |
| 07:54 | <hsivonen> | what makes Web authors declare iso-10646 in meta? |
| 07:55 | <hsivonen> | ...on pages that aren't in UTF-16BE |
| 07:58 | <Rik`> | copy paste ? |
| 08:04 | <hsivonen> | where would you copy iso-10646 from? |
| 08:05 | <estellevw> | lol |
| 08:06 | <Matjas> | How would you guys go about marking up a FAQ? I’m thinking of using a <dl> but I’m not sure if that's a good idea. |
| 08:06 | <Matjas> | i.e. <dl> <dt>Q: foo</dt> <dd>A: bar</dd> </dl> |
| 08:06 | <hsivonen> | Matjas: that works |
| 08:07 | <estellevw> | well, is the answer really defining the question? |
| 08:07 | <Rik`> | hsivonen: maybe wrong interpretation of http://www.w3.org/TR/html4/charset.html ? |
| 08:08 | <estellevw> | I think <dl> is very oftne, if not generally used for FAQ, but that's not quite semantically correct |
| 08:09 | <Hixie> | estellevw: it is in HTML5 as far as I can tell |
| 08:09 | <Hixie> | indeed the example for <dt> is a FAQ: http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-dt-element |
| 08:15 | <estellevw> | i was looking here: http://dev.w3.org/html5/markup/dt.html, name or term |
| 08:16 | <Hixie> | that's not the html5 spec |
| 08:16 | <estellevw> | yeah, i know |
| 08:16 | <estellevw> | thinking that page needs to be updated to reflect that ther ehas been a change |
| 08:17 | <estellevw> | that is the quick cheat sheet that a lot of implmenetors are using |
| 08:17 | <Hixie> | HTML5 itself is pretty clear that "name" is not being used in the english sense here but in the sense of an association list |
| 08:18 | <Hixie> | but I guess it could be made even clearer |
| 08:18 | <Matjas> | Thanks hsivonen, Hixie and estellevw! |
| 08:18 | <annevk> | estellevw, which implementors? |
| 08:19 | <estellevw> | There was a lot of discussion around DL at openwebcamp last week |
| 08:19 | <Hixie> | i assume estellevw means authors, not implementors |
| 08:19 | <estellevw> | front end engineers |
| 08:19 | <estellevw> | yes |
| 08:19 | <estellevw> | sorry |
| 08:19 | <Hixie> | np :-) |
| 08:19 | <estellevw> | i'm a front end. I implement at work ;) |
| 08:19 | Hixie | has filed a bug to make HTML5 clearer about this btw |
| 08:21 | <estellevw> | the discussion revolved around the semantics, screen readers, accessibility, etc. I htink the conclusion was that it wasn't quite semantic, but it was the best solution. Glad to see the nuanced change in the HTML5. Good change. And, good to get an official clarification |
| 08:21 | <estellevw> | Plus, the next time I see everyone, i can say "I told you so" :D |
| 08:27 | hsivonen | believes the relationship of semantics and screen readers gets exaggerated |
| 08:31 | <estellevw> | hsivonen: Open Web Camp, had several visually impaired users in attendance. It made for interesting conversation, and blew away many notions of what people had assumed were tenets of accessibility. |
| 08:31 | <Hixie> | like what? |
| 08:32 | <estellevw> | Many believed the title attribute to be very useful for accessibility. |
| 08:32 | <Hixie> | current screen readers make it basically impossible to read the title="" attribute |
| 08:32 | <estellevw> | seems that they're not helpful at all for users of screen reader. y |
| 08:32 | <Hixie> | it's a major bug in current screen readers |
| 08:32 | <estellevw> | yeah |
| 08:33 | <Hixie> | seems so easy to fix, too, dunno why they don't |
| 08:33 | <estellevw> | probably because most authors abuse the title attribute for feeding google |
| 08:33 | <Hixie> | (just have an audio cue when a title="" is available on the element being read out, and have a key to immediately play back the titles of the text currently being played) |
| 08:34 | estellevw | trying to remember 'author' not 'implementor' |
| 08:34 | <Hixie> | (plus something to navigate by title, but that can be added to the many existing navigation mechanisms) |
| 08:36 | <Hixie> | user/reader, author/webdev/coder/designer/page/app, implementor/vendor/ua/browser |
| 08:36 | <Hixie> | the three main classes |
| 08:36 | <zdenekkostal> | Could you say in HTML5 spec. how screen readers should read and understand the content? I think it would be very usefull for web developers, because when I code some project, I haven't enought time to test it in screen readers... |
| 08:37 | <estellevw> | I don't test in screen readers either |
| 08:38 | <estellevw> | the best quick accessibility checks involve navigating your page without your mouse (just use the keyboard), and test the page without images and without css to see how the screen reader would read the page (leave javascript on) |
| 08:38 | <Hixie> | if you're on a mac you can use voiceover to test it |
| 08:39 | <estellevw> | Windows 7 has a very cool reader as well. |
| 08:39 | <estellevw> | unfortunately (or fortunately) I don't have windows 7 yet |
| 11:32 | <annevk> | so unless something unforeseen happens I'm going to Maastricht after all |
| 11:41 | <hsivonen> | annevk: how long is the meeting? I thought it would be over by now. |
| 11:42 | <annevk> | it's tomorrow midday |
| 11:42 | <annevk> | I'm just going for hybi |
| 11:48 | <hsivonen> | annevk: "fun" |
| 11:49 | <hsivonen> | so in the meta charset sniffing "UTF-16" is special-cased |
| 11:49 | <annevk> | we'll see |
| 11:49 | <hsivonen> | does that really mean "UTF-16" only or also BE, LE and 32? |
| 11:49 | <annevk> | hopefully talking F2F will help clarify a few things |
| 11:49 | <annevk> | UTF-32 is irrelevant |
| 11:50 | <annevk> | iirc it just means UTF-16 case-insensitive |
| 11:51 | <hsivonen> | ok. how about the other cases in the spec where the charset of a URL is checked for "UTF-16", does that mean BE and LE, too? |
| 11:51 | <hsivonen> | (my guess is yes) |
| 11:51 | <annevk> | oh sorry |
| 11:51 | <annevk> | it says "a UTF-16 encoding" |
| 11:51 | <annevk> | I guess that means all of them |
| 11:52 | <hsivonen> | aliases, too? |
| 11:52 | <hsivonen> | it seems to me Safari doesn't do aliases |
| 11:53 | <hsivonen> | UTF-16 is such a bad idea :-( |
| 11:53 | <hsivonen> | must have seemed great at the time |
| 11:53 | <annevk> | aliases too |
| 11:53 | <annevk> | in fact, lots of the encoding stuff are pretty bad ideas |
| 11:54 | <annevk> | one day i'll sort it out |
| 11:54 | <Ms2ger> | Good luck |
| 11:54 | <annevk> | and ICU can be obsoleted |
| 11:54 | <annevk> | I made quite a bit of progress with encoding detection |
| 11:54 | <hsivonen> | annevk: it's good to have goals |
| 11:54 | <annevk> | and encodings to be supported by popular user agents |
| 11:55 | <annevk> | what there's yet to do is defining for each encoding how it maps to Unicode |
| 11:55 | <annevk> | (and possibly how it maps back) |
| 11:55 | <hsivonen> | annevk: doesn't ftp.unicode.org already do that except for Microsoft deltas? |
| 11:55 | <annevk> | in more detail than encodings are defined today (e.g. precise error handling for UTF-8) and more compatible (lots of ASIAN encodings support more than the standards indicate) |
| 11:55 | <hsivonen> | annevk: ok. |
| 11:57 | <hsivonen> | Woohoo. at least this iso-10646 thing isn't my mistake but a spec bug :-) |
| 11:57 | hsivonen | files |
| 12:18 | <hsivonen> | Philip`: do you happen to have something that you could grep for pages that say iso-10646 in meta and don't have an HTTP-level charset? |
| 12:19 | <hsivonen> | I'd like to know if those pages work better as UTF-8 or as Windows-1252 |
| 12:19 | <hsivonen> | or UTF-8 vs. chardet + default |
| 12:22 | <hsivonen> | Philip`: it would be great to have similar data for UTF-16BE, UTF-16LE, UTF-32, UTF-32BE and UTF-32LE |
| 12:24 | <Philip`> | hsivonen: http://philip.html5.org/data/charsets-2.html#charset-iso-10646-1 |
| 12:25 | <Peter`> | Ericsson seems to be playing around with implementing <device> in WebKit: https://labs.ericsson.com/blog/beyond-html5-implementing-device-and-stream-management-webkit |
| 12:25 | <hsivonen> | Philip`: thanks! (looks like a rare value, thankfully) |
| 12:25 | <Philip`> | hsivonen: Also http://philip.html5.org/data/charsets.html#charset-iso-10646 from a smaller but possibly more reliable set of pages |
| 12:27 | Philip` | doesn't entirely trust his data analysis, particularly for non-ASCII-compatible encodings |
| 12:31 | <annevk> | Peter`, pretty cool |
| 12:31 | <annevk> | Peter`, though not sure why they use video_player rather than media |
| 12:32 | <hsivonen> | the UTF-32 cases no longer say UTF-32... |
| 12:33 | <jgraham> | othermaciej: Are you or abarth going to be at the hybi meting? |
| 12:34 | <othermaciej> | jgraham: definitely not me |
| 12:34 | <annevk> | hsivonen, in the spec? UTF-32 support was dropped |
| 12:35 | <hsivonen> | annevk: the pages listed as UTF-32 in Philip`'s data |
| 12:35 | <Peter`> | annevk: apparently they use a hack to circomvent security limitations during development |
| 12:38 | hsivonen | mumbles about x-imap4-modified-utf7 and Java's modified UTF-8 |
| 12:43 | <hsivonen> | does webkit.org have a source code search that doesn't search changesets? |
| 12:43 | <hsivonen> | (I'm looking for the code that maps UTF-16 to UTF-8 in meta) |
| 12:51 | <Philip`> | hsivonen: Google Code Search with package:webkit sort of works, vaguely |
| 12:51 | <hsivonen> | dear lazy IRC, how do I make Ubuntu show me crash stacks for apps that have debug symbols but that don't come from Canonical? |
| 12:51 | <hsivonen> | Philip`: thanks |
| 12:51 | <Philip`> | Looks like it might be http://trac.webkit.org/browser/trunk/WebCore/loader/TextResourceDecoder.cpp?rev=64262#L344 |
| 12:52 | <Philip`> | and http://trac.webkit.org/browser/trunk/WebCore/platform/text/TextEncoding.cpp#L224 which returns UTF-8 |
| 12:52 | <Philip`> | perhaps |
| 12:52 | <jgraham> | othermaciej: OK. Do you have any opinion on the framing issue? Both technical and whether it is worth discussing in the "four week" timescale? |
| 12:52 | <hsivonen> | Philip`: interesting. thanks. that doesn't match my black-box testing, though |
| 12:53 | <othermaciej> | (I wonder if we should be saying "message" instead of "frame") |
| 12:53 | <hsivonen> | (or I misinterpret what "Default" means in Safari's menu) |
| 12:53 | <hsivonen> | does Default in Safari mean "what page said" or "user's default"? |
| 12:53 | <othermaciej> | jgraham: I think length-delimited text frames would be slightly technically superior to sentinel-delimited, but I don't care very much either way |
| 12:54 | <othermaciej> | jgraham: I think it's essential for text and binary to be clearly distinguished, and I think using presence/absence of a MIME type or whether the MIME type starts with text/ are very poor ways to signal text vs binary |
| 12:55 | <othermaciej> | jgraham: if we want to change text frames to be length-delimited, it probably needs to happen sooner rather than later |
| 12:55 | <jgraham> | othermaciej: OK, that mirrors my thoughts rather well. SO I am a little more confident that I am not toally off base :) |
| 12:56 | <jgraham> | I wonder if no one is discussing the handshake issue because they don't feel confident, or simply because the conversation has been led astray |
| 12:57 | <hsivonen> | Philip`: blame points to encoding, not decoding: https://bugs.webkit.org/show_bug.cgi?id=21635 |
| 12:58 | hsivonen | wonders what proportion of Web users globally is behind a proxy |
| 13:14 | <hsivonen> | non-UTF-8 encodings lead to unhappiness |
| 13:14 | <annevk> | yeah |
| 13:15 | <annevk> | can't believe this Greg Wilkins is pushing for non-UTF-8 support in WebSocket |
| 13:15 | <annevk> | I often get the feeling with him he's just pushing for features |
| 13:15 | <annevk> | features and complexity |
| 13:16 | <hsivonen> | annevk: I trust Hixie is good at saying "no" in that case |
| 13:17 | <hsivonen> | annevk: what's the rationale for non-UTF-8? |
| 13:18 | <hsivonen> | Hixie: fwiw, when <acronym> is obsoleted, it would be logical to zap <strong>, <em>, <kbd>, <samp> and <cite>, too |
| 13:19 | <annevk> | UTF-16 was there and "potential future encodings" |
| 13:19 | <hsivonen> | (maybe not practical for validator user-friendliness but consistent with the removal of <acronym>) |
| 13:19 | <hsivonen> | annevk: that's so sad |
| 13:21 | <hsivonen> | If we ever run out of UTF-8, it's more likely to start allowing 6-byte sequences than to come up with something new |
| 13:35 | <annevk> | it in fact allowed those once |
| 13:52 | <annevk> | is there a counter proposal for http://lists.w3.org/Archives/Public/public-html/2010Jan/1006.html to keep the wiki in place? |
| 13:52 | <annevk> | having more things rely on IANA is a step backwards imo |
| 13:53 | <hsivonen> | what's the deal with having to log in to the W3C bugzilla all the time? |
| 14:10 | <othermaciej> | annevk: no one ever wrote a counter-proposal |
| 14:18 | <annevk> | meh |
| 14:21 | <crash\> | Must HTML5 browsers conform with the XHTML-Syntax and support application/xhtml+xml? |
| 14:22 | <annevk> | no |
| 14:24 | <crash\> | Is there anything about Processing Instructions in the descriped HTML parsing process? |
| 14:24 | <crash\> | are they simply skipped? |
| 14:24 | <annevk> | they are treated as bogus comments |
| 14:25 | <crash\> | ok, thanks |
| 14:29 | <Lachy> | othermaciej, given the new information about RFC 20 from Leif yesterday, how will that affect the current ASCII ref poll? |
| 14:29 | <annevk> | RFC 20 also does not refer to Unicode |
| 14:44 | <hsivonen> | the recent polyglot threads demonstrate why working on a polyglot draft is bad |
| 14:44 | <hsivonen> | it's a time sink for the WG |
| 14:45 | <Lachy> | it's especially bad when we start getting requests for polyglot-only syntax, which really goes against the whole concept of what a polyglot document is. |
| 14:46 | <hsivonen> | Lachy: indeed |
| 14:57 | <jgraham> | I really wish I had a clue why anyone wants to add MIME to WebSockets |
| 14:57 | <jgraham> | Or specifically Content-Type |
| 15:17 | <hsivonen> | argh. I got trolled into the polygot threads again |
| 15:33 | <Lachy> | does anyone know where the Mozilla's useragent stylesheet html.css file has gone? It no longer appears in the res directory, as it did in older Firefox builds? I'm trying to see exactly what the new styles for figure are in now in Minefield |
| 15:34 | <Lachy> | oh, same as blockquote. |
| 15:35 | <Lachy> | found it via DOM Inspector. |
| 15:48 | <Ms2ger> | Lachy, that's what the spec said |
| 15:49 | <annevk> | fun -- http://www.flumotion.com/first_webm_live_event.php -- WebM streaming |
| 15:49 | <annevk> | seems to work fine |
| 15:49 | <annevk> | although the the time and general controls seem a bit off |
| 15:50 | <hsivonen> | so weird to see "Oracle" on the projector |
| 15:51 | <hsivonen> | why do they only advertise Opera and Firefox? Is streaming broken in Chrome? |
| 15:52 | <annevk> | hmm, someone is talking about chrome usability, but it's not mpt afaik |
| 15:52 | <annevk> | hsivonen, maybe it's not in Chrome beta builds yet? |
| 15:56 | <annevk> | s/chrome/Ubuntu/ doh |
| 15:56 | <annevk> | well, GNOME |
| 15:59 | <zdenekkostal> | the WebM streaming is incredible! Only timeline in Opera seems broken |
| 16:00 | <hsivonen> | works great in Minefield. the timeline was a bit jumpy during the first minute but now it looks ok |
| 16:05 | <jgraham> | hsivonen: You know how you love document.write... |
| 16:05 | <Lachy> | doesn't work in chromium for me on Mac |
| 16:05 | <Lachy> | shows one frame, but doesn't play |
| 16:05 | <jgraham> | I just found some odd behaviour that seems to be a Gecko (+WebKit) bug... |
| 16:16 | <hsivonen> | jgraham: what's the behavior? |
| 16:16 | <jgraham> | hsivonen: One moment |
| 16:19 | <jgraham> | hsivonen: I can't reproduce over HTTP :( |
| 16:19 | <jgraham> | I think it is a race condition |
| 16:19 | <jgraham> | http://hoppipolla.co.uk/tests/document_write/001.html |
| 16:20 | <jgraham> | The odd behaviour in WebKit reproduces though |
| 16:20 | <jgraham> | hsivonen: When I run it locally I get output like: |
| 16:20 | <jgraham> | 0,54,1,50,2,51,3,56,4,61,4,1280417173326 |
| 16:21 | <jgraham> | It also didn't reproduce when I moved all the js inline |
| 16:21 | <jgraham> | (but did in WebKit, where I think it is not a race condition, just mildly crazy) |
| 16:23 | <hsivonen> | Is see 0,52,1,49,2,51,3,49,4,50 in Minefield over HTTP |
| 16:23 | <jgraham> | hsivonen: Yeah, that looks sane |
| 16:23 | <jgraham> | And is the same as I see over HTTP |
| 16:24 | <hsivonen> | ok. that *is* weird |
| 16:24 | <hsivonen> | jgraham: thanks |
| 16:25 | <jgraham> | hsivonen: (it is not a HTTP vs non-HTTP thing because it is wrong if I run it from a local apache) |
| 16:25 | <jgraham> | (so I assume it is speed) |
| 16:27 | <hsivonen> | speed of the external script load vs. the initial iframe load? |
| 16:27 | <jgraham> | Could be |
| 16:28 | <hsivonen> | maybe a local script gets read in as one event loop task |
| 16:31 | <hsivonen> | jgraham: filed as https://bugzilla.mozilla.org/show_bug.cgi?id=582975 |
| 16:33 | <jgraham> | hsivonen: Thanks |
| 16:36 | <colapop> | jgraham: isn't start_time null at the time you set the event listener? Maybe the race condition is it fires & calls done() before start_time is initialized? |
| 16:37 | <colapop> | er, nevermind :) |
| 17:08 | <othermaciej> | I don't see where RFC 20 was mentioned |
| 17:15 | <TabAtkins> | othermaciej: In the latest message to the "Issue 101: us-ascii-ref - Straw Poll for Objections" thread. |
| 17:15 | <TabAtkins> | He linked http://www.ietf.org/rfc/rfc0020.txt |
| 17:17 | <TabAtkins> | Sigh. Okay, the fancy ascii table formatting is pretty, but really, what's the point of doing something where you have to split up the hexits when you can just do a simple two-column table? A split 2col table could be equally compact, or likely more compact actually. |
| 17:17 | <TabAtkins> | Silly people from 40 years ago. |
| 17:18 | <TabAtkins> | Or I guess 10 years ago, maybe? When it was put into the archives? |
| 17:19 | <othermaciej> | TabAtkins: was this on public-html? I don't see it... |
| 17:19 | <TabAtkins> | othermaciej: Yeah, it's the thread you started. |
| 17:20 | <jgraham> | othermaciej: http://www.w3.org/mid/20100728203158367745.c11b49f9⊙xn |
| 17:20 | <jgraham> | If the archive is working again |
| 17:20 | <TabAtkins> | What's the purpose of the /mid/ thing, when you can just dive into the individual directories for each list? |
| 17:23 | <othermaciej> | jgraham: hmm, oddly I don't see it in my public-html folder |
| 17:23 | <othermaciej> | checking if it might be somewhere else |
| 17:23 | <TabAtkins> | You been auto-spamming Leif's email? |
| 17:23 | <jgraham> | Maybe othermaciej has started snaking on email in the night |
| 17:23 | <jgraham> | *snacking |
| 17:23 | <othermaciej> | offhand, I am not sure what to do about it, unless someone seriously wants to propose it as an alternative instead of the ones already on the table |
| 17:24 | <TabAtkins> | Well, it's an official-looking and seemingly complete ASCII ref. |
| 17:24 | <TabAtkins> | And it was written by Vint Cerf! |
| 17:25 | <othermaciej> | hard to argue with that |
| 17:26 | <othermaciej> | is it in any way superior to the suggested ECMA-006? |
| 17:26 | <othermaciej> | my recollection from the poll is that the main objection to 006 is not defining the mapping to unicode, which flaw RFC20 seems to share |
| 17:26 | <TabAtkins> | More official-looking. Otherwise, no, because it lacks the unicode mapping. |
| 17:27 | <othermaciej> | I suspect it's actually less official |
| 17:28 | <TabAtkins> | Actual officialness is irrelevant. |
| 17:28 | <othermaciej> | ECMA-006 is the ECMA version of the joint publication with ISO that is the successor to ASCII |
| 17:28 | <othermaciej> | so it's an official joint publication, not just an ad-hoc copy |
| 17:28 | <othermaciej> | at least as I understand it |
| 17:28 | <annevk5> | yeah, it's just an RFC |
| 17:29 | <annevk5> | though really this is all quite nutty |
| 17:29 | <annevk5> | and quite the time sink |
| 17:29 | <TabAtkins> | Man, Cerf really liked his joke RFCs. |
| 17:29 | <othermaciej> | if we just let the poll continue then mainly it will consume the chairs' time and not much more of anyone else's |
| 17:30 | <annevk5> | the number of times this issue has been discussed here on IRC and on the list... |
| 17:30 | <annevk5> | anyway, back to super mario |
| 17:33 | <jgraham> | annevk5: Mario Galaxy 2? |
| 17:36 | <annevk5> | bros |
| 17:37 | <jgraham> | Ah |
| 17:37 | <TabAtkins> | kickin' it old school |
| 17:37 | jgraham | is wondering how desperate he should be for MG2 |
| 17:37 | <annevk5> | bros wii that is |
| 17:37 | <annevk5> | mg2 is quite cool |
| 17:37 | <annevk5> | but some frustrating levels made me give up for now |
| 17:38 | <gsnedders> | jgraham: Aww, want it for your birthday? |
| 17:38 | <jgraham> | Mario Galaxy + Yoshi sounds like it has to be awesome |
| 17:38 | <jgraham> | (although most things + Yoshi sound like that) |
| 18:26 | <hsivonen> | so now that IANA has a link registry, it can't be used yet, because more bureaucracy is needed to establish certain flags in the registry??? |
| 18:26 | <annevk5> | of course |
| 18:26 | <annevk5> | that's why we should have a wiki instead |
| 18:34 | <Workshiva> | Is the new registry properly registered? |
| 18:35 | <annevk5> | think so |
| 19:07 | <franksalim> | MIME sockets??? |
| 20:34 | <Workshiva> | I note that wikipedia deleted the article about DeathStation 9000 |
| 20:37 | <annevk5> | deletionists strike again? |
| 20:43 | <jgraham> | I want to write an article about deletionists and see how long it lasts |
| 20:44 | <annevk5> | I'm still not over what they did to the Pokeman pages |
| 20:44 | <annevk5> | of course I only started caring after I learned about what happened (though I had seen the original ones as well for unclear reasons) |
| 20:45 | <Workshiva> | Gotta protect those bytes, so people don't waste them |
| 20:50 | <hsivonen> | wikipedia deletionism is sad and annoying |
| 20:51 | <hsivonen> | particularly when you want to know what something is or what someone is supposed to be famous for and you see that there has been an article but is has been deleted as not notable enough |
| 20:52 | jgraham | wonders how articles about TV shows "are more likely to result in articles that are OR" |
| 20:53 | <jgraham> | How can watching a TV show and summarising the plot count as original research? |
| 20:53 | <jgraham> | The source... is the TV show |
| 20:53 | <Workshiva> | First party sources aren't good |
| 20:54 | <jgraham> | That's clearly insane |
| 20:55 | <jgraham> | If there is a track listing for a CD (common on wikipedia) I don't also expect there to be a link to an independent source listing the tracks on the CD |
| 20:55 | <AryehGregor> | It's completely insane, but there you have it. |
| 20:56 | <GPHemsley> | Is there a way to excluded a form element (e.g. <input type="submit">) from being submitted in a GET request? |
| 20:56 | <GPHemsley> | -d |
| 20:56 | <AryehGregor> | Primary sources that have been reliably published may be used in Wikipedia, but only with care, because it is easy to misuse them. Any interpretation of primary source material requires a reliable secondary source for that interpretation. A primary source may only be used on Wikipedia to make straightforward, descriptive statements that any educated person, with access to the source but without specialist knowledge, will be able to verify are |
| 20:56 | <AryehGregor> | supported by the source. For example, an article about a novel may cite passages to describe the plot, but any interpretation needs a secondary source. Do not make analytic, synthetic, interpretive, explanatory, or evaluative claims about material found in a primary source. Do not base articles entirely on primary sources. Do not add unsourced material from your personal experience, because that would make Wikipedia a primary source of that |
| 20:56 | <AryehGregor> | material. |
| 20:56 | <AryehGregor> | Blech, too long. |
| 20:57 | GPHemsley | tries to avoid the Wikipedia discussion |
| 20:57 | <AryehGregor> | GPHemsley, why do you want to not submit it? |
| 20:58 | <GPHemsley> | because, in essence, the form is intended to just add a sort variable to the URL, it doesn't need the submit variable too |
| 20:58 | <GPHemsley> | (whether that is a Bad Thing™, I don't know) |
| 21:01 | <AryehGregor> | You can't just ignore the submit variable? |
| 21:03 | <GPHemsley> | I want pretty URLs :) |
| 21:03 | <Workshiva> | GPHemsley: Don't give it a name? |
| 21:04 | <GPHemsley> | oh, that's easy :P |
| 21:04 | <GPHemsley> | thank you |
| 21:05 | <hsivonen> | GPHemsley: see the script on validator.nu |
| 21:05 | <GPHemsley> | hsivonen: oh, is that bad? |
| 21:06 | <hsivonen> | jgraham: OTOH, wikipedia seems to be fine with using XHTML2 WG's publication themselves as sources when writing about the XHTML2 WG's publications... |
| 21:06 | <AryehGregor> | hsivonen, it looks like you can directly repeat what primary sources say, you just can't summarize or interpret them. |
| 21:07 | <hsivonen> | GPHemsley: the script on validator.nu does tricks to make GET URLs shorter |
| 21:07 | <GPHemsley> | oh, well, I don't want JS tricks :) |
| 21:08 | <hsivonen> | AryehGregor: I mean even the propaganda parts of XHTML2 WG's publications |
| 21:08 | <GPHemsley> | hsivonen: Agh, why is the view-source of validator.nu afraid of line endings? ;_; |
| 21:09 | <AryehGregor> | Well, it's a secondary source on that, I guess. It shouldn't be taken as fact if it's disputed, it should be cited as the XHTMLWG's opinion. |
| 21:11 | <hsivonen> | GPHemsley: it's machine to machine communications :-) |
| 21:12 | <GPHemsley> | yeah, well, this machine doesn't like horizontal scrolling ;) |
| 21:57 | <jgraham> | This is a public service announcement (with guitars): chocolate from Trinidad is *so* nice |
| 21:57 | <jgraham> | At least the stuff I have right now is |
| 21:58 | <jgraham> | And I think the single origin Valrhona I particularly liked was from there too |
| 21:58 | <jgraham> | But I am not sure |
| 22:00 | <jgraham> | Also, it is really annoying how hard it is to do the simplest things without running into browser bugs |
| 22:01 | <jgraham> | It is doubly annoying when you were the one who should have found the bug |
| 22:01 | <jgraham> | One day someone will write a musical about the tragic life of a browser QA |
| 22:02 | <jgraham> | (I would have said opera, but that could have been mistaken for a pun) |
| 22:02 | <gsnedders> | jgraham: I find you notice minor issues far less when not a browser QA |
| 22:03 | <boblet> | jgraham: chocolate announcement requires independent verification, please forward to… |
| 22:03 | <boblet> | completely agree re: bugs too |
| 22:06 | <boblet> | regarding the a element, it says “Contexts in which this element may be used: Where phrasing content is expected”. As a can be flow content, shouldn’t that be where flow or phrasing content is expected? |
| 22:08 | <jgraham> | Oh |
| 22:09 | <jgraham> | I just discovered a site selling catering-sized bags of chocolate |
| 22:09 | <jgraham> | That is *such* a bad thing to know about |
| 22:09 | <gsnedders> | Will all end well? |
| 22:09 | <jgraham> | At 60GBP a bag, it would end in poverty at least |
| 22:10 | <jgraham> | (3kg) |
| 22:10 | <gsnedders> | You'll need a lot more rasberies to make up for that… |
| 22:10 | <jgraham> | Yeah |
| 22:10 | jgraham | closes that tab quickly |
| 22:11 | <boblet> | you need the equivalent of a pet food dispenser to limit consumption. it’d work then |
| 22:15 | <boblet> | guess I’ll file a bug, although I can’t believe no one has noticed it until now, which makes me wonder if I’m missing something re: flow/phrasing content :/ |
| 22:15 | <gsnedders> | Well, a lot of browser people only care about UA requirements |
| 22:55 | <jgraham> | Hmm, i think I just managed to DOS myself |
| 22:55 | <jgraham> | s/DOS/DoS/ |
| 22:56 | <jgraham> | I didn't mistakenly install a legacy operating system, after all |
| 22:57 | <boblet> | jgraham: that would have been far worse |
| 22:59 | <jgraham> | boblet: Well if this doesn't finish soon my laptop will be so hot it will set fire to my house |
| 22:59 | <jgraham> | and I will probably die in the flames |
| 22:59 | <jgraham> | So I'm not sure I agree with your assessment |
| 23:00 | <boblet> | jgraham: you can put some water on it to cool it down |
| 23:00 | jgraham | notes never to let boblet join the fire brigade |
| 23:01 | <boblet> | jgraham: good point, ice would be better huh |
| 23:01 | <annevk> | you guys missed http://www.w3.org/TR/2010/REC-xhtml-modularization-20100729/ ? |
| 23:02 | <jgraham> | annevk: I think "missed" is not quite right |
| 23:02 | <jgraham> | Maybe "filtered out as a pointless waste of bits" |
| 23:03 | <jgraham> | Although I did click on the link |
| 23:03 | <jgraham> | So it may open sometime in the distant future if the browser ever starts responding again |
| 23:03 | <annevk> | glad to waste your time ;p |
| 23:04 | <annevk> | maybe I'll get some sleep |
| 23:04 | <annevk> | got to clean up some stuff tomorrow morning and get to Maastricht in time for some hopefully constructive discussion |
| 23:05 | <boblet> | good to see they’re making progress on that whole XHTML thing |
| 23:08 | jgraham | wonders when Hixie is looking at WebSockets |
| 23:09 | <annevk> | if anyone wants to have me say anything on WebSockets at the Hybi meeting tomorrow just email and I'll try tor relay |
| 23:10 | <TabAtkins> | "stop complicating things, yor morons"? |
| 23:10 | <franksalim> | "sockets don't send messages" |
| 23:10 | <annevk> | heh, I'm gonna try to work out our different points of view; not sure if "morons" will be effective at that :) |
| 23:11 | <jgraham> | franksalim: Hmm? Websockets do at the moment |
| 23:11 | <TabAtkins> | "stop complicating things, you wonderful people"? |
| 23:11 | <franksalim> | ok, "sockets don't send MIME messages" |
| 23:11 | <annevk> | jgraham, I think what he means is that they don't need a media type and all |
| 23:11 | <annevk> | right |
| 23:11 | <jgraham> | Yeah |
| 23:11 | <franksalim> | some of the proposals are so far away from "TCP for the Web" it hurts |
| 23:12 | <Hixie> | jgraham: sup? |
| 23:12 | <annevk> | I think my main input is gonna be 1) settle on handshake 2) settle on framing 3) keep it very simple; and generally try to explain where we are coming from |
| 23:12 | <jgraham> | Hixie: sup?? |
| 23:13 | <jgraham> | (I have no idea what "sup?" means) |
| 23:13 | <TabAtkins> | "what's up" |
| 23:13 | <jgraham> | Is this some Google thing |
| 23:13 | <annevk> | no |
| 23:14 | <TabAtkins> | No, it's an american thing |
| 23:14 | <jgraham> | Are you all developing your own langauge |
| 23:14 | <annevk> | sup? is pretty normal |
| 23:14 | <annevk> | you should watch some more series or movies |
| 23:14 | <TabAtkins> | jgraham isn't down with the kid's slang these days |
| 23:14 | <Hixie> | jgraham: what do i need to look at? |
| 23:14 | <annevk> | lol |
| 23:14 | <annevk> | (at Hixie) |
| 23:15 | <jgraham> | Hixie: Well there has been a lot of discussion on the list |
| 23:15 | <jgraham> | Some more insane than others |
| 23:16 | <jgraham> | I think it would be nice to get some input from you, at least about the framing stuff, soon given the "4 week" timetable |
| 23:16 | <jgraham> | (much of the other stuff is irrelevant and can be ignored) |
| 23:16 | <Hixie> | k |
| 23:16 | <jgraham> | (at least in the short term) |
| 23:16 | <Hixie> | i looked earlier and didn't see anything new on the framing stuff |
| 23:16 | <Hixie> | but i'll look at the newer e-mails |
| 23:16 | <annevk> | the chunking stuff seems somewhat compelling |
| 23:17 | <Hixie> | chunking is pointless since the client can't do anything until it's received the whole message anyway, as far as i can tell |
| 23:17 | <annevk> | according to Yngve something like that might even get more efficient than varied length-encoding |
| 23:17 | <jgraham> | Basically at this point I think the IETF people will conclude that they have consensus around length-delimited frames |
| 23:17 | <jgraham> | s/delimited/marked/ |
| 23:17 | <annevk> | chunking is for the server to not have to know the length of a very large message |
| 23:17 | <franksalim> | i think lengh prefixing is superior to a terminator, myself |
| 23:18 | <Hixie> | length prefixing when the data is UTF-8 is just asking for subtle bugs |
| 23:18 | <franksalim> | annevk, why not send fixed sized messages at the socket layer and implement chunking in your protocol? |
| 23:18 | <Hixie> | that's a non-starter |
| 23:18 | <franksalim> | plenty of protocols over tcp have chunking |
| 23:18 | <Hixie> | annevk: for text you don't need to know the length at all |
| 23:18 | <franksalim> | Hixie, i think the terminator approach asks for different, complimentary bugs |
| 23:19 | <annevk> | franksalim, yeah, I suppose you can implement chunking yourself |
| 23:19 | <Hixie> | franksalim: like what? |
| 23:19 | <franksalim> | for instance if server code allows non string data to be sent as strings accidentally |
| 23:19 | <franksalim> | i have already seen websocket libraries that make that mistake |
| 23:19 | <franksalim> | written by professionals no less |
| 23:19 | <annevk> | Hixie, yeah, this is for non-text; though some people seem to dislike the sentinel stuff too, but I'm not too convinced myself |
| 23:19 | <franksalim> | that accept byte slices and send as UTF-8 |
| 23:19 | <Hixie> | franksalim: well if people are sending non-UTF-8 content, it doesn't much matter if they're sending lengths or terminators, the data is bogus anyway |
| 23:20 | <Hixie> | annevk: for non-text, we can do chunking, sure. That's a non-issue now since you can't send non-text. |
| 23:20 | <jgraham> | One argument for length markers was that it helps pre-allocating buffers |
| 23:20 | <franksalim> | why would we do chunking for one type and not another? |
| 23:21 | <Hixie> | so that people who don't need it don't have to do it |
| 23:21 | <franksalim> | also, i agree with folks on the list that it is best to spec binary now even though javascript will not be able to send/recv it |
| 23:21 | <jgraham> | Which seems to be good for avoiding typical buffer overflow bugs |
| 23:21 | <Hixie> | why? |
| 23:21 | <Hixie> | (^to franksalim) |
| 23:21 | <franksalim> | Hixie, i don't see why the api and the protocol need to be exactly in lock step |
| 23:21 | <jgraham> | Yay! Firefox unfroze! |
| 23:21 | <annevk> | binary is more or less defined already |
| 23:21 | <franksalim> | Hixie, i think we can _finish_ the protocol before TypedArray |
| 23:22 | <annevk> | it's %80 iirc |
| 23:22 | <annevk> | it's just invalid for now and not exposed |
| 23:22 | <Hixie> | franksalim: without knowing what the API is we can't design the protocol |
| 23:22 | <franksalim> | annevk, with the provision that type bytes will be defined later, right? |
| 23:22 | <franksalim> | Hixie, i don't think that is true |
| 23:22 | <Hixie> | jgraham: i don't see how you could possibly have a buffer overflow if you're not relying on someone telling you the length of the data |
| 23:22 | <annevk> | type bytes? |
| 23:22 | <jgraham> | It ran for 1763 seconds and then popped up the slow script dialog... |
| 23:22 | <annevk> | you mean like media streams? |
| 23:22 | <franksalim> | Hixie, i have put different APIs over the same protocol. I have also put the same API over different protocols |
| 23:23 | <Hixie> | jgraham: in fact, you're far more likely to have a buffer overflow with a length byte, since it's more likely that you'll allocate a buffer and then mistakenly inspect the data to read it in |
| 23:23 | <Hixie> | franksalim: i can't design a protocol without knowing the api. |
| 23:24 | <Hixie> | you can always jam things together and make them work, but that's not a good situation to be in. |
| 23:24 | <franksalim> | Hixie, what can i say to that? |
| 23:24 | <annevk> | while I'm gonna read and sleep some, keep this up; it's nice input :) |
| 23:24 | <franksalim> | Hixie, I can? |
| 23:24 | <jgraham> | Hixie: Anyway, it would be good if you have this discussion on the list |
| 23:24 | <Hixie> | we've had this discussion on the list |
| 23:24 | <Hixie> | multiple times over the last year or two |
| 23:24 | <jgraham> | Personally I am happy with either type of framing for text |
| 23:25 | <Hixie> | i don't see any point repeating what i've already said |
| 23:25 | <jgraham> | Hixie: I am pretty much 100% convinced that people will not be happy with that |
| 23:26 | <Hixie> | i'm not trying to make people happy, i'm trying to design a protocol |
| 23:26 | <jgraham> | Hixie: I don't think they see it like that either |
| 23:26 | <Hixie> | that's their problem :-) |
| 23:26 | <jgraham> | I think they think that the group is trying to design a protocol |
| 23:28 | <franksalim> | this can of worms would have been avoided completely by having the protocol be byte streams (like tcp) instead of discrete messages |
| 23:28 | <franksalim> | with byte streams it is clear you can do whatever you want and it is up to the next protocol up the stack to define structure, types, chunking, muxing |
| 23:29 | <Hixie> | byte streams would have to be exposed to JS, and I'm not at all convinced that your typical web dev can write code to handle byte streams well |
| 23:30 | <franksalim> | a typical web dev can't use opengl, either |
| 23:30 | <boblet> | are there any UTF-8 characters apart from & and > that need escaping in HTML5? |
| 23:30 | <jgraham> | Yeah, I think byte streams would be bad |
| 23:30 | <franksalim> | messaging protocols sitting on top of byte streams are equivalent to scene graphs on webgl |
| 23:30 | <TabAtkins> | boblet - you mean <, right? |
| 23:31 | <Hixie> | franksalim: i wasn't especially convinced that we should expose webgl either |
| 23:31 | <boblet> | TabAtkins: doh, yep |
| 23:31 | <TabAtkins> | Then in most circumstances, yes. In some circumstances you'll want to escape ',", and >. |
| 23:32 | <franksalim> | Hixie, if one messaging protocol 'wins,' we can bake it in |
| 23:32 | <boblet> | TabAtkins: aah good point. you mean eg in alt text yeah? |
| 23:33 | <TabAtkins> | Yeah. |
| 23:33 | <franksalim> | starting with a stripped down or half baked messaging protocol is the worst idea, imho |
| 23:33 | <TabAtkins> | If you're escaping attributes, escape ' and ". If you're escaping unquoted attributes, also escape > (as it can early-close the element in some circumstances). |
| 23:34 | <jgraham> | Anyway, bedtime |
| 23:34 | <jgraham> | Goodnight |
| 23:34 | <boblet> | jgraham: happy chocolate dreams |
| 23:34 | <jgraham> | :) |
| 23:35 | <franksalim> | Hixie, I should say that I am much happier with the frames we currently have than anything heavier weight that has been proposed |
| 23:36 | <franksalim> | because lightweight frames allow me to ignore framing and run a real protocol over a stream |
| 23:43 | <franksalim> | if your application messages and your wire messages are one and the same, then all the problems like chunking and addressing that have been raised are valid. if you treat websocket like tcp, you handle those concerns in your protocol of choice |
| 23:43 | <AryehGregor> | Why do all of these tests fail on Chrome? It's puzzling me. I don't seem to be able to easily make a reduced test case. http://aryeh.name/tmp/html5tests.html |
| 23:43 | <AryehGregor> | (not all, 20%, but whatever) |
| 23:43 | <AryehGregor> | (I'm idly writing some tests for basic easy-to-test-from-JS stuff, dunno if anyone has written any such so far) |