00:00
<daedb>
Hixie: IE9 shows the h264 video for all mime types
00:00
<Hixie>
and nothing for the others?
00:00
<Hixie>
and it starts at the same point for all of the ones that play?
00:01
<daedb>
nothing under ogg or webm columns
00:01
<Hixie>
k, thanks
00:01
<Hixie>
well of the browsers that sniff, that's the most rational behaviour
00:02
<daedb>
all videos that play look the same to me
00:02
<Hixie>
excellent
00:03
<daedb>
I'm only doing a quick look though, nothing too thorough :)
00:09
<Hixie>
bbiab
00:36
<nessy>
OMG that web page turns my machine into a turbo-heater!
01:48
<boblet>
TabAtkins: yt?
02:52
<othermaciej>
good lord, the NPN thread
02:52
<othermaciej>
just when I thought dealing with WebSocket protocol stuff couldn't get any more tine-consuming
03:54
<erlehmann>
anyone aware of a gzip compression implementation in javascript?
03:55
<jacobolus>
mcarter: did anyone ever do gzip in javascript that you know of?
03:55
<jacobolus>
erlehmann: you might try asking in channels w/ more specifically javascript devs
03:55
<jacobolus>
erlehmann: e.g. someone in #node.js might have some idea
03:56
<erlehmann>
i found one that writes zip files, but behaves funny … it does not compress.
03:56
<jacobolus>
anyway, good luck. I'm outta here
05:08
<nimbupani>
hey MikeSmith
05:17
<MikeSmith>
hey, it's nimbupani
06:36
<micheil>
annevk5: has anyone bothered to ask the biggest question of websockets: do we actually need protocol extensions?
06:37
<micheil>
like, I mean, what percentage of users / developers are actually going to use them?
06:38
<hober>
yes, that point has been raised on a number of occasions on the hybi list
06:38
<hober>
by maciej, ian, adam, and others
06:38
<micheil>
right, just thought I'd check
06:39
<micheil>
because really, I think we're going a little bit over the top with it all.
06:39
<micheil>
it's meant to be a simple transport method.
06:39
<micheil>
not the one-and-only ring-to-rule-them-all transport method.
06:40
<micheil>
like, sending a DVD over websockets, you probably should be doing that. Just use file transfers using http, that's already existent.
06:41
<micheil>
s/you probably should be doing/you probably shouldn't be doing
06:46
<cardona507>
one-and-only-ring-to-rule-them-all transport method - nice
06:46
<hober>
I'm sure you can easily imagine that you're preaching to the choir here. :)
06:47
<micheil>
good point.
06:47
<micheil>
I should get a few of the guys I know at Yahoo! to weigh in on it.
06:47
<micheil>
because I know some of the things they are planning to do / try with websockets are quite what it was necessarily designed for.
06:47
<cardona507>
you going to the crockford tech talk at yahoo! on the 27th?
06:48
<micheil>
sadly not.
06:48
<cardona507>
Yeah - I am looking forward to it
06:48
<cardona507>
talking about node
06:48
<micheil>
(well, not that I've been invited to have a plane fair paid :P)
06:48
<micheil>
wait. 27th august?
06:48
<cardona507>
heh
06:48
<cardona507>
yep
06:48
<cardona507>
next week
06:49
<micheil>
dang. wouldn't be able to go even if I wanted to.
06:49
<micheil>
curse exams.
06:49
<micheil>
:D
06:49
<cardona507>
http://www.meetup.com/BayJax/calendar/14371278/
06:49
<cardona507>
curse exams indeed :)
06:50
<micheil>
seriously.. pretty much missed any possibility to go to jsconf this year due to exams too. and I get to miss WDS due to more exams.
06:50
<micheil>
what's with that?
06:50
<cardona507>
hopefully a good degree
06:50
<cardona507>
or a good startup partner
06:50
<micheil>
actually, it's not a degree at all.
06:51
<micheil>
wrong level of education.
06:52
<micheil>
cardona507: this would be high school (final year) level.
06:52
<cardona507>
no way - nice - congrats
06:52
<cardona507>
I was about to type 'dr?'
06:52
<cardona507>
:)
06:53
<micheil>
haha, well, I've actually started my uni degree as well.
06:53
<cardona507>
computer science?
06:53
<micheil>
(well, I've completed one of the modules, I still have about 6 core modules of compsci left.)
06:53
<micheil>
yeah, a computer science degree.
06:54
<cardona507>
what languages?
06:54
<micheil>
it's just general at the moment
06:54
<cardona507>
what language do you intend to focus on?
06:54
<micheil>
javascript?
06:54
<micheil>
:P
06:54
<cardona507>
cool
06:55
<cardona507>
FTW
06:55
<micheil>
probably either javascript, C, or Erlang
06:55
<micheil>
not that I've done much of the latter two
06:56
<cardona507>
me neither
06:56
<cardona507>
i like JS though
06:57
micheil
will bbl.
06:57
<cardona507>
ttyl
07:41
<MikeSmith>
bobchao: congrats on what seemed to be a really successful COSCUP
08:16
<MikeSmith>
hmm, cvs update kinda seems to take a long time when you have a directory with 1034 files in it
09:28
<jgraham>
MikeSmith: This is where we mock you for using CVS, right?
09:28
<MikeSmith>
heh
10:16
<annevk5>
netsplit much?
10:16
<annevk5>
actually, sending DVDs over WebSocket is something the pro-simple camp brought up
10:30
<Rik`_>
MikeSmith: yeah you're right, other than testing people won't click twice
10:30
<gsnedders>
eighty4: lunch soonish?
10:31
<eighty4>
gsnedders: yeah, I'm starting to get hungry. But if I eat to early I will get hungry again to soon
10:31
<Rik`>
but I see this message while downloading : "loading… loading…"
10:31
<Rik`>
MikeSmith: is it intended ?
10:31
<MikeSmith>
heh
10:31
<MikeSmith>
Rik`: no, that's a bug
10:31
<gsnedders>
eighty4: Have more meals! :)
10:31
<MikeSmith>
Rik`: that I will fix in a bit
10:33
<eighty4>
gsnedders: that wouldn't work. If I eat 11 I need food again around 17, but that's to early for my girlfriend to eat dinner. So I'd have to eat dinner at 19 as well. That just wouldn't work ><
10:35
<eighty4>
gsnedders: so what would you like to eat? Would a salad at fräcka frökens work?
10:36
<gsnedders>
eighty4: I'd rather something bigger
10:36
<eighty4>
pizza at forno italia?
10:37
<gsnedders>
That works for me
10:39
<gsnedders>
eighty4: Meeting outside here at 11:55 work for you?
10:39
<gsnedders>
(or 12?)
10:40
<eighty4>
11.55 works good. Or I could just go right now
10:40
<gsnedders>
Okay
10:41
<eighty4>
try to get to forno 2 minutes earlier then everybody else
10:41
<eighty4>
*me leaves*
10:49
<MikeSmith>
Rik`: fixed the loading… loading… loading… thing
10:50
<MikeSmith>
thanks for the feedback and checking, btw
10:51
<micheil>
hmm.. anyone know who that Shelby Moore on the hybi mailing list represents?
10:52
<annevk5>
it's some kind of troll
10:55
<Philip`>
Is it trolling if you don't recognise or accept that that's what you're doing?
10:56
<micheil>
I believe so.
10:57
<Philip`>
micheil: Have you seen http://www.glazman.org/weblog/newarchive/2003_01_05_glazblogarc.html#s87008479 for relevant background information?
11:01
<jgraham>
micheil: http://ln.hixie.ch/?start=1041735552&count=1
11:36
<micheil>
Philip`, jgraham: do you think it'd be allowed to be mandated that for each protocol extension that a person / group wishes to have, that they show code for the implementation and provide documentation as to how it follows the original intent and goals of the websocket protocol?
11:37
<micheil>
like, not just psuedo code, but actual code showing how much complexity it would add to the parsing of the packets, etc.
11:37
<Philip`>
Has anyone agreed to follow the original intent and goals, or even agreed on what the intent and goals are?
11:39
<micheil>
I always thought that they were to create a simple bi-directional communication channel for which browsers could communicate with servers and servers could communicate with browsers in an asynchronous way.
11:40
<jgraham>
micheil: What do you mean "protocol extension"?
11:41
<micheil>
as in, anything added to the framing, handshaking or otherwise that isn't absolutely necessary for the communication of plain data
11:41
<micheil>
for instance, you message format, as simple as it may seem could be as simple as:
11:41
<micheil>
[frame-type][frame-length][frame-data]
11:42
<micheil>
frame-type being something like the flags currently defined
11:42
<jgraham>
Right, I think it is reasonable to ask people to show the code for cases where they want complexity. And people have been doing that
11:43
<micheil>
frame-length being the 7bits or what ever we're currently at
11:43
<micheil>
jgraham: so far I haven't seen much code
11:43
<micheil>
I've seen outlines of the packet format, but no implementations of it
11:44
<micheil>
(I'm not too sure I'm even reading the outlines of the packet format correctly)
11:45
<micheil>
bbl.
11:45
<jgraham>
micheil: There was one recent message with code
11:45
<jgraham>
and someone pointed out that it assumed a particularly simple case
11:45
<jgraham>
so there is evidence that code focuses the discussion somewhat
12:21
<annevk5>
http://twitter.com/kangax/status/21506116839 hmm
12:22
<annevk5>
I guess they are not doing that in quirks mode...
15:51
<MikeSmith>
goddammit
15:51
<MikeSmith>
is there a way to have mercurial use actual pathnames in diffs
15:51
<MikeSmith>
instead of whatever this a/ b/ shit
15:52
<MikeSmith>
jesus
15:52
<MikeSmith>
I want to meet the jackass who came up with that
15:52
<Philip`>
Why do you want that?
15:53
<Philip`>
If you're passing it to patch you can just add '-p1' or whatever to strip it off
15:54
<MikeSmith>
I'm really the diff from one level above the directory where the .hg subdir is
15:54
<davidhund>
tidy
15:54
<davidhund>
erm, oops
15:54
<MikeSmith>
and I do hg diff anolis/
15:55
<MikeSmith>
and I get a diff with: +++ b/anolislib/processes/terms.py Fri Aug 20 00:00:23 2010 +0900
15:55
<MikeSmith>
if I do -p1, I will just get +++ anolislib/processes/terms.py Fri Aug 20 00:00:23 2010
15:55
<MikeSmith>
right?
15:56
<Philip`>
Yes (I think)
15:57
<Philip`>
patch -p1 -d anolis < example.diff
15:57
<Philip`>
might do something useful
15:57
<Philip`>
(or might not)
15:57
<MikeSmith>
ok
15:57
<MikeSmith>
will try
17:13
<MikeSmithX>
http://www.w3.org/Public/Bugs seems to be down
17:13
<MikeSmithX>
hopefully not for long
17:13
<gsnedders>
MikeSmithX: Plz fix. Kthxbai.
17:13
<MikeSmithX>
heh
17:14
<MikeSmithX>
I've already pinged systems team
17:15
<jgraham>
MikeSmithX: Did you try M-x butterfly?
17:16
<MikeSmithX>
jgraham: will try it if I can do it in Vim…
17:17
<gsnedders>
Also: The Birthday Massacre are awesome.
17:18
<MikeSmith>
gsnedders: I wish you luck finding musical playpals
17:18
<MikeSmith>
most of my friends dislike most of the music I like
17:18
<MikeSmith>
so the only appropriate reaction is, too bad
17:18
<MikeSmith>
friends have their pros and cons
17:19
<gsnedders>
A managed to not get murdered for putting on metalcore with friend round yesterday. I guess I'm lucky.
17:19
<jgraham>
Evidence that metal is just silly item #55467 The stupid number of sub-genres
17:19
<MikeSmith>
but it would help if you weren't so keen on Christian Metalic Emo Noise Rock
17:20
<jgraham>
MikeSmith: What? I thought he was into Christian Metalic Emo Rock Noise!
17:20
<MikeSmith>
no, gsnedders hates that stuff
17:20
<MikeSmith>
gsnedders: what's wrong with just listening to. e.g. Belle and Sebastian?
17:21
<MikeSmith>
girls love that stuff
17:21
<jgraham>
Well he would, if he's into Christian Metalic Emo Noise Rock
17:21
<gsnedders>
MikeSmith: More variety needed.
17:21
<MikeSmith>
I mean it's a great way to impress girls with your sensitivity
17:21
jgraham
confirms this works :)
17:21
<gsnedders>
I think ending up curled up in their arms in tears shows sensitivity too.
17:23
<vals_>
it also gets you closer to their interesting parts
17:23
<vals_>
but anyway. does anybody know why the talk about which kind of pizza to eat is marked as "important lines" in the logs?
17:24
<gsnedders>
Because someone marked it as important.
17:24
<gsnedders>
Probably someone hungry.
17:24
<vals_>
8-D
17:26
<gsnedders>
Also: girls' "interesting parts" are overrated.
17:26
<paul_irish>
o.O
17:27
<vals_>
I guess that depends on your taste
17:28
gsnedders
has been pretty much asexual for the majority of this year
17:28
<pesla>
:o
17:29
<AryehGregor>
. . .
17:29
<gsnedders>
(and more or less aromantic as well)
17:29
<pesla>
Will the real gsnedders please stand up?
17:30
<vals_>
I've been aromatic for the majority of this summer
17:30
<vals_>
too frigging hot
17:30
<gsnedders>
*aromantic
17:30
<gsnedders>
No, I did spell it correctly.
17:31
<vals_>
anyway, I have an actual questio about the new web standard, and specifically the relation between hN and sections
17:31
<gsnedders>
Damnit, confusing me!
17:31
<vals_>
yeah, you spelled it correctly 8-D
17:31
<gsnedders>
hmm, I should probably get the outliner back up
17:31
<vals_>
(outliner?)
17:31
<gsnedders>
http://gsnedders.html5.org/outliner/
17:32
<gsnedders>
Oh, it's working again
17:32
<gsnedders>
That makes it simpler
17:33
<vals_>
so, the question is the following: h1, h2, ... h6 represent headings of (implied) sections, with the relative rank being useful to determine whether a new section starts or just a subsection starts
17:33
<vals_>
is that correct so far?
17:33
<AryehGregor>
If you use them that way, yes. The other acceptable thing is to just use <h1> for everything.
17:34
<gsnedders>
with hn, n is meaningless within section
17:34
<gsnedders>
outwith of section, n is used to determine whether a new section or subsection starts
17:34
<vals_>
that's exactly what I wanted to get to. so if I do my sectioning explicitly for each heading, it doesn't really matter what section level I use, right?
17:34
<gsnedders>
right.
17:35
<vals_>
now, if I was using CSS for styling, one of the advantages of using different hN is that styling would be automatic, more or less
17:35
<annevk5>
MikeSmith, isn't it at http://www.w3.org/Bugs/
17:36
<MikeSmith>
annevk5: yeah
17:36
<MikeSmith>
just typoed it
17:36
<MikeSmith>
anyway, I think it's back up now
17:36
<vals_>
if I only use h1 and do the sectioning manually, I have to do something to say "style this way every h1 that happens under exactly N sections"
17:36
<MikeSmith>
I think the mysql server was stopped and restarted
17:36
<vals_>
(more or less)
17:37
<gsnedders>
vals_: yeah
17:40
<vals_>
that's going to be a little painful 8-P
17:43
<AryehGregor>
That's part of why :any() is proposed.
17:44
<vals_>
yes, :any() would help a lot, and not just in this case
17:56
<jeromegn>
hey guys
17:57
<jeromegn>
is there an easy way to reconnect a websocket when it's closed?
17:57
<jeromegn>
I'm guessing I have to manually implement that in my app...
18:02
<eighty4>
gsnedders: aroudn?
18:02
<eighty4>
*around
18:03
<eighty4>
gsnedders: I've found you a FF bug that Opera handles as it should (IMO at least :))
18:53
<MikeSmith>
Philip`: btw, hg diff seems to have neither a -p nor -d option
18:53
<MikeSmith>
so its name is not wholly accurate
18:53
<gsnedders>
MikeSmith: They're optons on patch
18:53
<MikeSmith>
maybe it should be call hg deficient-diff
18:53
<Philip`>
diff doesn't have those options either
18:54
<MikeSmith>
or maybe hg not-quite-as-deficient-as-the-diff-in-svn-diff
18:54
<Philip`>
(at least not any with those effects)
18:54
MikeSmith
scrolls back to read what Philip` said
18:54
<MikeSmith>
ah
18:54
<gsnedders>
MikeSmith: patch.
18:54
<Hixie>
i wonder how all these formal objections will be handled
18:54
<MikeSmith>
hai hai hai
18:54
<MikeSmith>
gsnedders, Philip` - I was just testing you guys
18:54
<MikeSmith>
so, congrats in passing the test
18:55
<MikeSmith>
Hixie: http://www.w3.org/html/wg/wiki/FormalObjection
18:56
<Hixie>
i mean whether tim is going to do anything with them
18:56
payman
is away:
18:57
<Hixie>
(cos there's a number of things i don't particularly like the decisions of, and if tim is going to actually revert any of the decisions, it seems like it'd be worth giving it a shot)
18:58
<MikeSmith>
Hixie: yeah, I imagine that same thought is crossing a few other people's minds
18:58
<gsnedders>
It seems like overruling a WG decision would piss off a load of people, probably more so than the people already pissed off enough to be raising it
18:59
<gsnedders>
So, uh, I'd doubt it.
18:59
<TabAtkins>
Which is why, of course, most FOs just get stamped with a "Thanks for raising, move along now.", as far as I know.
18:59
<gsnedders>
TabAtkins: indeed
19:00
<Hixie>
well i've only been on one transition call, which had an FO discussed, and while I don't think Tim had any idea what the objection was about, I will give him ample credit for apparently giving it quite a fair hearing
19:00
<Hixie>
(to be fair it was an XBL2 issue so it's not clear anyone actually understood the issue)
19:00
<TabAtkins>
So no, Hixie, I don't expect anything to happen with the FOs, and I don't think it would be useful to raise any yourself, unless the WG does something *really* stupid.
19:03
<MikeSmith>
TabAtkins: I don't recommend acting on the assumption that nothing with happen with the formal objections
19:05
<MikeSmith>
and for any given decision the WG had made, I reckon I can find someone who thinks it is really stupid
19:05
<TabAtkins>
Oh, MikeSmith, while you're here: Who do I talk to to see if there's anything weird going on with w3's mailing systems that would cause someone to get spammed with over a thousand copies of one of my emails to the CSSWG over the past 2 months?
19:06
<MikeSmith>
TabAtkins: I recommend going on #sysreq on irc.w3.org
19:06
<MikeSmith>
and getting attention of the systems team
19:06
<MikeSmith>
and trying to get a response in real time
19:06
<TabAtkins>
kk
19:07
<MikeSmith>
if the person who received the messages can forward them, with the headers
19:07
<MikeSmith>
that would of course be a huge help
19:49
<annevk5>
sigh -- http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202
19:49
<annevk5>
I should have advocated more strongly for a codecs attribute of some sorts
19:49
<annevk5>
any type of media type parsing that involves parameters always gets ugly
20:31
<jgraham>
annevk5: Does 12 opcodes seem like enough?
20:32
<jgraham>
It feels like you could quite quickly be adding opcodes that mean "there are more opcodes"
20:34
<jgraham>
Also, I am increasingly worried about the complete message length stuff. There are lots of SHOULDs and MAYs floating around which I expect to cause interoperability problems
20:35
<jgraham>
I expect some servers will break with fragmented messages unless clients fragment from the start (e.g. simple servers that only deal with text)
20:39
<annevk5>
not sure
20:40
<annevk5>
i suspect you want something for video
20:40
<annevk5>
maybe json
20:40
<annevk5>
can't really think of much else
20:41
<annevk5>
of course, famous last words and all :)
20:47
<llrcombs>
hmmm
20:47
<llrcombs>
y'know, a copy/paste API would be great
20:48
<annevk5>
spec it
20:48
<vals_>
hm is it just me or it's imposttible to style list item numbers independently from the list item themselves without nesting a p in the li and resetting the style in the p?
20:49
<annevk5>
yeah, ::marker might solve that at some point
20:51
<llrcombs>
http://pastebin.com/tJMFxt2t
20:54
<annevk5>
llrcombs, not a spec :)
20:55
<MikeSmith>
content should be a list
20:55
<llrcombs>
so like a copybuffer?
20:55
<annevk5>
jgraham, so I expect clients to not use fragments
20:55
<MikeSmith>
so that you can have a history
20:55
<annevk5>
jgraham, but the magical intermediaries might fragment
20:55
<annevk5>
jgraham, but since the magical intermediaries are written much later
20:55
<llrcombs>
like with Jumpcut?
20:55
<annevk5>
jgraham, deploying them might be impossible if servers do not play ball
20:56
<MikeSmith>
hey, where's Simon?
20:56
<MikeSmith>
zcor..
20:56
<annevk5>
long break
20:56
<llrcombs>
so, now I'm pretty much directly cloning UndoManager
20:56
<llrcombs>
http://pastebin.com/XgZn9Tsi
20:57
<MikeSmith>
my completion on "zcor..." doesn't work
20:57
<MikeSmith>
due to lack of Simon presence
20:57
<MikeSmith>
I guess I have to wait til he gets back
21:07
<jgraham>
annevk5: Yeah the client doesn't fragment -> server doesn't support fragmentation properly -> intermediaries that fragment break applications to be a problem
21:07
<jgraham>
+ I expect
21:09
<annevk5>
yeah well
21:09
<annevk5>
these transcoding proxies always seem a bit of a myth
21:09
<annevk5>
but who knows
22:35
<AryehGregor>
"Going forward, I hope that the recommendations made after deliberation by the HTML A11y TF are taken more seriously by the wider group and not unilaterally dismissed."
22:36
<AryehGregor>
I can't see any way to read that other than "We should make the final decision on anything accessibility-related, not you."
22:36
<hober>
IIRC N-1 TF recommendations have gone over quite well in the wider WG
22:37
<Hixie>
clearly #whatwg should send a similar e-mail :-P
22:37
<AryehGregor>
Yeah, I was thinking of responding.
22:37
<AryehGregor>
I probably shouldn't.
22:38
<AryehGregor>
Stuff like: "The HTML5 A11y TF made the recommendation after much discussion and debate, onlist, off-list and via F2F. We are very aware of the pros and cons of @longdesc but decided that its retention was currently the best option."
22:38
<AryehGregor>
You could replace "HTML5 A11y TF" with "WHATWG", and "retention" by "removal".
22:38
<AryehGregor>
But it's not worth getting into an argument over. Won't accomplish anything.
22:39
<Hixie>
i strongly recommend letting them make fools of themselves and not doing the same for yourself
22:39
<AryehGregor>
I'm still waiting to see how the appeals turn out.
23:19
<Hixie>
TabAtkins: do you know who is responsible for the video codec selection part of chrome?
23:20
<Hixie>
e.g. what decides to use WebM vs Ogg vs H.264?
23:20
<Hixie>
roc: ping
23:20
<TabAtkins>
hixie: Scherkus, I'm told.
23:20
<Hixie>
any idea if he's on #chromium?
23:21
<Hixie>
scherkus: ah, he is
23:21
<Hixie>
er
23:21
<TabAtkins>
Ah, good. I wasn't about to go searching down that list of /who.
23:22
<Hixie>
i just typed "sch<tab>" :-)
23:22
<Hixie>
but i wasn't expecting him to use his name :-)
23:22
<TabAtkins>
That's only useful about 50% of the time...
23:23
<roc>
hi
23:25
<MikeSmith>
Hixie: you got roc back now too
23:27
<Hixie>
woohoo, roc's here too!
23:27
<Hixie>
roc: trying to work out what to do with <video> and content-type sniffing
23:27
<jgraham>
Party!
23:27
<jgraham>
Or maybe sleep
23:27
jgraham
goes with that
23:28
<Hixie>
roc: looks like we have five browsers and more or less five different implementations
23:28
<Hixie>
roc: what's your position on this topic?
23:28
<Hixie>
roc: http://hixie.ch/tests/adhoc/html/video/001.html and http://hixie.ch/tests/adhoc/html/video/NOTES may be of interest
23:35
<roc>
personally I get the feeling we've raced halfway down to the bottom of the slippery slope of the poisoned well
23:36
<roc>
and much as I hate to do it, we're likely to have to sniff, at least for <video> loads
23:36
<roc>
and there's a pretty strong argument that if you sniff for <video> loads, you should sniff the same for browsing context loads
23:37
<Hixie>
would you want to not even sniff for streams with missing content-types?
23:37
<roc>
otherwise stuff like a "View Video" context menu item breaks oddly
23:37
<roc>
I think sniffing for streams with no content-type is fine no matter what
23:38
<roc>
*however* I think the other video guys in the office are more keen to hold the non-sniffing line than I am
23:38
<Hixie>
what's the benefit of not sniffing when there is a type, given that these types are basically unambiguously sniffable? or are they not?
23:38
<roc>
but they're not here right now
23:38
<roc>
here's one
23:40
<roc>
Hixie: I don't know. It's possible that in some containers you have to read a lot of data to figure out what codecs are present, where that information can be given in the MIME type. Our experts in that area are in the process of joining us...
23:41
<Hixie>
oh you'd want to respect the codecs="" parameter even when it's wrong?
23:41
<Hixie>
or do you just mean to throw out the content early?
23:41
<roc>
the latter
23:42
<roc>
Hixie: I assume if we were to sniff, we'd still not even try to load resources whose <source type> is something we cannot render?
23:42
<Hixie>
i assume so
23:42
<Hixie>
there wouldn't be any point in the type="" attribute otherwise
23:42
<roc>
right
23:42
<Hixie>
haven't tested that though
23:43
<Hixie>
but that seems like a case that's much more unambiguously useful to honour
23:44
<Hixie>
right now firefox seems to look at the mime type to pick the codec, and refuses to render mislabelled content, but i haven't tested the codecs="" parameter
23:44
<Hixie>
s/codec/wrapper/
23:44
<roc>
yeah, we try not to be first in the race to the bottom :)
23:45
<Hixie>
(whatever you call the code that does that)
23:45
<roc>
but we don't want to be last either :-)
23:45
<Hixie>
hah
23:45
<kinetik>
Hixie: with Matroska (and WebM, since the WebM spec doesn't exclude this "feature"), you may have to read an arbitrary amount of ASCII at the start of the file before you can identify it as a valid Matroska file (see the first paragraph of http://matroska.org/technical/specs/notes.html)
23:45
<roc>
we should be honoring the codecs parameter correctly, we have code (and tests!) for that
23:46
<kinetik>
but I'm going to propose that the WebM spec is changed to exclude that feature
23:46
<Hixie>
roc: so if you supported codecs A and B, and a file used A but was labelled video/somethingsupported;codecs=B, you would not play it?
23:46
<Hixie>
kinetik: wow, that's lame
23:47
<Hixie>
kinetik: please indeed have them fix that!
23:47
<roc>
Hixie: that is correct, that's what we do
23:47
<roc>
or is it? hmm
23:47
roc
thinks
23:47
<roc>
no I guess it's not
23:47
<Hixie>
i guess you don't support enough codecs to actually test that
23:48
<Hixie>
or do you do the webm codec in ogg?
23:48
<Hixie>
i guess that'd be one way to test it?
23:48
<roc>
if the container type is mislabelled, we will reject even if both the label and the resource are something we support
23:48
<Hixie>
yes
23:48
<Hixie>
that i have indeed found
23:48
<roc>
but we don't check that the codecs we got in the resource are the ones advertised
23:48
<roc>
that would be pretty easy for us to do if we wanted to
23:50
<Hixie>
doesn't seem like either of these checks are especially useful to the author or user
23:51
<Hixie>
but they would definitely (if implemented everywhere) lead to mare accurately labeled content
23:52
<roc>
the brutal truth is that almost all the time, if it's done consistently and can be done unambiguously in a predictable way, sniffing is the most useful for authors and users
23:53
<Hixie>
i don't know that that's particularly brutal :-)
23:54
<roc>
it feels brutal to me :-)
23:54
<Hixie>
the consistency is the hard part
23:54
<roc>
yeah, those are big "ifs"
23:55
<roc>
Hixie: there's a small ease-of-implementation benefit for us the way we do things; we can set up the decoder based on the container label early in the load process, instead of having to buffer data, sniff it, construct the decoder, and feed the data back into it
23:55
<roc>
but clearly that benefit is low priority
23:55
<Hixie>
that's the container decoder right?
23:55
<roc>
yeah
23:56
<Hixie>
the chrome guy was telling me that one of his requirements is that the decoding happens out-of-process, and so he wants to just hand the bytes straight to that other process, and for some reason for them it's easier to just have that work without knowing the type
23:56
<roc>
the container formats contain authoritative metadata telling you what the codecs are
23:56
<roc>
we don't have to sniff again
23:56
<Hixie>
though he said he could add (what he called "artificial") checks for the type
23:56
<roc>
thankfully
23:58
<Hixie>
if we could limit how much you have to buffer, would that help?
23:59
<Hixie>
or is buffering any of the payload vs the headers a problem?