07:37
<tiglionabbit>
hi
07:39
<tiglionabbit>
html5 specifies scripting features too, right?
08:55
<Hixie>
wow, not only does w3c want to charge us $250 each to help improve the web at tpac (in addition to the annual $60k for being able to put their brand on specs), but they require that we pay them through paypal, which i can't use
10:01
<Lachy>
Hixie, why can't you use PayPal?
10:01
<tiglionabbit>
what exactly are you paying for? Endorsement?
10:02
<annevk42>
TPAC attendance I guess
10:03
<annevk42>
PayPal doesn't work for me either
10:05
<Lachy>
annevk42, if Opera does send us, then I assume they would deal with the payment issues anyway
10:07
<tiglionabbit>
do you guys specify javascript changes too?
10:07
<annevk42>
we keep a page about where browsers have to be incompatible with the ECMAScript spec, but that's about it
10:08
<tiglionabbit>
hm
10:09
<tiglionabbit>
what would you guys think about specifying a standard bytecode as an alternative to javascript? Something that is easier to compile into, so people don't have to do silly things like GWT
10:17
<annevk42>
I wouldn't be a huge fan given the increased complexity, attack surface, etc.
11:22
annevk42
finds http://www.w3.org/TR/SVGParam/#DOMInterfaces
11:54
<annevk42>
http://people.xiph.org/~greg/video/ytcompare/comparison.html is interesting
11:55
<annevk42>
was that pointed out on the list already?
11:59
<Philip`>
It was
11:59
<Philip`>
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020405.html
12:02
<annevk42>
cheers
12:03
<Philip`>
It always seems kind of amusing when people talk about the video quality of YouTube, because high video quality isn't something YouTube is historically known for
12:04
<annevk42>
well, the argument was bandwidth + quality
12:05
<Philip`>
Stage6 did well on video quality, but not so well on bandwidth and on not-losing-tens-of-millions-of-dollars-per-year
12:06
<annevk42>
"The website never went beyond beta status, and was shut down by DivX Inc. on February 29, 2008 because of apparent inability to support Stage6 financially, or other officially unspecified reasons."
12:10
<annevk42>
"According to the web-news blog TechCrunch, the prime reason for the shutdown were not the Stage6-generated bandwidth costs (approx. 1 Million USD per month), but an internal conflict on the DivX, Inc. board."
12:10
<Philip`>
annevk42: I don't intend to disagree with the real argument; it just seems easy to caricature it as a (slightly) amusing situation of people engaging in deep technical discussions of the relative merits of Theora vs H263 vs H264 for encoding music slideshows and mobile phone videos of cats
12:10
<annevk42>
but TechCrunch is usually a lot of bs so whether that's true is unclear
12:11
<Philip`>
I can imagine that spending a million dollars a month with no revenue would be a significant cause of internal conflict :-)
12:14
<annevk42>
it also says they made enough cash
12:15
<annevk42>
but yeah, youtube is great for things like http://en.wikipedia.org/wiki/Keyboard_Cat
12:17
<Philip`>
Hmm, I'm not sure how much Stage6 would have driven downloads of the DivX Web Player
12:17
<Philip`>
(I just used the mplayer plugin, but I don't know what Windows users would do)
12:25
<Lachy>
why is it that all studies I've ever seen comparing video and audio codecs always rely on subjective analysis by a person to rate the quality? Surely, there are algorithms available that could be implemented in a program to objectively compare the original lossless video with the compressed versions
12:26
<Lachy>
and then whichever compressed version is closest to the original is superior
12:30
<Philip`>
It's easy to make quantitative comparisons (like PSNR), but very hard to make ones that closely correspond to what a human would subjectively perceive as quality
12:31
<Philip`>
e.g. a human would care much more about blurriness in the compression of human faces than of background details
12:32
<Philip`>
and a human might prefer an image that looks sharp than one that's more faithful to the original
12:49
jgraham
is amazed that people are suggesting that removing conformance requirements would reduce rathole discussions
12:50
<jgraham>
Seriously if we start telling people that HTML5 makes presentational markup conforming (whether or not we can justify such a thing logically) there will be the other of all flamewars
12:51
<jgraham>
*mother
12:53
<Philip`>
It wouldn't make presentational markup conforming - it would just mean the answer to "is this page conforming?" would always be "mu", as far as I can tell
12:55
<Philip`>
(You could still ask a question like "does this page follow the Best Practices described in this other document that isn't the HTML5 specification?")
12:56
<Philip`>
(and there could be competition between different groups trying to define the most useful sets of best practices for authors, rather than codifying one set in the spec itself)
12:57
<Philip`>
Anyway, it certainly would reduce rathole discussions, because they would all be consumed by a single giant Sarlacc-hole
13:55
<annevk42>
http://twitter.com/sarahebourne/statuses/2158980327 o_O so much for using <strong>!
16:29
gsnedders
gets another "bug report" of an XML parse error
17:59
<annevk42>
can someone run http://xmlhttprequest.testsuite.org/dump/xhr-doc/001.htm and http://xmlhttprequest.testsuite.org/dump/xhr-doc/002.htm in IE8?
18:08
<annevk42>
man, this stuff is complicated :/
18:41
<heycam>
is there a spec/rfc that defines a mapping of utf-16 code units to a sequence of unicode characters (in some way other than aborting for things like unmatched surrogates)?
18:43
<gsnedders>
AFAIK no, it is defined in Unicode to be undefined (when invalid)
18:43
<gsnedders>
(It isn't defined to abort, it just plain is undefined, explicitly so.)
18:44
<heycam>
k
18:44
<gsnedders>
Same for UTF-8 and UTF-32
18:44
heycam
should do some testing, he supposes!
18:46
<heycam>
rfc 2781 says "the sequence is in error" and to "terminate" for bad input
18:46
<gsnedders>
I'm more or less certain Unicode 5.1 does what I say
18:47
<annevk42>
for XHR I need DOMString to UTF-8
18:47
<annevk42>
actually, potentially a plethora of encodings with the proposal of making it dependent on inputEncoding
18:48
<heycam>
annevk2, would an algorithm to obtain a sequence of unicode characters be sufficient?
18:48
<heycam>
unicode characters to utf-8 is already defined
18:48
heycam
is working on http://www.w3.org/mid/op.uuzo0yff64w2qv@annevk-t60 btw
18:48
<annevk42>
that seems like a good solution
18:49
<annevk42>
if we have valid Unicode characters mapping is an issue for the relevant encoding specs
18:49
<heycam>
yup
18:49
<heycam>
i'll do that
18:50
<heycam>
but i won't make the "converting ES String to IDL DOMString" algorithm invoke this
18:50
<heycam>
it'd just be a definition that other specs could use as desired
18:50
<annevk42>
yeah, you don't want to invoke it there I believe
18:51
<annevk42>
you want to use it when you need to specifically do something with a DOMString
18:51
<annevk42>
like sending it over the wire
18:51
<annevk42>
or writing it to disk maybe
18:51
<heycam>
or choosing what chars to render or something
18:52
<annevk42>
true
19:13
<heycam>
annevk2, do you know what xhr requires in this case?
19:14
<heycam>
inserting as many U+FFFDs as there are bad code points (for some value of "bad")?
19:17
<annevk2>
no sorry
19:17
<annevk2>
i have not actually played with it, just found the issue affected xhr too
19:17
<annevk2>
(in some way)
19:18
<heycam>
k
20:42
<Hixie>
anyone got a good reference for GB2312?
20:44
<Hixie>
i guess rfc1345 will do
21:04
<Hixie>
how about big5
21:04
<ezyang>
zomg big5
21:04
<ezyang>
I think I ended up using iconv as a reference implementation.
21:25
<jruderman>
mmm, a video codec and html5 slashdot flamewar. http://tech.slashdot.org/story/09/06/14/1649237/YouTube-HTML5-and-Comparing-H264-With-Theora?art_pos=1
21:27
<gsnedders>
Peh, there are virtually no comments.
21:37
<Hixie>
i guess i'll reference wikipedia for big5
21:37
<Hixie>
since i can't find a useful normative reference
21:49
<annevk2>
Hixie, http://tools.ietf.org/html/rfc1922 seems to define it
21:49
<annevk2>
Hixie, it also has a further reference: http://tools.ietf.org/html/rfc1922#ref-BIG5