| 00:05 | <twisted> | but then how can I override the 80% to the 100% later? |
| 00:05 | <twisted> | cause that works... |
| 00:10 | <TabAtkins> | I don't understand the question. |
| 00:16 | <twisted> | TabAtkins: well, if I define a background: the initial gets set and can't be overriden you say |
| 00:16 | <twisted> | but then why can a background-size be overridden when it has been set? |
| 00:16 | <twisted> | or is initial some special thing that can't change anymore? |
| 00:20 | <TabAtkins> | No, it gets overridden because the 'background' property has higher specificity than your 'background-size' declaration. It's not permanent or unfixable. You can either set the individual property with a higher-specificity selector, or switch away from using the shorthand, since it's unnecessary in your case. |
| 00:21 | <TabAtkins> | (Just move 'background-repeat:no-repeat' to the general rules for "#main-menu > li > a", and then use background-image in the specialized rules. |
| 00:21 | <twisted> | yep that's what I did |
| 00:22 | <twisted> | just that background: ended up there because of laziness and simply because it *worked* in chrome but didn't in firefox and saw no real reason why it shouldn't have worked :) |
| 00:22 | twisted | goes very deeply by the if it works don't fix it concept |
| 00:22 | <TabAtkins> | Except it didn't work in Chrome - the background property was resetting your background-position rule. ^_^ |
| 00:22 | <twisted> | anyway :) ttyl, gotta get up early to bring my gf to the foot-specialist to figure out what she exactly broke |
| 00:23 | <twisted> | TabAtkins: true :) |
| 00:23 | <twisted> | cool thanks for the help |
| 00:23 | <twisted> | hehe |
| 00:23 | <TabAtkins> | np |
| 00:23 | twisted | saved this channel in autojoin |
| 00:24 | <twisted> | have to join it each time but forget |
| 00:24 | <twisted> | hehe |
| 01:10 | <aho> | eh... why is there no panning for Audio? |
| 01:10 | <aho> | kinda sucks for games :v |
| 01:10 | <TabAtkins> | Because <audio> is very simplistic, like <canvas>. This is being solved by a more advanced api designed by the guy sitting across from me. |
| 01:10 | <zewt> | audio filtering is a whole API in and of itself |
| 01:12 | <aho> | canvas is like 2 steps above audio |
| 01:12 | <kinetik> | aho: there are a couple of groups working on more powerful audio APIs. |
| 01:12 | <aho> | ye, i know... i was just very surprised that there isnt even panning |
| 01:13 | <aho> | i was even able to do that with java's midi stuff :P |
| 01:13 | <zewt> | 1d panning alone is pretty limiting; what about 2d (surround) and 3d (environmental) panning? may as well throw in environmental reverb and modelling too :P |
| 01:14 | <zewt> | of course, it's always frustrating when the line is drawn for an API's scope just *barely* below where you need it at the time, heh |
| 01:15 | <aho> | for now i would be happy if i could a) play sounds, b) without delay, c) w/o stutter, d) w/o randomly breaking, and e) with some little panning :> |
| 01:16 | <zewt> | without delay is hard, too :P |
| 01:16 | <aho> | currently only opera's sound is somewhat ok-ish (even though it also got that latency issue like all other browsers) |
| 01:17 | <aho> | it comes from a data uri and was load()ed once |
| 01:17 | <aho> | there shouldn't be any delay |
| 01:17 | <zewt> | not that simple at the OS level--it takes a lot more work to get "interactive" levels of delay than to get reliable streaming for music/video |
| 01:20 | <aho> | dunno... works fine in java, with openal, or things like fmod |
| 01:20 | <aho> | or flash :> |
| 01:21 | <aho> | no idea why browser vendors don't manage to get it right |
| 01:21 | <kinetik> | aho: because they haven't tried yet? |
| 01:21 | <aho> | i wasn't talking about panning |
| 01:22 | <kinetik> | nor was i. |
| 01:22 | <aho> | chrome for example goes silent after a few minutes |
| 01:22 | <zewt> | openal still exists? i seem to recall looking at its source ~10 years ago and it being some of the worst I'd ever seen (like, 8-12 levels of indentation per function) |
| 01:22 | <zewt> | (but being 10 years ago, I may be thinking of something else) |
| 01:23 | <aho> | firefox is kinda stuttery... 3.6 totally fails at short samples |
| 01:23 | <aho> | ie9 also doesnt work right |
| 01:23 | <zewt> | guessing most audio implementations to start are focusing on the music use case more than games |
| 01:24 | <zewt> | don't really know, though |
| 01:25 | <roc> | kthe short-sample bug might be fixed in Firefox 4 |
| 01:26 | <kinetik> | it is, it was also windows only iirc. |
| 01:26 | <zewt> | what I'd like to know is why browsers are allowing <audio> without asking permission, heh |
| 01:27 | <zewt> | audio is not something any page should be able to do without asking first |
| 01:27 | <roc> | I agree it is strange we are speccing out new A/V features at breakneck speed while basic stuff doesn't work too well across browsers :-) |
| 01:28 | <aho> | roc, yes short samples work a lot better now |
| 01:28 | <zewt> | both ff4 and chrome will happily obnoxiously play music without any kind of permission :| |
| 01:29 | <aho> | was possible with flash too |
| 01:29 | <zewt> | and that's exactly why I use flashblock |
| 01:30 | <aho> | guess browsers will add some volume control thingy at some point |
| 01:30 | <aho> | would make sense, i guess |
| 01:30 | <zewt> | it's strange that new browser APIs are written with limiting how obnoxious webpages can be in mind, but <audio> gets deployed without that |
| 01:31 | <zewt> | i guess audioblock won't be far off :) |
| 01:33 | <roc> | because for 99% of users, Web pages have been able to play audio since forever |
| 01:33 | <jarib> | 3 |
| 01:34 | <jarib> | < |
| 01:34 | <jarib> | >. |
| 01:34 | <jarib> | >. |
| 01:34 | <jarib> | <.> |
| 01:34 | <jarib> | woops. sorry :) |
| 01:34 | <zewt> | "flash does it wrong" is not a reason to excuse core web features from doing things wrong |
| 01:34 | <zewt> | (flash does lots of things wrong) |
| 01:35 | <aho> | ah... opera got a sound on/off thing since ages |
| 01:36 | <zewt> | a major thing needed is a way to find out who's playing sound (via any API); eg. an icon in Chrome's task manager |
| 01:36 | <aho> | doesnt seem to have any effect though... (i'm using the hyper glitchy webgl build) ;> |
| 01:36 | <zewt> | yeah that wasn't my Chrome window |
| 01:37 | <aho> | ye, like background tabs which play sound get their favicon replaced by a speaker icon (or a mini UV meter thingy) |
| 01:37 | <zewt> | so many times I've loaded a browser session, had sound start playing from some random tab and had to go hunting to figure out which, heh |
| 01:38 | <roc> | those are good ideas |
| 01:44 | <uf0> | should there be more than one <h1> on a page? |
| 03:02 | <Hixie> | i'm looking for people willing to take up writing CCPs for 131, 147, 155, and 144 (in that order), in case anyone is interested |
| 03:03 | <Hixie> | (i'm happy to help out, but am getting tired of taking point on these things) |
| 05:22 | <hober> | Hixie: I'll take a look at those issues in the morning and let you know which (if any) I'll take |
| 05:22 | <Hixie> | cool, thanks |
| 05:25 | <Hixie> | i wonder what PeerConnection.close() should do |
| 05:26 | <Hixie> | abrubtly end all communication? remove all the media streams and restart ICE (which will notify the other side that all the streams got removed)? send a simple packet to the other side telling it to abort everything? |
| 05:27 | <Hixie> | stop sending data but keep receiving it? |
| 05:28 | <Hixie> | i guess in the typical use case there has to be some out-of-band signaling separate from the SDP signaling channel |
| 05:28 | <Hixie> | and that's likely to be where the apps first agree that the session is ending |
| 05:28 | <Hixie> | so we don't need to be graceful at the ICE level |
| 05:55 | <Hixie> | abarth: our discussion the other day resulted in http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-data-stream |
| 05:55 | <abarth> | reading |
| 05:58 | <abarth> | encrypted twice. interesting |
| 05:59 | <Hixie> | yeah. the other layer is supposed to be actual encryption, the inner layer is supposed to make it so that there's never a known plaintext. |
| 05:59 | <Hixie> | but i don't know how much that makes sense, so i'm just calling it masking. :-) |
| 05:59 | <Hixie> | s/other/outer/ |
| 06:00 | <abarth> | looks reasonable |
| 06:00 | <Hixie> | cool |
| 06:00 | <abarth> | i bet you could combine those two layers somehow if you needed to save a few bytes |
| 06:00 | <abarth> | i'm not sure i understand the constraints on the outer layer |
| 06:00 | <Hixie> | it wouldn't save bytes, just CPU, right? |
| 06:01 | <abarth> | ah |
| 06:01 | <abarth> | yes |
| 06:01 | <Hixie> | originally i had the key be generated from the HMAC of the ice-key, the salt, and the nonce |
| 06:02 | <abarth> | that could work too |
| 06:02 | <Hixie> | but i was lying in bed and thinking about it and it struck me that since an attacker would always know the salt, could always get the nonce by inspection, and could likely engineer a known plaintext (the first four bytes are always 0x00 0x00 0x00 0x01 for example), that might not be as secure |
| 06:02 | <zewt> | blah spec crashing firefox, time to see if session saves thing i've been typing for 20 minutes... |
| 06:02 | <Hixie> | but i have no idea really |
| 06:03 | <abarth> | that's not really an issue |
| 06:03 | <Hixie> | seems that the maths would be harder this way, but likely no less possible |
| 06:03 | <abarth> | you should think of AES-128-CTR has giving your a stream of random bytes to XOR with the message |
| 06:03 | <abarth> | for all intents and purposes, they bytes are really random if you don't know the key |
| 06:04 | <Hixie> | ah ok |
| 06:04 | <Hixie> | so one layer would be just as good? |
| 06:04 | <abarth> | yeah |
| 06:04 | <Hixie> | k |
| 06:05 | <abarth> | i assume you've looked at this: http://tools.ietf.org/html/draft-jennings-rtcweb-api-00 |
| 06:06 | <Hixie> | don't think i've seen that one yet |
| 06:06 | <Hixie> | everybody and their dog seems to be writing requirements docs |
| 06:07 | <hsivonen> | hooray! WebKit landed async=false. |
| 06:14 | <Hixie> | abarth: k, spec updated to just use one layer |
| 06:21 | <zewt> | should there be a hash of the data within the packet, too, to prevent randomly tampering with encrypted packets? |
| 06:22 | <zewt> | (that's not implicit in -CTR, right? been a while...) |
| 06:22 | <abarth> | depends if you want integrity protection |
| 06:23 | <abarth> | CTR has zero integrity protection |
| 06:23 | <Hixie> | there's also the risk of replay attacks |
| 06:23 | <abarth> | at some point you're re-inventing DTLS |
| 06:27 | <Hixie> | does DTLS work without having to negotiate certs and stuff? |
| 06:27 | <Hixie> | we have a signaling channel here for that kind of stuff |
| 06:28 | <Hixie> | it would be unfortunate if our UDP data channel also had to do all kinds of stuff like that |
| 06:33 | <zewt> | without integrity protection, if an attacker knows a single, full packet (eg. a handshaking packet that's always the same), he can derive the key from the packet, then use that key over and over to generate whatever fake data he wants |
| 06:34 | <zewt> | (worse than just a replay attack) |
| 06:34 | <Hixie> | i thought AES-128-CTR prevented that |
| 06:34 | <Hixie> | (in principle) |
| 06:34 | <Hixie> | (for current technology) |
| 06:34 | <zewt> | CTR is supposed to never reuse a key |
| 06:35 | <Hixie> | right, it doesn't |
| 06:35 | <zewt> | by increasing a counter for each packet |
| 06:35 | <Hixie> | we have a nonce for each packet |
| 06:35 | <zewt> | but the key is determined by the sender, right? |
| 06:35 | <zewt> | right, the 16 random bytes--but nothing prevents me from taking your 16 random bytes and just using them again and again |
| 06:35 | <Hixie> | the key for each packet is a combination of the salt in the spec, the nonce, and the connection key |
| 06:36 | <Hixie> | sure, but that's just a replay attack |
| 06:36 | <Hixie> | you can't get the key from that |
| 06:36 | <Hixie> | (except by brute force) |
| 06:36 | <zewt> | i can get the key from an encrypted packet and a decrypted packet |
| 06:36 | <zewt> | (not the original AES key, the nonce+salt+ice-key key) |
| 06:36 | <Hixie> | abarth earlier asserted that you couldn't |
| 06:37 | <Hixie> | what's the difference between the original AES key and the nonce+salt+ice-key key? |
| 06:37 | <zewt> | correct me if I'm forgetting how it works, but AES-128-CTR is basically taking the input key (nonce+salt+ice-key), generating a securely-random block of bytes, and XORing those bytes with the plaintext |
| 06:38 | <zewt> | so if I know the plaintext (eg. handshaking packet) and I know the encrypted data (sniffing), I can XOR to get those random bytes back |
| 06:38 | <zewt> | then I can reuse the 16 random bytes (causing it to use the same random bytes), and then spoof whatever data I want |
| 06:38 | <Hixie> | well if that's correct then i should go back to the double-encryption thing i had specced earlier |
| 06:39 | <Hixie> | but abarth suggested it was not |
| 06:39 | <zewt> | i think here, the "counter" (in -CTR terms) in your scheme is the nonce? |
| 06:39 | <Hixie> | and i tend to trust abarth :-) |
| 06:41 | <zewt> | it's late and I'll look at it more tomorrow when I'm not tired, but I think for this to work the way you want, you'd want a counter in each packet that can only increase--but that won't work since UDP packets can come in out of order |
| 06:42 | <Hixie> | if what you describe is accurate, which isn't clear to me, then the previously-specced solution should work fine |
| 06:42 | <Hixie> | since it encrypts the nonce |
| 06:42 | <Hixie> | so that there's no known plaintext |
| 06:42 | <zewt> | have a URL to that version of the spec? i'll look at it tomorrow |
| 06:43 | <Hixie> | see the diff :-) |
| 06:43 | <Hixie> | (on tracker) |
| 06:43 | <zewt> | i don't even know where the diffs go :) |
| 06:43 | <Hixie> | (linked from the spec) |
| 06:43 | <zewt> | k found it |
| 06:45 | <zewt> | i think the missing piece here is you don't actually have a counter anywhere |
| 06:46 | <zewt> | the inputs to AES-128-CTR are the key, the plaintext and the counter--you only have the first two, so it's just plain AES-128 |
| 06:46 | <zewt> | anyway 'night |
| 06:47 | <abarth> | "i can get the key from an encrypted packet and a decrypted packet" <--- that's not really true |
| 06:49 | <Hixie> | so you can't just take an encrypted packet and the plaintext, xor them, xor the result with a new plaintxt, and send it on its way? |
| 06:49 | <abarth> | or rather, if you could, you could break AES and make lots of money by hacking the banking system |
| 06:49 | <abarth> | oh, you can alter the data in a single packet all you like |
| 06:49 | <abarth> | that's what we mean when we say there's no integrity |
| 06:49 | <abarth> | but that doesn't help you learn the contents of the message |
| 06:50 | <Hixie> | wouldn't my double-encryption thing protect you from that too? |
| 06:50 | <abarth> | nope |
| 06:50 | <Hixie> | why not? |
| 06:51 | <abarth> | imagine you knew the plain text was "attack at dawn" |
| 06:51 | <abarth> | the bytes on the wire are "attack at dawn" XOR something |
| 06:51 | <abarth> | so you take those bytes and XOR them with ("attack at dawn" XOR "let's do lunch") |
| 06:52 | <abarth> | it doesn't matter what the something is |
| 06:52 | <abarth> | the "attack at dawn"s cancel out |
| 06:52 | <abarth> | and the message decrypts to "let's do lunch" |
| 06:53 | <Hixie> | fair enough |
| 06:54 | <abarth> | if you want integrity, you need to do something like MAC the message using SHA1-HMAC |
| 06:54 | <abarth> | you can generated a key for that using the ice-key and another salt |
| 06:54 | <abarth> | to be precise, you should MAC the ciphertext |
| 06:55 | <Hixie> | what would you do with the MAC? |
| 06:56 | <abarth> | if you got a message with a bogus mac, you'd ignore it |
| 06:56 | <Hixie> | i don't follow |
| 06:56 | <Hixie> | how would you know it's bogus? |
| 06:57 | <abarth> | since the receiver knows the ice-key and the salt |
| 06:57 | <abarth> | he knows the mac-key |
| 06:57 | <Hixie> | i'm missing something here |
| 06:57 | <abarth> | ok |
| 06:57 | <abarth> | backing up |
| 06:58 | <abarth> | if we're worried about someone changing the message enroute |
| 06:58 | <abarth> | (rather than just learning the contents of the message) |
| 06:58 | <abarth> | we need some way for the receiver to drop messages that have been changed, right? |
| 06:58 | <Hixie> | right. |
| 06:58 | <abarth> | the most common approach to doing that |
| 06:59 | <abarth> | is to send something like a checksum with the message |
| 06:59 | <abarth> | that both the sender and receiver can compute |
| 06:59 | <abarth> | but the attacker cannot |
| 06:59 | <abarth> | so if the messages arrives with the correct checksum |
| 06:59 | <abarth> | the receiver knows it was sent by the sender at some point in the past |
| 06:59 | <Hixie> | ohh, you're saying send the MAC with the message |
| 06:59 | <Hixie> | got it |
| 06:59 | <abarth> | yes |
| 07:00 | <abarth> | that still doesn't solve the replay problem |
| 07:00 | <Hixie> | replay is easy to solve at the application layer |
| 07:00 | <abarth> | yes |
| 07:00 | <Hixie> | hmmm |
| 07:00 | Hixie | ponders whether to add a checksum or not |
| 07:03 | <Hixie> | any reason it has to be a different salt, btw? |
| 07:03 | <abarth> | you're never supposed to use the same key for more than one thing |
| 07:04 | <Hixie> | fair enough |
| 07:05 | <Hixie> | ok filed a bug on that |
| 07:07 | <Hixie> | yeah DTLS isn't really appropriate here |
| 07:08 | <Hixie> | having to do a handshake as part of setting this up seems silly when we have a signaling channel |
| 07:08 | <abarth> | yep |
| 14:24 | <matjas> | TabAtkins: What’s up with your CSS feed? |
| 14:25 | <matjas> | Make that your entire website :o |
| 14:26 | <matjas> | http://downforeveryoneorjustme.com/xanthir.com |
| 14:51 | <zewt> | "<abarth> "i can get the key from an encrypted packet and a decrypted packet" <--- that's not really true" <- not the AES key; the resulting block of data AES generates to XOR with the plaintext |
| 14:56 | <zewt> | "<Hixie> replay is easy to solve at the application layer" <- if you mean by user code, I don't recommend it--users shouldn't need to worry about that layer of security; you could, for example, have each peer send the salt the other side should be using (instead of using a hardcoded salt), which would stop replay entirely |
| 15:04 | <zewt> | including a hash in the packet won't fix the known-plaintext problem; the fundamental problem is this is using CTR without having a counter (which doesn't really make sense, it's missing a parameter to the algorithm) |
| 15:07 | <TabAtkins> | matjas: Sorry, I let my account run out of money. Funding it now... |
| 15:08 | jgraham | discovered once that letting your account run out of money is easy to do if all the email about impending doom goes to a dead or unused account |
| 15:08 | <jgraham> | Well I say once |
| 15:09 | <jgraham> | It was more like like twice in quick succession |
| 15:10 | <jgraham> | zewt: At risk of making an idiot of myself, don't you just start the counter at 0 at some point? So it doesn't need to be an input |
| 15:11 | <zewt> | jgraham: you have to specify what the counter is, it's not implicit--this is UDP, it's going to miss and reorder packets, so it's not as simple as "increment it once for each packet" |
| 15:15 | <TabAtkins> | jgraham: I got the $1 message a few days ago, I just didn't do anything with it. Sometime overnight I got the "we've turned off your website" message. ^_^ Back now, though. |
| 16:53 | <zcorpan> | hsivonen: webm.html5.org needs a snippet that people can use on their sites to show a link to webm.html5.org only when a webm video fails |
| 17:08 | <hober> | Hixie: OK, getting back to you on those CCPs. |
| 17:08 | <hober> | 131 is the sort of thing I'd like to run by Maciej, but he's on vacation. |
| 17:09 | <hober> | WRT 147, we support Frank's CP. |
| 17:09 | <hober> | 155 is not something we have any sort of position on, but I'm surprised to say that I personally agree with Leif on this one. |
| 17:10 | <hober> | (I can't say I ever expected to say that) |
| 17:10 | <hober> | Re: 144, we generate <u> in WebCore editing's applyStyle command, and don't intend to change that. All things being equal, we'd like the markup that we generate to be conforming. |
| 17:11 | <zcorpan> | hsivonen: maybe something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/883 |
| 17:11 | <jgraham> | hober: Why do you agree with Leif for 155 (just curious)? Assume I haven't read or understood any or what Leif wrote… |
| 17:12 | <hober> | jgraham: <table border=1> is the most succinct way to mark up a data table that survives syndication |
| 17:12 | Philip` | assumes that's not a far-fetched assumption |
| 17:13 | <hober> | Philip`: indeed, he's quite hard to follow most if not all of the time. |
| 17:16 | <jgraham> | Oh, is there actaully a CP just about border? I just read the issue title… |
| 17:18 | <jgraham> | (as a theoretical point, it seems that the "I want this to survive syndication" argument implies people don't really want seperation of content and style, they just want a convenient way of reusing style) |
| 17:19 | <hober> | jgraham: yeah, 155 is just about <table border> |
| 17:21 | <hober> | jgraham: In this case, I think the syndication argument is a pragmatic one. Personally, I want content and style to be separate. That said, if one of the most common methods for consuming my content mangles it in a way that makes it lose meaning, I'm happy to do something to avoid that |
| 17:21 | <hober> | Consider a data table which is a matrix of single digit numbers |
| 17:22 | <jgraham> | Right, I see that it could be bad to lose the border |
| 17:22 | <jgraham> | I'm wondering if it is ever the case that it could be bad to have the border |
| 17:22 | <jgraham> | Assuming one wasn't using tables for layout |
| 17:23 | <jgraham> | Otherwise, feed readers could add borders in their UA stylesheet |
| 17:23 | <hober> | If feed readers started doing that, that would be good New Information for revisiting the issue |
| 17:24 | <jgraham> | Right, in the absence of them actually doing that it seems that it could be pragmatic to allow authors to control it somehow |
| 17:25 | <jgraham> | In other news, I have no idea what the text at http://www.whatwg.org/specs/web-apps/current-work/#renderingUA means |
| 17:25 | <jgraham> | It sounds like "if a UA says it conforms to this section, it must conform to this section" |
| 17:26 | <hober> | jgraham: indeed |
| 17:27 | <AryehGregor> | hober, by applyStyle do you mean execCommand(), or is that something else that does a similar thing? |
| 17:27 | <jgraham> | Hmm, bug 12319 is at least the third time someone has made that mistake |
| 17:28 | <AryehGregor> | jgraham, it's saying that you can only claim to be "a visual user agent that supports the suggested default rendering" if you implement the rules in the rendering section. |
| 17:28 | <AryehGregor> | So it defines the term "a visual user agent that supports the suggested default rendering". |
| 17:29 | zcorpan | claims there are no user agents that support the suggested default rendering |
| 17:30 | <AryehGregor> | Well, yes. |
| 17:30 | <AryehGregor> | There are no user agents in any of the other conformance classes either, yet. |
| 17:31 | <zcorpan> | sure there is. i have a data mining tool that does nothing. i think it's a conforming data mining tool! |
| 17:33 | <zcorpan> | (it's my table; it's also a conforming HTML4 UA) |
| 17:34 | <hober> | jgraham: I think it's an internal noodly bit lower down than execCommand |
| 17:34 | <jgraham> | AryehGregor: ^ |
| 17:35 | <jgraham> | Although I approve of the idea of noodly bits. Functional and tasty! |
| 17:36 | <AryehGregor> | hober, I'm writing an execCommand() spec right now. Currently my plan is to have the default only output conforming elements, but if you set styleWithCSS = false, it will output stuff like <font> (for things like e-mail where you can't rely on clients supporting CSS). |
| 17:36 | <AryehGregor> | Of course, this will depend on what implementers think, since it's a change from the status quo. |
| 17:36 | <AryehGregor> | I do hope <u> becomes conforming, though. |
| 17:42 | <hober> | AryehGregor: link to your draft? I'll fwd it along to the right people over here |
| 17:42 | <hober> | which, now that I think about it, I think I've already done |
| 17:42 | <hober> | nvm |
| 17:42 | <AryehGregor> | hober, pretty sure they've seen it. :) |
| 17:42 | <AryehGregor> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030714.html |
| 17:43 | <AryehGregor> | I've had lots of discussion with rniwa in particular, and am busy rewriting the spec based on his input. |
| 17:43 | <AryehGregor> | Actually, WebKit people are the only ones who have given me much feedback so far. Except for Hallvord of Opera, who gave me a bookmarklet to use to trace execCommand() usage in insanely complicated rich text editors like Gmail. |
| 17:44 | <AryehGregor> | Which I'll be sure to use at some point. |
| 17:56 | <TabAtkins> | Yay, I found a nearly up-to-date version of my Lists UA stylesheet that I generated off the old spec a while back! That'll save me a lot of conversion efforts in rewriting the numeric and alphabetic lists. |
| 18:37 | <AryehGregor> | So apparently, bolding something in a text editor will only unbold it if the whole selection is already bold. |
| 18:37 | <AryehGregor> | Interesting. |
| 18:37 | <AryehGregor> | I thought it went according to the start, for some reason. |
| 18:39 | <TabAtkins> | Yes, that's the standard behavior. If anything is unbold, it bolds it first. |
| 18:58 | <zewt> | Hixie: it may be worth considering just using DTLS, because: it deals with all of the security issues we've discussed; it deals with some that I havn't brought up yet (like being able to support new ciphers/hashes down the line); it may improve interoperability (for example, allowing comms with other systems supporting the existing protocol); openssl already supports it; it's already (I expect) thoroughly audited; ... |
| 19:13 | <Hixie> | hober: k |
| 19:14 | <Hixie> | hober: could you elaborate on 147? |
| 19:14 | <Hixie> | jgraham: all the conformance classes are opt-in, essentially |
| 19:14 | <Hixie> | jgraham: the goal of that particular clause though is to let people write a test suite for the rendering section |
| 19:15 | <hober> | Hixie: it's not really my area of expertise; maybe eric_carlson can elaborate |
| 19:18 | <Hixie> | for <u> and <table border> and layout tables i expect i'm just not going to bother fighting it for now; maybe fork the whatwg copy, maybe just wait a few more years and try again. It's sad that every time we try to help the cause of accessibility advocacy by removing the presentational aspects, people insist on trying to keep some. |
| 19:18 | <Hixie> | it's so shortsighted. |
| 19:18 | <Hixie> | but oh well. |
| 19:19 | <bfrohs> | Hixie: That's humanity for ya :) |
| 19:20 | <eric_carlson> | Hixie: what is hober volunteering me for? |
| 19:21 | <hober> | eric_carlson: ISSUE-147 (the playbackRate thing) |
| 19:21 | <eric_carlson> | Hixie: OK |
| 19:23 | <eric_carlson> | Hixie: the problem is that is really isn't always possible to play at an arbitrary rate |
| 19:25 | <eric_carlson> | Hixie: so the current behavior in browsers that support rates other than 1 and 0 is what Frank suggests |
| 19:26 | <Hixie> | eric_carlson: it's always possible, why would it not be? |
| 19:27 | <Hixie> | playing it back faster is just a matter of decoding it faster, playing it back slower is just a matter of decoding it slower. playing it backwards is, at the extreme, just a matter of decoding it forwards into a buffer then playing it backwards. |
| 19:29 | <eric_carlson> | Hixie: OK, "not possible" was poorly chosen |
| 19:30 | <Hixie> | well if it's just possible but hard, tat's just a quality of implementation issue |
| 19:30 | <Hixie> | lots of things in the platform are hard |
| 19:30 | <Hixie> | rendering box-shadow on a large box is apparently hard, but we don't say that browsers can just give up after a certain number of pixels |
| 19:30 | <zewt> | well, there's a difference between "hard" and "doesn't fit the design of the data" (eg. "you really don't want to do this") |
| 19:31 | <eric_carlson> | Hixie: most (all?) media frameworks don't support arbitrary playback rates, and while it may be possible to work around the issue with the tricks you note, it seems *extremely* unlikely that anyone will do it |
| 19:31 | <Hixie> | yeah, the difference is a quality of implementation difference |
| 19:31 | <zewt> | eg. in the extreme case, say, 30 seconds of HD data with no keyframes and not enough memory to hold the entire uncompressed video in memory at once, you may have to decode the entire video for each frame, which is O(n^2); that's worse than just "hard", it's pathologically broken |
| 19:32 | <Hixie> | eric_carlson: well then the media frameworks aren't good enough and need improving. that's hardly the first time we've had that problem. platform networking frameworks have had to be rewritten for web browsers, platform font support has had to be shored up for web browsers, etc. why is media special? |
| 19:32 | <hober> | this sounds like an area where we're likely to have browser behavior converge on frank's proposal and not what's currently in the spec |
| 19:32 | <Hixie> | sure, we'll always have coverage on subsets of the spec before the whole spec |
| 19:32 | <Hixie> | the question is what do we want in the future, not what we have now |
| 19:33 | <eric_carlson> | Hixie: aren't good enough because they don't implement a feature that isn't terribly useful? |
| 19:33 | <Hixie> | eric_carlson: if arbitrary playback speed isn't useful, let's remove the feature, not just make it optional to implement |
| 19:34 | <Hixie> | i was under the impression that it was in facD[D[D[D[D[D[D[Dt terribly useful |
| 19:34 | <Hixie> | er, "fact" |
| 19:34 | <eric_carlson> | Hixie: isn't that essentially what the CP suggests: "If the user agent is unable to play back media at the requested rate, ignore the requested rate; playbackrate must not change" |
| 19:34 | <Hixie> | eric_carlson: that's making the feature optional, not removing it. |
| 19:35 | <Hixie> | eric_carlson: i'm suggesting if we have the feature we should require that it be implemented |
| 19:35 | <Hixie> | eric_carlson: and that if we don't want the feature, we remove it |
| 19:35 | <zewt> | it should be optional, since whether it's possible (or real-world-reasonable) to play at a specific rate (particularly in reverse) depends heavily on the file being played (keyframe frequency, mostly) |
| 19:35 | <zewt> | if you want to support playing backwards then you have to encode a file with that in mind |
| 19:36 | <zewt> | (i'd expect in practice if it's "required", browsers are going to sort of fudge it, such as by only playing keyframes--which seems worse than honestly telling scripts "nope, can't do that") |
| 19:38 | <Hixie> | seems much better to me to fudge it than not do it |
| 19:38 | <eric_carlson> | zewt: I don't agree that playing only keyframes is necessarily a bad idea |
| 19:38 | <Hixie> | seems even better to just do it right |
| 19:38 | <zewt> | well, more specifically: as a developer I'd rather have feedback from the UA when the quality of a feature is significantly reduced |
| 19:39 | <zewt> | and granted doing so by disabling the feature and ignoring the setting isn't necessarily the best way of doing so |
| 19:39 | <Hixie> | i guess i should submit two CPs: "this feature isn't useful so we should remove it altogether, not make it essentially useless", and "this feature is implementable, so it's just a quality of implementation issue and we should not have the browser refuse to set the rate" |
| 19:40 | <Hixie> | i don't mind having metrics saying how well the video is playing |
| 19:40 | <Hixie> | we need that anyway |
| 19:45 | <zewt> | (of course, either way, i'd think this has got to be at the bottom of the pile of important things to be worried about right now, heh) |
| 19:46 | <zewt> | do these things just get forced on you out of order? heh |
| 20:03 | <espadrine> | God, ie9 now supports webm?! |
| 20:03 | <espadrine> | officially! |
| 20:06 | <miketaylr> | ...with a plugin |
| 20:07 | <espadrine> | well, having them embrace it is pretty much the best we could hope for |
| 20:07 | <espadrine> | even with a plugin |
| 20:07 | <miketaylr> | better than nothing :) |
| 20:29 | <Philip`> | Sounds like IE9 supports WebM to the same extent that Safari support Theora |
| 20:34 | <aho> | safari doesnt even support audio on xp and vista |
| 20:35 | <aho> | i'm not really sure what's up with that |
| 20:35 | <aho> | (i.e. Audio is undefined) |
| 20:40 | <aho> | On Windows, if QuickTime is not installed, Safari is missing the "Audio" and "Video" APIs completely. - http://twitter.com/thomasfuchs/status/48095892976304129 |
| 20:40 | <aho> | that explains it :) |
| 20:53 | <karlcow> | http://www.w3.org/mid/AANLkTinLGdDzxn=KatYoJSkum_NFz5ddJQsHG8jJCdJb⊙mgc |
| 20:53 | <karlcow> | Spellchecker for the DOM |
| 20:57 | <Hixie> | zewt: yeah, the chairs decide the order |
| 20:57 | <Hixie> | ok, bbiab |
| 21:17 | <TabAtkins> | Hixie: Is it worth it for me to transcribe the syriac characters into a @counter-style rule? Looks like the language is dead, and it would be a lot of annoying copypaste. |
| 21:45 | <AryehGregor> | Wow, Eric Law is apparently very aggressive about editing his blog post comments: http://blogs.msdn.com/b/ieinternals/archive/2011/03/14/internet-explorer-hidden-images-styled-with-display-none-always-have-zero-0-height.aspx |
| 21:46 | <AryehGregor> | There were lots more before, and the one remaining one by me has been edited to point to the W3C spec instead of the WHATWG spec. |
| 21:46 | <TabAtkins> | That's... weird. |
| 21:46 | <AryehGregor> | Originally I linked to the WHATWG spec, then he asked if I had a W3C spec link, so I gave that. |
| 21:46 | <AryehGregor> | Then some other people posted comments. |
| 21:46 | <zewt> | that's unacceptable--you don't edit the writing of someone else, period |
| 21:46 | <AryehGregor> | Then my second comment disappeared, along with a bunch of other people's comments. |
| 21:47 | <AryehGregor> | Then I reposted some form of my second comment. |
| 21:47 | <AryehGregor> | Now he's removed all the other comments, including the ones he's left before; edited my first comment to link to the W3C spec; and added a response. |
| 21:47 | <AryehGregor> | Well, at least he filed a bug about it. |
| 21:48 | <zewt> | he's edited what you said to make it look like you said something you didn't; that's beyond unacceptable |
| 21:48 | <zewt> | the sort of thing that makes me angry even though it didn't even happen to me, heh |
| 21:51 | <AryehGregor> | Yeah, it's kind of objectionable. |
| 21:51 | <AryehGregor> | But oh well. |
| 21:51 | <AryehGregor> | I've had posts disappear before on various blogs, or never appear, but I don't think they were ever edited to make them say something they didn't before. |
| 21:52 | <TabAtkins> | Yeah, that's shitty. The most I've seen is in-place edits with a note from the site author indicating what they edited, and then it was only for really minor things. |
| 21:53 | <zewt> | censoring comments is bad enough, but editing other people's messages directly--intuitively I put that in a similar level of unacceptability as plagiarism |
| 21:53 | <AryehGregor> | Meh, no need to get excited about it. |
| 21:53 | <AryehGregor> | It's not like Microsoft is usually any better than that. |
| 21:54 | <TabAtkins> | On an unrelated note, luckily one of the geocities-preserval projects contained the reference I needed from this unicode technical note. |
| 21:54 | <AryehGregor> | . . . |
| 21:54 | <AryehGregor> | What? |
| 21:55 | <TabAtkins> | One of the cited references in this note was a geocities page about tamil numbering. |
| 21:56 | <zewt> | references to geocities, heh |
| 21:56 | <zewt> | i suppose the modern-day analogue would be referencing a pastebin |
| 21:56 | <AryehGregor> | Really. |
| 21:57 | <AryehGregor> | That's a little bit sad. |
| 21:57 | <TabAtkins> | Well, the note itself appears to be hosted on scribd, which isn't any better. |
| 21:57 | <AryehGregor> | Although I guess it's not so different from html5.org references in the HTML5 draft. |
| 21:58 | <Philip`> | zewt: Not really, since Geocities was intended for permanent hosting of individuals' sites, whereas pastebins are generally intended to be temporary and anonymous |
| 21:58 | <AryehGregor> | Philip`, plenty of pastebins default to permanent storage. |
| 21:58 | <zewt> | well, most pastebins have "expire: never" options--but I wouldn't count on them, either |
| 22:00 | <Philip`> | AryehGregor: They're probably technically as permanent as Geocities, but I don't think they give the impression to users that they'll exist forever |
| 22:00 | <AryehGregor> | Did Geocities give that impression, strictly speaking? |
| 22:00 | Philip` | had some sites on Geocities, and never considered the possibility that it would ever disappear |
| 22:01 | <AryehGregor> | Yeah, but is that because they gave you that impression, or because you made it up? |
| 22:01 | <Philip`> | (If I had thought about it I probably could have assumed it might disappear eventually, but I never thought about it) |
| 22:01 | <Philip`> | It's the impression I got |
| 22:01 | <Philip`> | regardless of where that impression came from :-) |
| 22:01 | <zewt> | we were all new at things back then :) |
| 22:02 | <Philip`> | Of course the things that I thought *would* disappear, like newsgroups postings, have stuck around forever |
| 22:04 | AryehGregor | finds his old Geocities page from when he was 16 |
| 22:04 | <Philip`> | (Also I put sites on my ISP's free web hosting thing, which was under the ISP's domain name, which was a bad idea since it meant I couldn't leave that ISP without losing my sites and email addresses) |
| 22:05 | <zewt> | everyone's done that... once |
| 22:05 | <AryehGregor> | This site really brings back memories. |
| 22:05 | <TabAtkins> | Did it used to be expensive to register domain names or something? |
| 22:05 | <zewt> | was originally something like $50/mo, I think |
| 22:05 | <zewt> | er |
| 22:05 | <zewt> | /year |
| 22:05 | <zewt> | (not *that* expensive. heh) |
| 22:06 | <Philip`> | http://www.dotweekly.com/respecting-a-domain-name-with-age-registration-history - "From 1995-1998 Network Solutions was the only domain name registrar and .com (I think .net and .org as well) domain name fee’s were $100 for a 2 year minimum" |
| 22:07 | <TabAtkins> | Jeez. |
| 22:07 | <Philip`> | That's quite expensive when you're about 12 :-) |
| 22:07 | <TabAtkins> | zewt was referring to his mistake of marking it as per month. |
| 22:08 | <AryehGregor> | Seems like the Gmail app got stuck in an infinite loop or something on my phone. |
| 22:09 | <AryehGregor> | It ran down the battery to 15% over the course of a few hours, with the screen off and everything, and the phone was hot to the touch. |
| 22:09 | <AryehGregor> | Yay power management! |