| 06:31 | <Hixie> | abarth: yt? |
| 06:33 | <Hixie> | abarth: i have a string of bytes of variable length which i'm sending in a UDP packet. i can limit the total allowed length of the input to an arbitrary limit, e.g. 30K, 60K, whatever fits in an IPv6 UDP packet (65487 bytes as far as I can tell would therefore be the max). I want to make sure it is masked so it can't ever be used to reliably attack a service. |
| 06:34 | <Hixie> | is there a good way to do that? the most obvious way seems to be to limit it to 30K and make each packet contain first a one-time pad of equal length (and completely random) followed by the data xor'ed with that pad |
| 06:34 | <Hixie> | but is there some crypto magic that would be better? |
| 06:58 | <abarth> | Hixie: hey |
| 06:59 | <abarth> | Hixie: |
| 06:59 | <abarth> | Hixie: yay |
| 06:59 | <abarth> | s/yay/yeah/ |
| 06:59 | <abarth> | just use AES-128-CTR |
| 06:59 | <Hixie> | cool |
| 06:59 | <abarth> | send a nonce |
| 06:59 | <abarth> | then HMAC a unique id with the nonce to get the key |
| 06:59 | <abarth> | and use AES-128-CTR |
| 07:00 | <abarth> | the CTR is the important part |
| 07:00 | <Hixie> | k |
| 07:00 | <Hixie> | wait CTR won't work if the receiver doesn't receive everything right? |
| 07:01 | <Hixie> | this is UDP so the delivery is unreliable |
| 07:01 | <abarth> | CTR is a stream cipher |
| 07:01 | <abarth> | you want to re-key with each packet |
| 07:01 | <Hixie> | ah ok |
| 07:01 | <abarth> | you can decrypt each byte as it arives |
| 07:01 | <Hixie> | right |
| 07:01 | <Hixie> | cool, thanks |
| 07:02 | <Hixie> | and the unique id is unique to the spec? or to the UA? or to the packet? |
| 07:02 | <Hixie> | spec presumably |
| 07:02 | <abarth> | the spec |
| 07:02 | <Hixie> | how big should the nonce and unique id be? |
| 07:02 | <Hixie> | 16 bytes? |
| 07:03 | <abarth> | yeah, that should be plenty |
| 07:03 | <abarth> | for the unique id, you can just use uuidgen |
| 07:03 | <Hixie> | i figured i'd pipe /dev/urandom to head then to hexdump :-) |
| 07:04 | <abarth> | that works too :) |
| 07:04 | <Hixie> | to get 16 random bytes i can copy-paste into the spec :-) |
| 07:05 | <Hixie> | does websocket -06 have prose for this that's spec-ready by any chance? |
| 07:05 | <abarth> | http://tools.ietf.org/html/draft-abarth-websocket-handshake-01 probably does |
| 07:06 | <abarth> | looking |
| 07:06 | <abarth> | http://tools.ietf.org/html/draft-abarth-websocket-handshake-00 |
| 07:06 | <abarth> | 27 |
| 07:06 | <abarth> | step 27 on page 9 |
| 07:07 | <Hixie> | awesome |
| 07:07 | <Hixie> | thanks |
| 07:07 | <abarth> | there's a NIST document you can reference for AES-128-CTR |
| 07:08 | <Hixie> | references i'm good with :-) |
| 07:08 | <hsivonen> | http://blog.lostdecadegames.com/an-html5-game-in-the-mac-app-store Somehow I'm annoyed at how the article claims that Chrome and WebKit on Mac are "completely different platform[s]" |
| 07:23 | <annevk> | w3.org Bugzilla slow for anyone else? |
| 08:11 | <annevk> | subjects so far: extend paragraphs/inline lists; datalist stuff; WebApps publications; cross-origin databases |
| 08:12 | <annevk> | maybe I should write about the license debate hmm |
| 08:28 | <Hixie> | annevk: what exception should i fire for when too much data has been passed to a method? (specifically, too much data to fit in a UDP packet) |
| 08:29 | <Hixie> | INVALID_ACCESS_ERR? |
| 08:30 | <annevk> | INDEX_SIZE_ERR ? |
| 08:30 | <annevk> | hmm I guess that's not quite correct |
| 08:30 | <Hixie> | yeah i made the same mistake |
| 08:30 | <Hixie> | i guess SIZE_ERR is misleading |
| 08:31 | <hsivonen> | hmm. the spec is silent on how to render runs of multiple spaces in the values of a title attribute |
| 08:31 | <hsivonen> | or tabs |
| 08:31 | <hsivonen> | or carriage returns |
| 08:31 | <Hixie> | we mention line feeds though right? |
| 08:31 | <hsivonen> | Hixie: yes |
| 08:31 | <Hixie> | k good |
| 08:31 | <Hixie> | if you want more specifics, please file a bug or send mail, happy to add more |
| 08:32 | <annevk> | INVALID_ACCESS_ERR sounds good |
| 08:32 | <Hixie> | CRs should be treated the same as NULLs |
| 08:32 | <annevk> | I can also add a new one |
| 08:32 | <Hixie> | (or any control character) |
| 08:32 | <hsivonen> | Hixie: OK. I guess I need to test what other browsers do first, so I know what to ask for! |
| 08:32 | <Hixie> | annevk: wasn't sure what to call it that would be generic enough to make it useful yet less generic than INVALID_ACCESS_ERR |
| 08:32 | <Hixie> | hsivonen: :-) |
| 08:33 | <annevk> | QUOTA_EXCEEDED_ERR is quite close too, but it's named in a specific way |
| 08:33 | <annevk> | actually no, that's quite different |
| 08:33 | <annevk> | meh |
| 08:33 | annevk | goes back to writing WHATWG Weekly |
| 08:34 | zcorpan | disables [FLASH] feature in the forums |
| 08:35 | <zcorpan> | a bit scary that phpbb3 allows remote flash embedding in user posts by default |
| 08:35 | <hsivonen> | zcorpan: it indeed is |
| 08:36 | <hsivonen> | not only a bit scary |
| 08:36 | <Hixie> | luckily the forums are isolated on their own origin |
| 08:37 | <hsivonen> | Grr. Why doesn't the Gnome Character Map include ASCII? |
| 08:38 | <zcorpan> | Hixie: maybe somebody pulls off an attack against the other origins on the same virtual machine with Flash sockets |
| 08:39 | <Hixie> | zcorpan: well we're not going to be any safer if we disable flash if that's the attack scenario |
| 08:40 | <zcorpan> | maybe not :) |
| 08:47 | <hsivonen> | hmm. this is interesting: IE9 seems to handle literal tab and escaped tab differently in the title attribute |
| 08:48 | <hsivonen> | no I fail |
| 08:48 | <hsivonen> | editor set to expand tabs to spaces |
| 08:59 | <jgraham> | hsivonen: Gnome Character Map does include ASCII |
| 09:00 | <jgraham> | It's called "Basic Latin" |
| 09:00 | jgraham | thought that annevk was away |
| 09:01 | <hsivonen> | jgraham: oh right. I got fooled by having Latin 1 selected and being unable to scroll up |
| 09:02 | <hsivonen> | it also confuses me greatly that the Unicode Blocks are sorted by name alphabetically instead of being sorted by code point order |
| 09:02 | <jgraham> | Yeah, having a by-codepoint view might be nice |
| 09:03 | <jgraham> | Hixie: Is it intentional that one can now nest <input> inside <button>? |
| 09:03 | <hsivonen> | and it irks me that there's no in-windows search field, so I have to use ctrl-f |
| 09:03 | <Hixie> | one can? |
| 09:03 | <Hixie> | how can one? |
| 09:03 | <hsivonen> | jgraham: intentional as in conformance or as in parser? |
| 09:03 | <jgraham> | Hixie: <button><input></button> |
| 09:03 | <jgraham> | hsivonen: In the parser |
| 09:03 | <Hixie> | oh in the parser |
| 09:03 | <Hixie> | no idea |
| 09:04 | <Hixie> | what changed it? |
| 09:04 | <Hixie> | what do browsers do? |
| 09:04 | <jgraham> | We specced the parser |
| 09:04 | <jgraham> | Before we specced the parser it didn't work |
| 09:04 | <jgraham> | :) |
| 09:04 | <Hixie> | if all browsers do otherwise and the parser spec has always allowed it then it was an oversight due to incomplete testing |
| 09:04 | <hsivonen> | I expect to become very tired of switching between IE9 and IE8 VM snapshots... |
| 09:04 | <jgraham> | I think HTML5 browsers allow it and pre-HTML5 browsers don't |
| 09:05 | <jgraham> | I haven't tried IE |
| 09:05 | <jgraham> | (I suppose s/HTML5/parser spec/ |
| 09:05 | <jgraham> | ) |
| 09:05 | <zcorpan> | jgraham: in ie the input is put inside the button but it doesn't render |
| 09:06 | <hsivonen> | jgraham: IE8 allows them nest |
| 09:06 | <hsivonen> | jgraham: so interop FTW! |
| 09:07 | <zcorpan> | hsivonen: does it render in ie8? |
| 09:07 | <hsivonen> | zcorpan: AFAICT, the input isn't rendered |
| 09:08 | <jgraham> | Well I am not adverse to just leaving things as-is; it just means that I need to change some tests that assume the old behaviour |
| 09:08 | <annevk> | jgraham, leaving 4AM tomorrow, flying to Madrid from Germany at around 8AM |
| 09:08 | <hsivonen> | I'm greatly annoyed by Microsoft not allowing XP Mode to be run on the VM of my choice outside Windows 7 |
| 09:08 | <annevk> | jgraham, arriving in Bogotá at around 5PM local time if all goes well... |
| 09:08 | <jgraham> | Having a visible, but unclickable input is weird but so are lots of things |
| 09:09 | <hsivonen> | Virtual PC doesn't work when Windows 7 itself is itself running in a VM |
| 09:09 | <jgraham> | annevk: I see |
| 09:09 | <hsivonen> | anyway, I don't have IE6 or IE7 to test with on this computer |
| 09:11 | <hsivonen> | jgraham: Clearly, the parsing algorithm is correct. Maybe we should consider doing |
| 09:11 | <hsivonen> | button input { display: none; } |
| 09:11 | <jgraham> | Yes |
| 09:12 | <hsivonen> | in other news, it seems the Gnome folks don't actively test their site in IE8 |
| 09:12 | <annevk> | http://blog.whatwg.org/weekly-layout-table |
| 09:12 | <hsivonen> | got a bug report about API doc layout changing on gnome.org due to the HTML5 parser |
| 09:12 | <hsivonen> | when AFAICT, we became more like IE |
| 09:13 | <hsivonen> | the <br></br> thing |
| 09:13 | <jgraham> | It seems quite plausible that very few gnome developers *have* IE… |
| 09:14 | <hsivonen> | sadly, enhanced interop may be thought of as a bug in the context of Linux or Mac-oriented sites |
| 09:14 | <hsivonen> | well, fortunately, it's not the end of the world if API listings have some extra blank lines |
| 09:14 | <hsivonen> | also, XHTML as text/html for the lose |
| 09:17 | <jgraham> | hsivonen: It would be astonishingly shortsighted for the people who benefit from greater interop in general (those running on minority platforms) to view interop as a negative thing |
| 09:19 | <zcorpan> | Hixie: a better attack scenario would be attacking the admin panel |
| 09:19 | <Hixie> | sure |
| 09:19 | <Hixie> | allowing embedded flash is equivalent to allowing embedded <script> |
| 09:20 | <Hixie> | i was just saying the damage would be isolated to the forums |
| 09:20 | <zcorpan> | yeah |
| 09:20 | <hsivonen> | I think the background image breakage on http://www.buzzmachine.com/ shows a huge win for interop |
| 09:21 | <hsivonen> | the page "worked" in pre-HTML5 non-IE browsers but the HTML5 parser-enabled builds of non-IE browsers break the page exactly like IE |
| 09:22 | <davve__> | he |
| 09:23 | <zcorpan> | hsivonen: what's the cause of the background breakage on that page? |
| 09:23 | <hsivonen> | zcorpan: <ul><div><li>foo</li></div></ul>, I've been told |
| 09:24 | <zcorpan> | did pre-HTML5 non-IE pop the div? |
| 09:25 | <hsivonen> | or maybe the key is <ul><div></div><li></ul> |
| 09:25 | <Hixie> | jesus some of these RFCs have stupidly long names |
| 09:26 | <hsivonen> | zcorpan: I don't recall, but anyway, the divs become a bit different and the div that has the background ends up having the content overflow instead of having another div in it that'd stretch the bg div |
| 09:26 | zcorpan | sees a <center> in <ul> |
| 09:26 | <hsivonen> | zcorpan: anyway, I think we shouldn't change the spec or implementations |
| 09:26 | <hsivonen> | zcorpan: I think we should declare victory |
| 09:26 | <zcorpan> | yep, was just curious :) |
| 09:28 | <hsivonen> | oh, great. Firefox, Chrome and IE can't agree on the tab size in tooltips |
| 09:32 | <hsivonen> | I wonder why IE9 RC pops up a balloon to call my attention to the compat view button when loading http://hsivonen.iki.fi/test/moz/title-attribute.html |
| 09:32 | <hsivonen> | or maybe it pops the balloon when the user repeatedly reloads the page |
| 09:33 | <Hixie> | my quest to write the spec with the most references ever continues unabated |
| 09:34 | <zcorpan> | hsivonen: i think it's the latter. at least i remember ie8 doing that when reloading some random page |
| 09:36 | <hsivonen> | zcorpan: yeah. looks like it's the reload |
| 09:40 | <annevk> | Hixie, is there some WIP to view? |
| 09:42 | <Hixie> | yeah, reload |
| 09:42 | <Hixie> | search for PeerConnection |
| 09:42 | <Hixie> | that whole section is new |
| 09:42 | <Hixie> | i'm fixing markup errors |
| 09:42 | <Hixie> | so don't worry if the whole page is blue or whatever |
| 09:44 | <annevk> | :) |
| 09:50 | <annevk> | Hixie, instead of sendText shouldn't this follow XHR / postMessage() more? |
| 09:50 | <Hixie> | good idea |
| 10:02 | <Hixie> | annevk: i changed sendText to postMessage, i hope that's what you meant! |
| 10:05 | <annevk> | either postMessage or just send() |
| 10:05 | <annevk> | something that can be overloaded later |
| 10:05 | <annevk> | with ArrayBuffer and other things we want to tranmist |
| 10:05 | <jgraham> | Without looking, son't we want to reuse the terminology from websockets? |
| 10:05 | <jgraham> | *don't |
| 10:06 | <Hixie> | which terminology? |
| 10:06 | <annevk> | yeah, I sort of expected Hixie to pick send() |
| 10:06 | <Hixie> | send() is fine too |
| 10:06 | <jgraham> | The function names |
| 10:06 | <Hixie> | sure |
| 10:07 | <Hixie> | so i have idl checking in my pipeline |
| 10:08 | <Hixie> | unfortunately the error messages refer to the number of the idl block |
| 10:08 | <Hixie> | i've no idea which idl block is numbered what |
| 10:08 | <Hixie> | apparently idl block 115 or so has a new error |
| 10:08 | <Hixie> | something about DOMString vs ( |
| 10:08 | <Hixie> | so if anyone sees the mistake later, let me knot |
| 10:08 | <Hixie> | know |
| 10:13 | <annevk> | so this also nukes device |
| 10:13 | <annevk> | wonder what Andrei will say to that |
| 10:14 | <Hixie> | which andrei? |
| 10:14 | <Hixie> | andrei p? |
| 10:14 | <annevk> | yeah |
| 10:14 | <Hixie> | i think he'll be fine with it |
| 10:14 | <Hixie> | there was a lot of confusion amongst webkit guys about what exactly <device> should do |
| 10:15 | <annevk> | hmm yeah, reading the message again he seems less displeased with that suggestion than I remembered |
| 10:15 | <annevk> | the main question is UI |
| 10:17 | <Hixie> | ok this is committed |
| 10:17 | <jgraham> | Hixie: On an entirely different topic, DOMTokenList specifies that you get null for .index(n) with n>=.length But WebIDL specifies that, at least for index properties you throw TypeError for out of range |
| 10:17 | <jgraham> | Is it intentional that there is a difference? |
| 10:17 | <Hixie> | i doubt it |
| 10:17 | <jgraham> | Is it even allowed by WebIDL? |
| 10:17 | <Hixie> | dunno |
| 10:17 | <Hixie> | file a bug or send mail :-) |
| 10:17 | <Hixie> | i'm hours late for bed |
| 10:18 | jgraham | can't see anything that would prevent it right now, but… |
| 10:18 | <Hixie> | wanted to get this peer-to-peer thing done |
| 10:18 | <Hixie> | nn :-) |
| 10:18 | <jgraham> | Hixie: Fair enough :) |
| 10:18 | <jgraham> | Sleep wel |
| 10:18 | <jgraham> | l |
| 10:18 | <Hixie> | ta :-) |
| 10:45 | <jgraham> | So what obvious thing am a I missing? Where is it specified that \n -> \r\n for form submission? |
| 10:50 | <jgraham> | Ah, only for type=hidden |
| 10:50 | <jgraham> | Perhaps |
| 10:51 | <jgraham> | No, <textarea? also |
| 10:51 | <jgraham> | s/?/>/ |
| 11:04 | <richt> | FYI http://my.opera.com/core/blog/2011/03/14/web-meet-device |
| 11:04 | <richt> | I'll caveat that with the fact we will update the APIs with Hixie's latest changes from here on out :) |
| 11:21 | <hsivonen> | is this a fork? http://libav.org/ |
| 11:23 | <annevk> | the event should probably be named message rather than text |
| 11:23 | <annevk> | like WebSockets |
| 11:23 | <annevk> | oh well, details |
| 11:24 | <annevk> | hsivonen, "We, as a group of FFmpeg developers, have decided to continue developing FFmpeg under the name Libav. All existing infrastructure will be transferred to the libav.org domain." |
| 11:24 | <hsivonen> | annevk: but why? and why doesn't the same message appear on ffmpeg.org? |
| 11:27 | <annevk> | no idea |
| 11:31 | <hsivonen> | I can guess three possible explanations: 1) fork 2) MPEG complaining about name 3) rebranding is more general than just MPEG |
| 11:43 | <Philip`> | hsivonen: Sounds like a reaction to http://lwn.net/Articles/423702/ |
| 11:43 | <Philip`> | http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-March/109202.html |
| 11:46 | <Philip`> | http://avcodec.org/pipermail/ffmpeg-private/2011-March/thread.html also somewhat relevant |
| 11:51 | <Philip`> | (Sounds kind of like there was a fork due to the normal reasons (personality clashes and disagreements over development practices), but the forkers took control of the FFmpeg name, which the other people didn't like, so the other people started their own fork called libav, or something like that) |
| 11:55 | <hsivonen> | Philip`: thanks. too much email for me to have a clear understanding of what happened and why |
| 11:56 | <hsivonen> | I wonder if someone is chronicling open source fork history with reasonably unbiased recounts of what happened in each case |
| 12:02 | <Philip`> | Unbiased accounts might not help understanding the reason much, since the reason usually seems to be people's differing biases |
| 12:03 | <Philip`> | The most useful thing you can get is a full collection of everyone's biases, since then the reader can recognise the conflict |
| 12:03 | <jgraham> | Philip`: Presumably one can objectively document a bias without having to share it |
| 12:04 | <jgraham> | Insofar as one can objectively document anything |
| 12:25 | <Lachy> | Hixie, in the new getUserMedia() method, the description says options is comma separated, but the algorithm says to split on spaces. |
| 12:31 | <hsivonen> | Speaking of forks, who is using XFree86 still? |
| 12:39 | <smaug____> | has <device> been removed from HTML spec? |
| 12:39 | <smaug____> | it is mentioned in Abstract, but I can't seem to find it elsewhere |
| 12:41 | <jgraham> | smaug____: Yes |
| 12:42 | <smaug____> | jgraham: I was just wondering the example http://my.opera.com/core/blog/2011/03/14/web-meet-device (I think the example shows that the API is rather strange) |
| 12:43 | <jgraham> | smaug____: <device> was removed this morning |
| 12:43 | <smaug____> | aha, good |
| 12:43 | <smaug____> | I wonder what the reasoning was |
| 12:48 | <smaug____> | annevk: are you on vacation already? |
| 12:50 | <erlehmann> | oh noes |
| 13:07 | <Lachy> | smaug____, there are a few reasons why an API is better than the device element |
| 13:08 | <smaug____> | sure. I never liked <device>, though I didn't have time to review it properly |
| 13:08 | <foolip> | Hixie, are you aware that the video conferencing section ended up in http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication ? |
| 13:09 | <foolip> | seems rather unrelated to drag and drop :) |
| 13:10 | <zcorpan> | Philip`: ^ |
| 13:11 | <Lachy> | smaug____, firstly, the device element would require a native control to be inserted into the page so that the user can initiate access. Native controls suck for designers, since hey |
| 13:11 | <Lachy> | since they're difficult to style |
| 13:11 | <smaug____> | Lachy: very true. Similar reasons why I don't like Google's proposals for HTML Speech |
| 13:12 | <Lachy> | The API lets the author use whatever controls they like, and activiate it with a script, and then the browser can provide suitable UI in the chrome to request access, just like with geolocation |
| 13:13 | <smaug____> | right |
| 13:13 | <smaug____> | I wonder why the API is in HTML spec |
| 13:13 | <smaug____> | sounds a lot like something which could be handled in some separate spec |
| 13:13 | <Lachy> | because <device> was in the HTML spec, and no-one has yet offered to take over and write it as a separate spec |
| 13:14 | <hsivonen> | smaug____: probably because it's easier to add a section to an existing document than to start a new one |
| 13:14 | <jgraham> | smaug____: (that type of comment is more or less pure stop energy without actually doing the seperation) |
| 13:14 | <Philip`> | Hmph, Hixie keeps adding markup to the spec |
| 13:14 | <jgraham> | smaug____: (not suggesting that's what you intended at all) |
| 13:15 | <Philip`> | foolip: If you remind me later today or thereabouts, I can probably update the splitter |
| 13:15 | <Philip`> | (else I'll probably forget) |
| 13:16 | <smaug____> | jgraham: how so? I would guess there are pretty good tools to separate parts of HTML spec to separate documents automatically. Isn't that what happened to Websockets API for example |
| 13:17 | <hsivonen> | smaug____: there are tools, because people have complained in the past, but still the organization across specs isn't a substantive problem |
| 13:17 | <jgraham> | smaug____: Because it is not providing any useful feedback on the spec but requiring other people to expend effort to make, in the best case, meaningless changes |
| 13:18 | <jgraham> | when that effort could be better spent on actually improving the spec |
| 13:19 | smaug____ | doesn't understand how trying to make things easier to read is meaningless |
| 13:19 | <smaug____> | but anyway, not important enough to complain now... |
| 13:19 | <jgraham> | Is it really easier? Especially if it is conveniently split into its own page in the multipage version |
| 13:20 | <jgraham> | I find it harder because I have to hunt out the particular document that the thing I'm interested in is living in |
| 13:20 | <jgraham> | rather than just searching the TOC |
| 13:20 | <foolip> | Philip`, how much later should I remind you? |
| 13:21 | <smaug____> | it is true that readability of the spec could perhaps be improved also in some other ways |
| 13:21 | <jgraham> | (in the worst case, it is used as a tactic by people who don't like a spec to try and bury it; c.f. microdata) |
| 13:23 | <smaug____> | But anyhow, I'm concerned about the readability of the spec. It needs to reviewed more often and more thoroughly |
| 13:23 | <hsivonen> | smaug____: I like to be able to use in-browser search over a larger body of text |
| 13:24 | <Lachy> | smaug____, splitting specs sucks so much, and that's why I always look at complete.html because it has everything in it |
| 13:24 | <hsivonen> | smaug____: it annoys me greatly that the single-page version of SVG 1.1 latest ed. is hidden and that the latest EDs of CSS are sprinkled across documents |
| 13:25 | <hsivonen> | smaug____: also, a part of the pushback you are seeing is probably due to connotations from microdata etc. at the HTML WG |
| 13:25 | <Philip`> | foolip: Perhaps in between maybe 5 and 10 hours |
| 13:28 | <Lachy> | Is Interface GeneratedStream supposed to inherit from Stream? The IDL doesn't show that, but the prose indicates that might be the case |
| 13:29 | <zcorpan> | Lachy: my thought too |
| 13:29 | <zcorpan> | Lachy: second thought was that if that is the case, it'd be nicer to have all constants on Stream |
| 13:29 | <Lachy> | zcorpan, yeah, was just thinking that too |
| 13:34 | <zcorpan> | getRecordedData should probably have void return value |
| 13:40 | <Lachy> | why was the readystatechange event added to this, since there is also separate events for play, paused and ended? |
| 14:28 | <annevk> | smaug____, still here |
| 14:28 | <annevk> | somewhat |
| 14:28 | <zcorpan> | why is it ontext rather than onmessage? |
| 14:28 | <smaug____> | I wonder what I was going to ask... |
| 14:30 | <annevk> | zcorpan, it was sendText() or some such before as well |
| 14:30 | <annevk> | zcorpan, I hope Hixie just forgot to fix it |
| 14:31 | <annevk> | well, that's what I expect |
| 14:31 | <zcorpan> | ok |
| 14:31 | <hsivonen> | hmm. Microsoft PR links to a review at Softpedia |
| 14:39 | <zcorpan> | "as i recently realised, there is not (to my knowledge) a single MUST requirement on browsers to implement the features of HTML5 in an accessible, interoperable way." http://blog.whatwg.org/weekly-layout-table |
| 14:42 | <hsivonen> | zcorpan: curiously, the HTML5 spec requires data mining tools to treat elements according to their semantics, but there's no requirement (that I could find) for accessibility API exposure to do the same |
| 14:43 | jgraham | is just getting the blog timing out |
| 14:43 | <zcorpan> | thus, it's proof that Hixie cares more about data mining tools than about accessibility |
| 14:43 | <hsivonen> | I wonder if it's too controversial to highlight quirky and almost standards doctypes as errors in View Source |
| 14:43 | <jgraham> | Quirky should be |
| 14:44 | <hsivonen> | jgraham: highligthed or controversial? :-) |
| 14:44 | <jgraham> | heh |
| 14:44 | <jgraham> | Highlighted |
| 14:44 | <hsivonen> | it would seem inconsistent not to highlight Almost Standards, too, in that case |
| 14:45 | <jgraham> | Yeah, I would highlight both |
| 14:45 | <hsivonen> | at present, I'm not highlighting tree builder errors detected on EOF, because I don't know what I'd highlight |
| 14:46 | <hsivonen> | since there's no visible EOF character to highlight |
| 14:46 | <annevk> | hmm |
| 14:46 | <annevk> | even http://dreamhoststatus.com/ is down?! |
| 14:46 | <zewt> | dreamhoststatusstatus.com |
| 14:47 | <hsivonen> | zewt: I had to check if that one really existed |
| 14:47 | <zewt> | dreamhoststatus^N.com |
| 14:48 | <annevk> | "Update 7:11 am: We are currently operating on half of a core, so partial connectivity has been restored. We are working to resolve an issue with one of the cisco core supervisors not maintaining it’s configuration. Systems that are affected by this are our servers located at our downtown Los Angels, CA location (including the panel)– servers at our LAX data center are not affected by this outage." |
| 14:48 | <hsivonen> | whoa. looks like Hixie has allowed mozillaquestquest.com expire |
| 14:49 | <hsivonen> | (cue concern trolling about Hixie-owned domain names) |
| 15:02 | <Lachy> | Apparently Dreamhost is having network issues. Even Dreamhost Status is offline and I can't get my email :-( |
| 15:04 | <hsivonen> | I have a hard time understanding Microsoft's update categories. Are all "important" updates eligible for autoinstall? |
| 15:04 | <hsivonen> | If yes, why do I see unchecked-by-default "Important" updates in Windows Update? |
| 15:27 | <annevk> | dammit dreamhost |
| 15:29 | <zewt> | heh dreamhost is pretty much down at the bottom of the bargain bin of hosting |
| 15:31 | <jgraham> | hsivonen: What would it mean for an accessibility API to treat an element according to its semantics? |
| 15:32 | <hsivonen> | jgraham: that a <button> element is exposed as a button--not, for example, as a scrollbar |
| 15:32 | <jgraham> | hsivonen: Isn't that defined on a per element basis? |
| 15:33 | <jgraham> | using aria as an intermediate layer or something? |
| 15:34 | <hsivonen> | jgraham: only for stuff that's representable as ARIA, right? And is there a req to support ARIA? |
| 15:34 | <hsivonen> | jgraham: it's quite possible that the req is there but I just didn't find it |
| 15:34 | <jgraham> | http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotations-for-assistive-technology-products-(aria) |
| 15:34 | <jgraham> | "User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications" |
| 15:35 | <hsivonen> | jgraham: oh. OK. |
| 16:57 | <Hixie> | richt: d'oh, that was some poor timing we did there :-) |
| 17:57 | <AryehGregor> | Hixie, it's kind of a pain that the spec doesn't define things like phrasing vs. flow content for obsolete elements. In execCommand(), I need a category of "things that are safe to put in inlines", meaning in practice that if you put them in a <span> it will serialize safely to text/html. |
| 17:58 | <Hixie> | i can add something like that if you want |
| 17:58 | <AryehGregor> | E.g., if you have <p><font color=red>Foo</font> bar</p>, and the user bolds the whole paragraph, I want to be able to say you can do <p><b><font color=red>Foo</font> bar</b></p>. |
| 17:58 | <Hixie> | file a bug with the list of elements you want defined and the name of the term you want it defined as |
| 17:58 | <AryehGregor> | Okay, will do. |
| 18:03 | <AryehGregor> | Wait, can you put stuff like <p> inside a <b> in text/html? |
| 18:03 | <AryehGregor> | It looks like you can. |
| 18:03 | <AryehGregor> | So it's just invalid? |
| 18:03 | <AryehGregor> | Maybe this isn't needed, in that case. |
| 18:04 | <Ms2ger> | http://ln.hixie.ch/?start=1138169545&count=1 |
| 18:05 | <AryehGregor> | So it will work fine as long as they're nested properly? |
| 18:05 | <AryehGregor> | Why is it even invalid, in that case? |
| 18:07 | <Hixie> | it's more often an indication of a mistake than intentional |
| 18:08 | <AryehGregor> | Really? How so? |
| 18:11 | <Hixie> | <p><b>.... <p><b>... <p><b>... |
| 18:11 | <AryehGregor> | Oh. |
| 18:11 | <AryehGregor> | Hmm. |
| 18:11 | <Hixie> | there are very few times you ever need to actually nest paragraphs |
| 18:11 | <Ms2ger> | <p><span><ul> |
| 18:11 | <Hixie> | arguably there are no times because it's meaningless, though in practice there are times where it's not completely meaningless |
| 18:11 | Ms2ger | still wishes that happened |
| 18:12 | <AryehGregor> | Oh, so in that case it will actually nest the paragraphs? Yeah, I can see why you'd want to avoid that, then. |
| 18:12 | <Hixie> | it'll nest the <p>s in the case above, yeah |
| 18:12 | <AryehGregor> | Although why can't you make the paragraph nesting invalid, while still allowing <b><p>Foo <p>Bar</b>? |
| 18:12 | <Hixie> | you can also nest paragraphs with just one <p>, as in "foo bar<b>baz <p>foo bar" |
| 18:12 | <AryehGregor> | If you close your <b> then it's not relevant, though, is it? |
| 18:13 | <AryehGregor> | So just make the lack of closing tag the error. |
| 18:13 | <Hixie> | it turns out the syntax gets really unintuitive if you allow <p> inside things like <b> |
| 18:13 | <Hixie> | we could do it |
| 18:13 | <Hixie> | but i don't think people would thank us on the long run |
| 18:13 | <Hixie> | it'd be a different matter if </p> wasn't optional |
| 18:13 | <AryehGregor> | Hmm. |
| 18:13 | <Hixie> | also, semantically given our definitions of the various phrasing elements, there's very few cases where it makes sense |
| 18:14 | <Hixie> | (for <i> there's a better argument, admittedly) |
| 18:14 | <AryehGregor> | How about for things like <ol>, where the ending tag isn't optional anyway? |
| 18:14 | <AryehGregor> | There are cases where you want to <strong> or <small> multiple paragraphs in a row, for example. |
| 18:14 | <Hixie> | yeah, there are cases where it makes sense |
| 18:15 | <Hixie> | the problem is that it interacts poorly with previous paragraphs, even in the <ol> case |
| 18:15 | <Hixie> | e.g. <small><ol>...</ol></small> should be allowed |
| 18:15 | <Hixie> | but <p>... <small><ol>...</ol></small> doesn't do what it looks like |
| 18:15 | <AryehGregor> | Ah. |
| 18:15 | <Ms2ger> | Depends on what it looks like to you, I guess :) |
| 18:15 | <AryehGregor> | That's an issue, yeah. |
| 18:16 | <AryehGregor> | Oh well. |
| 18:16 | <Hixie> | for a while we had the spec allow nesting <ol>s inside <p>s |
| 18:16 | <Hixie> | primarily for xhtml |
| 18:16 | <Ms2ger> | Hmm, you're right |
| 18:16 | <Hixie> | we even for a while had the <span> thing ms2ger described above |
| 18:16 | <AryehGregor> | But if it's invalid anyway, I'm not going to worry, I'll just allow stuff like <b><listing>foo</listing></b> or whatever to happen in the odd case you have such an element. |
| 18:16 | <Hixie> | but it doesn't really work sadly |
| 18:16 | <AryehGregor> | I mean, given that it parses okay when you serialize the DOM. |
| 18:16 | <AryehGregor> | I assumed it didn't parse right. |
| 18:17 | <Hixie> | AryehGregor: yeah for execCommand() i think the guideline to use is "don't make a conforming document non-conforming" |
| 18:17 | <AryehGregor> | Hixie, in practice it looks like there has to be some mode that can make the document non-conforming, because at least e-mail clients seem to need to use <font> if they want to be understood by, e.g., Blackberry. |
| 18:17 | <Hixie> | AryehGregor: when you start with a non-conforming document, it doesn't really matter critically what happens |
| 18:18 | <AryehGregor> | The HTML/CSS engines in some common e-mail clients appear to be terrible. |
| 18:18 | <TabAtkins> | They don't appear to be. They are. |
| 18:18 | <AryehGregor> | But I'll see if we can get away with making that a non-default mode. |
| 18:18 | TabAtkins | shudders at the memories. |
| 18:18 | <Hixie> | yeah the e-mail use case might need a different mode |
| 18:18 | <Hixie> | but in that mode just pretend <font> is conforming and my statement still holds :-) |
| 18:18 | <TabAtkins> | I don't understand how people ever did table-based layouts. I did two complex emails using them, and it was the worst coding experience of my life. |
| 18:18 | <AryehGregor> | They were the only thing that worked. |
| 18:18 | <Hixie> | TabAtkins: indeed |
| 18:24 | <TabAtkins> | Argh, can I please have XML5 SVG already? Quoting attribute values is so annoying. >_< |
| 18:24 | <AryehGregor> | Serve as text/html. |
| 18:25 | <TabAtkins> | That doesn't let me use it as an image. |
| 18:25 | <AryehGregor> | It should. |
| 18:25 | <AryehGregor> | File bugs. |
| 18:25 | <AryehGregor> | :) |
| 18:26 | <TabAtkins> | Problem is that we probably don't want to allow HTML as an image in general. |
| 18:26 | <TabAtkins> | We do a lot of (non-interoperable) hacks to make SVG less objectionable as an embedded image. |
| 18:26 | <zewt> | AryehGregor: personally I'd be happy with email clients universally refusing to apply fonts in emails. heh |
| 18:26 | <zewt> | it boggles the mind that gmail doesn't have an option to ignore fonts in html mail |
| 18:27 | <Ms2ger> | zewt++ |
| 18:28 | <Ms2ger> | Myself, I'd be even happier without HTML email |
| 18:29 | <zewt> | certain limited uses are okay, but I decide what font and color I read mail in, not the other guy |
| 18:33 | <TabAtkins> | Particularly, most people that set the font color of their emails don't follow the basic accessibility guidelines of also setting the background-color, often rendering it unreadable for me. |
| 19:54 | <annevk> | Hixie, "Create an event that uses the MessageEvent interface, with the name text" should be named message just like Web Sockets |
| 20:31 | <AryehGregor> | Has anyone ever found that sometimes WebKit's Web Inspector inconsistently refuses to let you set a breakpoint at some line on a script, sometimes until you reload the page and sometimes until you restart? |
| 20:32 | <AryehGregor> | I've had that lately with Chrome dev, and it's really really annoying. |
| 20:32 | <AryehGregor> | Clicking on a line, or picking "Add breakpoint" from the context menu, just does nothing. |
| 20:33 | <AryehGregor> | On the other hand, Firebug routinely just claims there are no scripts on the page. |
| 20:34 | <Ms2ger> | I think that happened to me when going back/forward in history |
| 20:34 | <zewt> | i gave up on firebug long ago; always made firefox unusably flaky |
| 20:34 | <zewt> | even when not using it |
| 20:36 | <AryehGregor> | I've also found that WebKit sometimes doesn't update the Elements view in Web Inspector properly until you close and reopen it. |
| 20:36 | <AryehGregor> | It's really incredibly annoying. |
| 20:36 | <AryehGregor> | But I don't have a reduced test-case or anything, it's unreliable. |
| 20:40 | jgraham | finds that kind of problem all the time with all page inspectors |
| 20:40 | <jgraham> | But yeah, the bugs all seem to be stateful and hard to reproduce on demand |
| 20:41 | <AryehGregor> | I didn't try at all to reproduce it, admittedly. |
| 20:44 | <AryehGregor> | I feel like it didn't used to happen, with Web Inspector. |
| 20:44 | <AryehGregor> | (dunno about Firebug) |
| 21:59 | <AryehGregor> | Ms2ger, did I ever ask you to take my tests for createContextualFragment()? |
| 21:59 | <AryehGregor> | Ms2ger, they're here: http://aryeh.name/spec/dom-parsing-and-serialization/test/ |
| 21:59 | <Ms2ger> | Ooh, nice |
| 22:01 | <Ms2ger> | Oh, did you update Anolis, btw? |
| 22:08 | <AryehGregor> | When? |
| 22:14 | <Ms2ger> | After --dump-xrefs broke :) |
| 22:15 | <AryehGregor> | I just stopped dumping my xrefs for editcommands. It's going to be merged into HTML5 eventually anyway, so it's not like anyone will ever want them. |
| 22:15 | <Ms2ger> | That makes sense |
| 22:18 | <TabAtkins> | Hmm, is there an easy way to tell if I'm 32 or 64 bit on Ubuntu? |
| 22:19 | <AryehGregor> | TabAtkins, uname -a should do it. |
| 22:20 | <TabAtkins> | Excellent, thank you. |
| 22:20 | <AryehGregor> | uname -m, more specifically. |
| 22:20 | <TabAtkins> | Well, -a gave me sufficient information for me to find an appropriate-looking value. |
| 22:20 | <TabAtkins> | I'm gonna try out Sublime Text 2 as an editor, and needed to know which build to use. |
| 22:21 | <AryehGregor> | Cool: http://src.chromium.org/viewvc/chrome?view=rev&revision=77860 |
| 22:22 | <zewt> | hmm |
| 22:23 | <zewt> | but that may encourage people to put site titles as prefixes, when so far people have been encouraged to make them suffixes, which is better |
| 22:23 | <zewt> | eg. "text - Google Search" instead of "Google Search - text" |
| 22:29 | <AryehGregor> | Yes, the real solution is just to have people who use site name prefixes die in a fire. |
| 22:29 | <AryehGregor> | But sometimes it's not practical. |
| 22:30 | <AryehGregor> | E.g., consider a message board with a multipage thread, and the user is viewing the first page. |
| 22:30 | <zewt> | sure, but if people see it and start using prefixes where they would have otherwise used suffixes, it's a loss |
| 22:30 | <AryehGregor> | Do you do "Thread title - Page 1 - Site Name" or "Page 1 - Thread title - Site Name"? Presumably the latter. |
| 22:30 | <AryehGregor> | Er, the former. |
| 22:30 | <AryehGregor> | But then what if the user is viewing multiple pages at once? |
| 22:30 | <AryehGregor> | I think people use prefixes because they didn't think about it, so I'm not too worried about that. |
| 22:31 | <zewt> | personally I don't understand why vertical tabs are so poorly supported; they're a much more obvious way of listing tabs |
| 22:31 | <zewt> | afaik only Opera supports it natively and Firefox with some questionably-supported extensions |
| 22:32 | <AryehGregor> | Why don't OSes do it? |
| 22:32 | <zewt> | it's one of the main things keeping me from using Chrome |
| 22:32 | <zewt> | they can |
| 22:32 | <AryehGregor> | Anyway, it doesn't bother me. |
| 22:32 | <AryehGregor> | Yeah, I guess they can. |
| 22:32 | <AryehGregor> | Pretty sure Windows and GNOME do, at least. |
| 22:32 | <TabAtkins> | zewt: Switch to a portrait-orientation on your monitor. Then tabs at the top make more sense. |
| 22:32 | <zewt> | heh |
| 22:33 | <TabAtkins> | You need a monitor large enough that the narrow side is at least 1024, though. |
| 22:33 | <zewt> | i typically have 30-50 tabs open per browser window; horizontal tabs are a non-starter |
| 22:33 | <TabAtkins> | Ah, k. Stop doing that, then? |
| 22:33 | <TabAtkins> | That was my solution. |
| 22:33 | <zewt> | i like doing that; it works well for me |
| 22:34 | <TabAtkins> | Sure, except that it's harder to get the tabs to display right for you. ^_^ |
| 22:34 | <zewt> | right now I'm using one of those aforementioned extensions, but it's not ported to FF4 yet... |
| 22:34 | <gsnedders> | zewt: Use Opera? :P |
| 22:34 | <zewt> | i used to :) |
| 22:34 | <AryehGregor> | I used to use a Firefox extension that allowed multiple rows of tabs. |
| 22:34 | <AryehGregor> | Worked pretty well. |
| 22:35 | <AryehGregor> | There were scrollbars if it got beyond three. |
| 22:35 | <AryehGregor> | Tab Mix Plus, it was called. |
| 22:35 | <AryehGregor> | Then I realized extensions are a horrible idea and switched to Chrome. |
| 22:35 | <zewt> | (using FF for the typical reason: too much stuff in extensions it has that Opera doesn't) |
| 22:35 | <zewt> | i use TMP+VertTabbar |
| 22:36 | <zewt> | most of the blockers for using chrome are fixed (abp, stylish, a couple other things), but the vertical tab thing is still in the way |
| 22:37 | <zewt> | (also not crazy about my process list being totally filled with dozens of Chrome processes, heh) |
| 22:39 | <zewt> | jesus, someone sure is dissertationing about D&D on the list, heh |
| 22:41 | <TabAtkins> | I really wish drap-n-drop wasn't abbreviated to D&D or DnD. That already carries strong and hard-to-overwrite connotations in my head. |
| 22:42 | <zewt> | "Proposal: add dice rolling methods to the D&D API" |
| 22:51 | <TabAtkins> | I kinda want to file a bug on that. |
| 22:51 | <TabAtkins> | Except I don't want to waste Hixie's time. |
| 22:51 | <zewt> | heh |
| 22:52 | <Hixie> | do i abbreviate it anywhere? |
| 22:52 | <TabAtkins> | I doubt it, unfortunately. |
| 22:52 | <Hixie> | problem solved! |
| 22:52 | <TabAtkins> | My bug would be about adding dice-rolling methods. |
| 22:52 | <Hixie> | hah |
| 22:53 | <gsnedders> | TabAtkins: Using a how many sided die? |
| 22:53 | <TabAtkins> | Well, that's clearly a parameter to the methods. |
| 22:53 | <zewt> | NaN |
| 22:54 | <aho> | NaN NaN NaN NaN batman :v |
| 22:55 | <zewt> | :| |
| 23:27 | <hober> | sidedness could be a new CSS unit |
| 23:27 | <hober> | 20d |
| 23:27 | <hober> | oof, that looks like 20 old pence |
| 23:41 | <TabAtkins> | hober: units are allowed (per the grammar) to have numbers in them, so 20d6 can be a valid CSS value, using the 'd6' unit. |
| 23:42 | <zewt> | that leads to the question of metaunits |
| 23:42 | <zewt> | eg. width: 2d6em |
| 23:42 | <zewt> | i just made myself sad |
| 23:42 | <TabAtkins> | That's calc( 2d6 * 1em ) |
| 23:43 | <TabAtkins> | (Given that the dX units are subtypes of <integer>, I guess.) |
| 23:45 | <zewt> | though that raises the question of when the value is resolved; having a new width chosen during each reflow would be unpleasant |
| 23:45 | <TabAtkins> | Indeed, that's a harder problem. |
| 23:47 | AryehGregor | will be interested to see the answer to his comments here: http://blogs.msdn.com/b/ieinternals/archive/2011/03/14/internet-explorer-hidden-images-styled-with-display-none-always-have-zero-0-height.aspx |
| 23:49 | <TabAtkins> | Yeah, that behavior is clearly broken, as it means that <img>s which haven't yet been inserted into the document (and thus aren't participating in layout) should return 0 as well. |
| 23:49 | <zewt> | that's pretty evil |
| 23:49 | <zewt> | happen to know if it happens if the image isn't hidden, but it's in a container which is? |
| 23:49 | <TabAtkins> | If the container is display:none? Should be the same. |
| 23:50 | <zewt> | i regularly do that to preload images (without using the evil load-images-without-putting-them-in-a-document hack) |