00:10
webr3
meh's at xmlns, bloody pita
01:10
<MikeSmith>
Hixie: http://caniuse.com/#background-img-opts
01:10
<MikeSmith>
fwiw
01:10
<MikeSmith>
as far as browser support
01:11
<Hixie>
border-image, not background-image, but yeah, i looked at caniuse :-)
01:11
<MikeSmith>
seems fantasai is still working on the spec pretty actively
01:11
<MikeSmith>
ah
01:11
<MikeSmith>
nm then *)
01:11
<Hixie>
she's been working on that spec for like a half-decade
01:16
<gsnedders>
Does anywhere spec that getting an element which has had a custom property set on it before must get the same element with the custom property still set, regardless of GC?
01:20
<hober>
I could have sworn that was in web dom core, but I can't find it
01:21
<gsnedders>
If it's in web dom core, I guess I should be embarrassed seeming I briefly edited it :P
01:22
<hober>
:)
04:28
<Hixie>
when making a tileset, e.g. for techniques like css sprites, is there any advantage to using a grid over using a single row for all the images?
08:01
<Hixie>
man, webkit-border-image is quite buggy
09:12
<hsivonen>
must be a busy year both for legitimate HTML5 trainers and snakeoil salesmen
09:13
<hsivonen>
now that publishers are waking up to iOS apps being a bad deal and staff need to be trained for "HTML5"
10:42
<Philip`>
Hixie: If the images are not all equal sizes, you can pack them more tightly into a squarish grid
10:44
<Philip`>
Implementations will have some maximum height/width limits, so if you've got a very large number of images in a row you might hit that
10:45
<Philip`>
(PNG can only represent 64K pixels in each direction; I don't know if implementations have tighter limits)
10:46
<Philip`>
(Incidentally, I'd expect a column would probably be minutely more efficient than a row, if you don't want a grid)
12:59
<annevk>
alright, I guess I'll write some more Change Proposals
13:00
<annevk>
one for ISSUE-150 as micromanaging editors is annoying (if the W3C had a proper style guide for these questions it would be a different matter)
13:01
<annevk>
and one for ISSUE-140 as we should not introduce versioning in conformance
13:29
<annevk>
damnit
13:29
<annevk>
now I wrote CPP twice
13:29
<annevk>
if you all read CCP there you'll be fine
19:04
<AryehGregor>
Why do people use things like Mersenne twister when they can just use, e.g., AES in counter mode?
19:04
<AryehGregor>
Are they much faster?
19:05
<AryehGregor>
If AES is a secure block cipher, its output is computationally indistinguishable from a random bitstring.
19:06
<AryehGregor>
Maybe things like Mersenne twister are comparably secure, though, in which case I guess it makes no difference.
19:11
<Philip`>
The cipher will never repeat, which doesn't sound like good randomness
19:12
<AryehGregor>
Oh, right.
19:12
<AryehGregor>
It's indistinguishable from an arbitrary pseudo-random permutation.
19:12
<AryehGregor>
But repetitions have negligible probability anyway with a 128-bit block size, right?
19:12
<erlehmann>
I don't get it. Wouldn't a cipher need an initialization vector and a key? and on top of that a counter input?
19:13
<erlehmann>
While a random number generator only needs a seed?
19:13
<AryehGregor>
You'd use your seed as a key, and start the counter from 0. You have to have a random seed anyway.
19:14
<Philip`>
Depends on what you consider negligible, and why you'd put up with theoretical non-randomness instead of using something specifically designed to be random
19:14
<AryehGregor>
You can't be secure against negligible probabilities anyway. Basically all cryptographic theorems say "except with negligible probability" in them.
19:15
<AryehGregor>
I mean, you can be secure in some cases.
19:15
<AryehGregor>
Like a one-time pad.
19:15
<AryehGregor>
But it's an unreasonable requirement given how much more you can do if you allow negligible probabilities of stuff breaking.
19:15
<AryehGregor>
I dunno, my crypto course covered block ciphers and not PRNGs independently, so maybe I'm biased. :)
19:16
<AryehGregor>
Theoretically, it's considerably superior to minimize the number of assumptions, so if you can prove something secure given that AES is secure, and you already rely on AES's security . . .
19:16
<erlehmann>
AryehGregor, a one-time pad only moves the problem. How to you securely communicate the one time key? I suspect that is an infinite regress.
19:17
<AryehGregor>
Well, that's a separate problem. You have to solve one problem at a time. The one-time pad solves one specific problem perfectly.
19:17
<AryehGregor>
It has other problems too, like it's malleable.
19:18
<AryehGregor>
E.g., I can flip a bit in the ciphertext and it will be flipped in the message.
19:18
<AryehGregor>
So if I happen to have external knowledge of what a particular bit means, I can modify the message -- although it stills gives me no information.
19:19
<Philip`>
If you only want the PRNG output for use in crypto stuff, then I guess you might worry less about its randomness properties than if you're using it for statistical computation stuff, so AES would probably be okay
19:20
<Philip`>
If you care about it being a good uniform distribution in up to 623 dimensions then you'd use a Mersenne twister instead, I suppose
19:20
<AryehGregor>
Even for statistical computation, surely you can't run enough rounds of AES for non-repetition to be statistically detectable?
19:21
<erlehmann>
>rounds
19:21
<erlehmann>
that sounds computationally expensive
19:21
<AryehGregor>
I don't know why people want such extragavant period sizes for RNDs.
19:22
<AryehGregor>
I meant "you can't run AES enough times". AES has a fixed number of rounds depending on key size.
19:22
<AryehGregor>
Maybe it's just that AES is slower than Mersenne twister.
19:22
<erlehmann>
Jack up the AES rounds up to eleven!
19:25
<Philip`>
There is e.g. http://infoscience.epfl.ch/record/99493 which says "A preliminary study suggested that [Rijndael] required too many rounds for randomness, because the size of the elementary round functions is too small."
19:26
<Philip`>
I don't understand what it's talking about at all, but it seems the general impression is that being a decent cipher doesn't necessarily imply being a decent PRNG
19:27
<Philip`>
(or at least not provably decent)
19:28
<AryehGregor>
Ms2ger, what's "Assert: refNode is not null" supposed to mean?
19:29
<Ms2ger>
That refNode shouldn't be null at that point in the algorithm
19:30
<Ms2ger>
The "Node!" in the IDL means that a TypeError should be thrown when you pass null in
19:30
<Ms2ger>
(Not yet in any spec, though)
19:31
<AryehGregor>
Oh, exclamation point.
19:31
<AryehGregor>
I didn't notice that.
19:32
<AryehGregor>
Current WebIDL says you can always pass null for objects, right?
19:33
<Ms2ger>
Yeah
19:33
<Ms2ger>
That might change
19:33
<gsnedders>
But null is an object! typeof says so!
19:34
<AryehGregor>
It's not a Node, though.
19:35
<AryehGregor>
So why should it be passable as a Node argument?
19:35
<AryehGregor>
That's why we have "Node?", right?
19:35
<Ms2ger>
We don't
19:35
<Ms2ger>
"Node?" isn't allowed in current WebIDL
19:36
<AryehGregor>
Well, only because "Node" already means what you'd expect "Node?" to mean.
19:36
<Ms2ger>
(The idea is that "Node" becomes "Node?" and "Node!" or "[NoNull] Node" becomes "Node")
19:37
<gsnedders>
AryehGregor: That wasn't a serious argument.
19:40
<AryehGregor>
Ah.
19:51
<Hixie>
anyone know of an equivalent to ImageMagick for audio?
19:53
<benschwarz>
Hixie: I want to discuss some features for appCache with you… are you around in about an hour and a half?
20:05
<Hixie>
benschwarz: can't predict when i'll be around
20:05
<Hixie>
benschwarz: sorry
20:05
<benschwarz>
Hixie: sure, I'll pull something together if you're not around
20:08
<Hixie>
benschwarz: my irc client is always online, so feel free to ask questions and i'll reply when i can (assuming you leave your irc client on too!)
20:09
<Hixie>
i have to merge some sound files together in an automated fashion on my linux server
20:09
<Hixie>
so far the only way i've found to do it is to manually mix the wave files
20:09
<benschwarz>
Hixie: wav files? can't they just be cat / appended to each other?
20:09
<Hixie>
i need to mix them
20:10
<Hixie>
not concatenate them
20:10
<Hixie>
with differences in volume and in stereo position
20:11
<benschwarz>
Hixie: you're not on a mac, are you?
20:11
<Hixie>
the server is debian
20:11
Hixie
is on a mac right now, but this is for a web service, not a one-off
20:11
<benschwarz>
ok. I can't help :)
20:13
<Hixie>
and my input files are all different bitrates, #s of channels, etc
20:13
<Hixie>
this is going to suck
20:13
<AryehGregor>
Blech, writing tests requires you to actually decide what you want to test. How tiresome.
20:13
<Hixie>
AryehGregor: i often write what i call "demos" which have no pass conditions
20:13
<Hixie>
AryehGregor: and then, if i remember, convert them to real tests afterwards
20:14
<AryehGregor>
My problem is, if I have an algorithm defining something like range.setStart(), how do I decide what Ranges to test on?
20:14
<AryehGregor>
Since I could construct arbitrarily many.
20:14
<AryehGregor>
I guess I could just reuse the ones I made up for my extend() tests.
20:15
<Hixie>
could construct arbitrarily many :-)
20:15
<Hixie>
oops, copy-paste error
20:15
<Hixie>
i meant: construct arbitrarily many :-)
20:15
<AryehGregor>
No, because that takes forever to run.
20:16
<AryehGregor>
Like "longer than I'm willing to wait".
20:16
<Hixie>
construct arbitrarily many / 10 ?
20:16
<Hixie>
they can't be random, they have to be reproducible
20:17
<Hixie>
so just take a complicated DOM and then make a good cross-section of the possible ranges given that DOM
20:17
<Hixie>
(then repeat with a different DOM a few times so that you don't miss bugs that are hidden by that specific DOM)
20:17
<AryehGregor>
If I naively constructed test-cases for setStart() based on the nodes and offsets I have now, it would be something like (23*9)^3, which is too many.
20:17
<AryehGregor>
Yeah, I'm basically doing that (although the DOM isn't so complicated). I'm just annoyed that it requires thought, I guess. :)
20:17
<Hixie>
writing test cases requires a lot of thought
20:18
<Hixie>
(writing test cases without thought rarely finds bugs)
20:18
<Hixie>
(writing test cases _with_ thought should result in at lesat one bug per test :-) )
20:18
<Hixie>
though in your case you're not really looking for bugs per se
20:19
<Hixie>
more just edge cases to reverse engineer
20:19
<AryehGregor>
Writing test cases without thought finds lots of bugs. :)
20:19
<AryehGregor>
I'm writing general DOM Range tests right now.
20:19
<AryehGregor>
So it's not reverse-engineering at the moment. Reverse-engineering is different.
20:19
<Hixie>
ah ok
20:19
<Hixie>
do dom range implementations really suck that badly?
20:20
<Hixie>
that's sad
20:20
<AryehGregor>
Yes, they're totally incompatible.
20:20
<AryehGregor>
Especially Opera's.
20:21
<Hixie>
good times
20:21
<Hixie>
not really that surprising given how the dom range spec used to suck
20:21
<Ms2ger>
And I haven't specced what happens on DOM mutations yet
20:22
<AryehGregor>
Heh, didn't even notice that.
20:51
<annevk>
I hope mutations can be made to go asynchronous...
20:56
<annevk>
Ms2ger, I'm still thinking about putting events in DOM Core by the way. Just been a bit too busy.
20:56
<annevk>
Ms2ger, now you joined WebApps I guess your name can be put as editor of DOM Core again. :-)
20:57
<annevk>
Ms2ger, and you can update the W3C copy too! Teehee
20:57
<Ms2ger>
Yay :)
20:58
<annevk>
hmm, my "CPP" got quite some response. Does that mean I have to do something?
20:59
<AryehGregor>
You don't have to, but if you think it won't convince the chairs, it might make sense to change it.
20:59
<Hixie>
annevk: for the CCPs, are you still editing them?
21:00
<annevk>
I can change them, of course
21:00
<annevk>
but I just wrote them as one-off emails to start with
21:00
<annevk>
feel free to turn them into wiki pages though
21:12
<AryehGregor>
. . . what does it mean in WebKit Developer Tools when a CPU profile says 70% of time spent in "(program)"?
21:13
<gsnedders>
AryehGregor: program code, stuff in the global code
21:13
<gsnedders>
*scope
21:13
<AryehGregor>
Hmm.
21:13
<AryehGregor>
That seems unlikely, somehow.
21:14
<AryehGregor>
Hmm.
21:20
<AryehGregor>
Someone remind me, what's the point of the convention of wrapping your whole JS body in function () {...}();? Just to not litter the global namespace with anything?
21:22
<gsnedders>
AryehGregor: Yeah
21:22
<AryehGregor>
kthx.
21:23
<bga_>
AryehGregor `;(function(global){ })(this)`
21:24
<zcorpan>
function(window,undefined){}(window); is a pattern i saw somewhere
21:25
<GarethAdams|Home>
zcorpan: jquery does that
21:25
<zcorpan>
right
21:27
<zcorpan>
seems a bit pointless to me
21:33
zcorpan
does not like it when he gets emails with both a text/plain body and an HTML body but the text/plain body is entirely useless
21:34
<Ms2ger>
zcorpan++
21:42
<AryehGregor>
Looks like IE9 freaks out on long-running scripts.
21:51
<Hixie>
i'm having great trouble understanding the CP for 140
21:51
<Hixie>
what problem does it solve?
21:51
<Hixie>
it seems so completely misguided that i don't understand how to argue against it
21:52
<Ms2ger>
I'm not sure solving a problem is a requirement or CPs