/irc-logs / freenode / #whatwg / 2007-03-23 / end

Options:

# Session Start: Fri Mar 23 00:00] 2007
# Session Ident: #whatwg
# [00:00] <tylerr> What's the context? For beginners?
# [00:00] <bewest> yeah, that is my pet peeve
# [00:00] <bewest> I hate that behaviour
# [00:00] <Lachy_> It should cover from beginner to advanced authors
# [00:01] <tylerr> Ah lovely.
# [00:01] <tylerr> Perhaps if this turns into a book for me, we'll suggest eachothers' work's in the intros. ;)
# [00:02] <tylerr> Too many apostrophes. :)
# [00:09] <tylerr> So here's an idea. Take each of the sections and have a use case that is comprised of steps, or levels of enhancement.
# [00:10] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
# [00:14] <tylerr> As an example, start with a <p>, give it enhancements with <em>/<strong>/etc. move on to breaking up quotes with <blockquote>, so on and so forth. All the while introducing each of these elements.
# [00:15] <Lachy_> yeah, but aren't you only writing about the new features in HTML5, not those that have been in HTML forever?
# [00:16] <Hixie> probably makes sense to treat them the same, if you're targetting newbies
# [00:17] <tylerr> It all depends on whom I'm targeting.
# [00:17] <tylerr> Which I haven't decided upon yet. :)
# [00:17] <zcorpan_> people reading the whatwg blog probably already know about html4, i'd think
# [00:18] <zcorpan_> as a start, i'd focus on new features that are implemented in some browser
# [00:18] <tylerr> Sure. Perhaps I'll start with the new items, particularly the ones already implemented, them move on from there.
# [00:18] <tylerr> So <canvas>, then move on from there. ;)
# [00:20] <zcorpan_> now we're talking ;)
# [00:20] <tylerr> Anyway, more tomorrow, as I'm off for the evening. Cheers everyone!
# [00:20] <zcorpan_> bye
# [00:20] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) ("Leaving")
# [00:23] * Quits: aroben (i=adamrobe@nat/apple/x-486cdeb77c4cb0c6) (Read error: 104 (Connection reset by peer))
# [00:24] * Joins: aroben (i=adamrobe@nat/apple/x-30016eb399fbee49)
# [00:25] * Joins: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
# [00:31] <Hixie> so
# [00:31] <Hixie> othermaciej: the <param> thing is great, but it poses an interesting design choice
# [00:31] <Hixie> othermaciej: should we say that the choice of which media resource to use is only made when you call .play() the first time (or after a .stop() call), and that dynamic changes to the document are otherwise ignored?
# [00:31] <othermaciej> Hixie: after talking to Darin, I don't think it should use the <param> element, seems wonky to reuse it with a whole separate set of attributes
# [00:32] <Hixie> well i don't mind what we call the element, <param> has the advantage of not requiring parser changes (legacy UAs would treat a new element as being an inline element, not just an empty one)
# [00:32] <Hixie> (IE notwithstanding)
# [00:32] <othermaciej> Hixie: my thought on how static fallback should work:
# [00:33] <othermaciej> 1) You first do it when you hit the video close tag
# [00:34] <Hixie> hrm, i'm trying to avoid things that depend on parsing the end tag. </script> is the only one that does that right now.
# [00:34] <Hixie> doing that makes a dichtomy between dynamic mutations and parsing
# [00:34] <Hixie> which is annoying to spec (puts knowledge of the element into the parser part of the spec)
# [00:35] * Quits: hendry (n=hendry@91.84.53.136) ("nn")
# [00:35] <Hixie> but we can do it on the invokation of play(), and say that that gets called automatically onload if autoplay is set
# [00:36] <othermaciej> Hixie: sorry, in meeting, I'll get back to this shortly (less than 30 min)
# [00:36] <Hixie> k
# [00:36] <Hixie> no worries
# [00:36] * Quits: KevinMarks (i=KevinMar@nat/google/x-6c317a0a2b9f1588) ("The computer fell asleep")
# [00:38] <Lachy_> Hixie, I don't understand what you mean by "the choice of which media resource to use is only made when you call .play() the first time"
# [00:39] <Lachy_> doesn't the UA need to choose choose the suitable format from those available and downlaod it before play() is invoked?
# [00:39] <Hixie> no, .play() is what starts the download in the current spec
# [00:39] <Lachy_> oh, did that change?
# [00:39] <Lachy_> maybe I just didn't read carefully enough
# [00:40] <Hixie> well the UA can precache before if it wants
# [00:40] <Hixie> but that isn't required
# [00:41] <Lachy_> ok, so that handles YouTybe's case where videos embedded on other sites don't begin downloading till the user requests, but UAs would need to provide an easy way to start downloading in the background before play)(
# [00:41] <Lachy_> play()
# [00:43] <Hixie> hm fair point
# [00:43] <Hixie> although
# [00:43] <Hixie> wouldn't that be just up to the UA
# [00:43] <Hixie> i mean, the author shouldn't have to say "download this, you might need it", surely, having a <video> there is enough to do that
# [00:43] <Hixie> brb
# [00:44] <Lachy_> yes, it would be up to the UA. Isn't that what I said?
# [00:44] * Parts: jsled (n=jsled@pdpc/supporter/silver/jsled) ("Leaving")
# [00:49] * Quits: hyatt (i=hyatt@nat/apple/x-925af53816529fd1)
# [00:49] <Hixie> oh
# [00:49] <Hixie> i guess i misunderstood "would need to provide an easy way"
# [00:50] <Lachy_> that sentence begun with "but UAs ...", and figuring out the "easy way" is up to their UI designers
# [00:55] <Hixie> i don't understand why there'd be any ui
# [00:55] <Hixie> wouldn't browsers just do it?
# [00:56] <Hixie> though i guess if we do do this we _should_ send events so that the author-driven ui can update too
# [00:56] * Joins: hyatt (i=hyatt@nat/apple/x-02f9a0c4f11c049a)
# [00:57] <othermaciej> Hixie: will have much to say on this once I am out of my meeting, topic is too complex to discuss in background to this meeting
# [00:58] <Hixie> sure
# [00:58] * Hixie is playing while he waits :-D
# [01:01] <bewest> Hixie: how many documents do you have that contain a classname containing "vcard" somewhere in the document?
# [01:01] <Hixie> haven't done a classname survey for many months
# [01:01] <Hixie> when i did it it wasn't many
# [01:01] <Hixie> but that was at least 6 months ago now
# [01:02] * bewest nods
# [01:02] <bewest> what is the rough range of not many?
# [01:03] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
# [01:03] <Lachy_> Hixie, it depends. In some cases it makes sense to immediately start downloading and buffering the video, in others it doesn't.
# [01:04] <Lachy_> e.g. when on YouTube, I like to open new videos in background tabs and have them load while I'm watching another, but if I just happen to come across a blog with a video in it, I'd like to decide whether or not I want to download it first
# [01:04] <Hixie> bewest: not in the top 1000 class names. less common than class="srchbox_keywords_div" or class="affiliates_wrapper" or class="ex_hdr_cell"
# [01:04] <bewest> hmmm that's interesting
# [01:04] * bewest looks for himself
# [01:04] <Hixie> Lachy_: hm, fair enough. not sure how to tell the difference, but yeah, that would be a ui thing.
# [01:04] <zcorpan_> Lachy_: the one on youtube in a background tab would have autoplay=""
# [01:05] <zcorpan_> the blog with video in it wouldn't
# [01:05] <Hixie> you'd hope
# [01:05] <Lachy_> possibly, but I wouldn't want the video to actually play until I swtich to that tab. I guess that's also up to the UA, since that's Safari's behaviour
# [01:06] <Hixie> does safari even buffer?
# [01:06] <bewest> do authors copy/paste those from somewhere?
# [01:06] <Lachy_> not sure, I only know what othermaciej told me a few days ago
# [01:07] <Lachy_> I haven't tested it out yet
# [01:10] * Parts: hyatt (i=hyatt@nat/apple/x-02f9a0c4f11c049a)
# [01:19] <zcorpan_> http://simon.html5.org/temp/valid-html5.png
# [01:20] <Hixie> hahahahaha
# [01:20] <Hixie> i love it
# [01:21] <zcorpan_> :)
# [01:23] <othermaciej> Hixie: ok, I'm out of my meeting
# [01:23] <Hixie> cool
# [01:23] <Hixie> so
# [01:23] <Hixie> you started saying something before
# [01:23] <othermaciej> Hixie: I don't think downloading starting on play() is right, so maybe we should step back and discuss that
# [01:23] <Hixie> let's work out where to put the urls first
# [01:24] <Hixie> since i'm half way through a patch to the spec to do that
# [01:24] <Hixie> and i'd have to undo my changes to change something else first
# [01:24] <othermaciej> ok
# [01:24] <othermaciej> well, I think that affects when you want the fallback algorithm to apply
# [01:24] <Hixie> yes, i agree
# [01:25] <Hixie> wait, there are two "fallback mechanisms" here
# [01:25] <Hixie> there's the content-negotiation "pick the right video" case, and the "my UA doesn't support <video>" case
# [01:25] <othermaciej> which two do you have in mind?
# [01:25] <othermaciej> ok, agreed
# [01:26] <Hixie> i would argue that for the former you just want a list of URIs and metadata (MIME type with RFC4281, eg)
# [01:26] <othermaciej> yes
# [01:26] <Hixie> and for the second you want arbitrary markup, which is never shown in <video>-supporting UAs
# [01:26] <othermaciej> even if the last chance media source is unsupported?
# [01:27] <Hixie> i think if none of the codecs are supported, the better result is for the UA to display UI to the effect of "codec not supported, download more here"
# [01:27] <Hixie> (maybe automatically doing so)
# [01:28] <othermaciej> it's possible <object> would support codecs that are not natively supported
# [01:28] <othermaciej> I can see arguments either way
# [01:28] <othermaciej> would rather not debate it now
# [01:28] <othermaciej> I think your proposal is fine
# [01:29] <othermaciej> list for content negotiation, alternate content only for non-<video> UAs
# [01:29] <Hixie> so my straw man for how to give the UA the list and alternate content would be <video> (list goes here) (legacy ua content goes here) </video>
# [01:29] <Hixie> with the list being a series of elements with src/type attributes
# [01:30] <Hixie> tentatively <param> since it already works and is a void element (no end tag) in all UAs
# [01:30] <othermaciej> can you also specify src/type on <video> itself?
# [01:30] <othermaciej> if so, what if you specify both that and <param>s?
# [01:31] <Hixie> i would only have one
# [01:31] <Hixie> on the principle of simplicity
# [01:31] <Hixie> though i agree it's weird
# [01:32] <othermaciej> if it weren't for the <param> is already void issue, I would suggest having a new element called <alt>
# [01:32] <Hixie> agreed
# [01:32] <othermaciej> and allow src/type on <video> and have that be the first one considered
# [01:32] <zcorpan_> oh, no, that's too confusing with alt tags, er, i mean alt attributes :P
# [01:32] <othermaciej> so the non-fallback case is still simple
# [01:32] <Hixie> though i dunno what i'd like, namewise
# [01:33] <Hixie> well even with <param> we could do that
# [01:33] <Hixie> but it looks a bit weird
# [01:33] <Hixie> <video src=a type=a> <param src=b type=b> <param src=c type=c> ... </video>
# [01:34] * Joins: KevinMarks (i=KevinMar@nat/google/x-21db9c60e93dc783)
# [01:34] <othermaciej> yeah, that's why I suggested <alt>, cause then it's clear that it is an alternate source
# [01:35] <othermaciej> not sure what would happen in existing UAs if it appeared as an unclosed element
# [01:35] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [01:35] <othermaciej> or you could be lame and require a close tag even though there can't be content
# [01:36] <zcorpan_> it wouldn't mess up existing uas, i think. in ie it would be an empty element, and other browsers would close them at </video>
# [01:36] <Hixie> well it's not really an <alt>, though, right, i mean it's equally important as the first one
# [01:36] <Hixie> it's just the ua will pick the best one, or something
# [01:37] <zcorpan_> <negotiate>
# [01:37] <othermaciej> well, there's an ordering
# [01:37] <othermaciej> so there is in fact a priority order
# [01:37] <Hixie> oh, ok
# [01:42] <othermaciej> or rather, I think the algorithm should pick the first one that it supports
# [01:43] <othermaciej> I suppose another design would have the UI somehow evaluate quality, not just binary yes/no
# [01:43] <othermaciej> but I think that is harder to deal with for both UAs and authors
# [01:49] <Hixie> hang on mtg of my own now
# [01:49] <othermaciej> ok
# [01:54] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [01:56] <Hixie> ok back
# [01:56] <Hixie> i guess we can have src/type on video and on child elements
# [01:56] <Hixie> but it feels a little weird to me
# [01:56] <Hixie> kind of assymetric
# [01:58] <othermaciej> Agreed, but it would be nice not to make the no-fallback case more complex
# [01:58] <Hixie> yeah..
# [01:58] <Hixie> <video><param src=""></video>
# [01:58] <Hixie> it's not that much more complex i guess
# [01:59] <Hixie> or maybe we can make it be one or the other
# [01:59] <Hixie> if there's a src, ignore children
# [01:59] <Hixie> if there isn't, only use children
# [01:59] <Hixie> and not have a type="" on the <Video> element itself
# [02:01] <othermaciej> it's hard for me to have a strong opinion on these particular details
# [02:01] <othermaciej> I would like both single-source and multi-source cases to be nice syntactically
# [02:01] <Hixie> ok well i'll just go with that last suggestion then
# [02:01] <Hixie> what was the argument against using <param>?
# [02:02] <othermaciej> is using an already-void element really a big advantage here, btw?
# [02:02] <othermaciej> is there any UA where </video> wouldn't close random open unknown elements?
# [02:02] <Hixie> well it's not a huge advantage, it's just neat. It also avoids the need to invent yet another element.
# [02:02] <Hixie> every element we use here is one less name we can use elsewhere when we really need it
# [02:03] <othermaciej> sure, but one element that you use with completely orthogonal sets of attributes in different situations is not much of a simplification
# [02:03] <othermaciej> and makes validators either more complicated or less effective
# [02:04] <Hixie> this is probably a one-line change in a decently architected conformance checker
# [02:04] <Hixie> it only complicates matters if someone tries to document the element itself, as opposed to <object> and <video>
# [02:04] <Hixie> hm
# [02:04] <Hixie> what could we call it if not <param>...
# [02:04] <Hixie> <source>, maybe
# [02:04] <othermaciej> <source> is good
# [02:04] <Hixie> <video> <source src="" type=""> <source src="" type=""> <p>You need Safari 3.</p> </video>
# [02:06] <othermaciej> <source src> is a bit awkward, but better than alternatives I guess
# [02:06] <othermaciej> the other prior art would be <source data> or <source href> and both of those seem worse
# [02:06] <Hixie> yeah
# [02:07] <Hixie> personally i prefer <param src="" type=""> but <source> is fine too. i'm speccing <source> for now, we can see what people say.
# [02:07] <zcorpan_> i'd vote for <param> over <source>
# [02:07] <zcorpan_> fwiw
# [02:09] <othermaciej> it would seem weird to me if <param value name> and <param src type> were the same element but had completely different semantics, behavior, allowed attributes and contexts where they are valid
# [02:11] <Hixie> i'd consider them different elements :-)
# [02:11] <Hixie> just that happen to have the same name :-)
# [02:12] <othermaciej> would the HTMLParamElement interface also include both sets of attributes?
# [02:13] * Joins: welly (n=welly@62-31-59-92.cable.ubr12.azte.blueyonder.co.uk)
# [02:13] <Hixie> sure
# [02:13] <Hixie> on <source>, should the type="" attribute require a codec="" parameter?
# [02:13] <othermaciej> Some audio/video types may already imply a codec
# [02:14] <Hixie> k
# [02:14] <Hixie> so optional but mentioned
# [02:15] <othermaciej> <param> already has a type attribute BTW
# [02:15] <Hixie> not in HTML5
# [02:15] <Hixie> but yeah
# [02:15] <Hixie> in HTML4 it did
# [02:15] <othermaciej> I guess no one uses that?
# [02:16] <Hixie> i couldn't work out what it was supposed to do and nobody could tell me
# [02:16] <Hixie> so i dropped it
# [02:16] <Hixie> :-)
# [02:16] <Hixie> much like <meta scheme>
# [02:16] <Hixie> and many others
# [02:17] * Quits: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
# [02:18] <Lachy_> hmm. I was expecting you to use <param name="src" value="">
# [02:18] <Lachy_> embedding flash in IE uses <param name="movie" value="flash.swf">
# [02:18] <Hixie> the name="src" would be redundant and UAs would end up ignoring it
# [02:19] <Lachy_> so this param is only ever going to be used for specifying alternate sources?
# [02:19] <Hixie> it's <source> right now
# [02:19] <Hixie> but for now, yes
# [02:19] <Hixie> extensibility doesn't work when you only have one value, because people end up ignoring it
# [02:19] <Hixie> look at, e.g., <style>'s type="" attribute
# [02:20] * Quits: smfr (i=smfr@nat/apple/x-0d9ff0a5c8762b50)
# [02:21] <Lachy_> I thought it might have been useful for extensibility, so that instead of adding new attributes to <video> for every new feature in the future, we could just use <param name value>
# [02:22] <othermaciej> better yet, we could do that for all elements, and deprecate attributes entirely
# [02:22] <othermaciej> </reductio>
# [02:22] <Lachy_> :-)
# [02:23] <Lachy_> I'm not particularly thrilled with <source src>. The name seems a little redundant, and could cause confusion for some about which spelling of source/src to use
# [02:23] <Hixie> that's what xhtml2 has done
# [02:23] <Hixie> (seriously)
# [02:24] * Joins: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
# [02:24] <Lachy_> really? I thought XHTMl2 <param> was only for object
# [02:24] <Hixie> well they use <meta>
# [02:24] <Lachy_> oh, they have done that with <meta> thought
# [02:25] <Hixie> but <element><meta name="foo">bar</meta></element> is supposedly exactly equivalent to <element foo="bar"/> in XHTML2
# [02:25] <Lachy_> where is that specified? ;-)
# [02:25] <Hixie> hah
# [02:25] <Hixie> i asked steven that in person once
# [02:25] <Hixie> he told me it wasn't required
# [02:26] <zcorpan_> it's undefined, like everything else ;)
# [02:26] <Hixie> i never got him to explain why the spec says about that <title> example that the two are equivalent, if they're not as he claimed to me in person
# [02:26] <Lachy_> I never got a response to my questions about the equivalence of <title>/<meta name="title'>
# [02:26] <Hixie> go figure
# [02:29] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [02:29] * moeffju is now known as moeffju[ZzZz]
# [02:29] <othermaciej> Lachy_: maybe if you were more aligned you would understand
# [02:30] <Lachy_> understand what?
# [02:30] <othermaciej> the equivalent of <title>/<meta name="title">
# [02:31] <othermaciej> I'm kind of being facetious here
# [02:31] <Hixie> i still don't get why we would want to _not_ look at concrete technical issues
# [02:32] <Hixie> but instead pontificate on "interesting" questions
# [02:33] * Joins: karlUshi (n=karl@dhcp-246-23.mag.keio.ac.jp)
# [02:34] <othermaciej> well apparently if you do that, you get XHTML2
# [02:39] * Quits: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [02:40] * Quits: othermaciej (i=mjs@nat/apple/x-aa79843db911419c)
# [02:40] * Quits: sayrer (n=chatzill@user-10876hc.cable.mindspring.com) ("Chatzilla 0.9.73-rdmsoft [XULRunner 1.8.0.4/2006050908]")
# [02:42] <Hixie> what should the method that does the conneg without doing the play() be called? open() or load() ?
# [02:42] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [02:47] * Joins: othermaciej (i=mjs@nat/apple/x-7d65e1cbf5248316)
# [02:47] * Quits: bzed (n=bzed@dslb-084-059-105-208.pools.arcor-ip.net) ("Leaving")
# [02:49] * Quits: othermaciej (i=mjs@nat/apple/x-7d65e1cbf5248316) (Client Quit)
# [02:50] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
# [02:50] <Dashiva> Hixie: buffer? preload? Among the two you suggested, I'd take load
# [02:52] <Dashiva> Or do you mean only a basic HEAD to get the parameters, no content download involved?
# [02:52] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [02:52] <Hixie> preload() i guess could work too
# [02:52] <Hixie> though i prefer load(), i think
# === Backup from Lachy: ===
# [12:57] * billmason (n=billmaso@c-71-236-194-106.hsd1.or.comcast.net) has joined #whatwg
# [13:03] * csarven- has quit (Read error: 110 (Connection timed out))
# [13:04] * MikeSmith has quit ("Get thee behind me, satan.")
# [13:08] * tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) has joined #whatwg
# [13:08] * mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) has joined #whatwg
# [13:09] * mw22____________ is now known as mw22
# [13:09] * h3h_ (n=w3rd@cpe-70-95-237-98.san.res.rr.com) has joined #whatwg
# [13:12] * h3h_ is now known as h3h
# [13:12] * welly has quit ()
# [13:13] * welly (n=welly@62-31-59-92.cable.ubr12.azte.blueyonder.co.uk) has joined #whatwg
# [13:17] * zcorpan_ has quit (Read error: 60 (Operation timed out))
# [13:22] * yod (n=ot@softbank221018155222.bbtec.net) has joined #whatwg
# [13:35] * h3h has quit ()
# [13:56] * welly has quit (Read error: 60 (Operation timed out))
# [14:01] * tantek has quit (Read error: 104 (Connection reset by peer))
# [14:01] * tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) has joined #whatwg
# [14:02] * ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) has joined #WHATWG
# [14:03] * ericcarlson has quit (Remote closed the connection)
# [14:03] * ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) has joined #WHATWG
# [14:10] * krijnh has quit (Read error: 110 (Connection timed out))
# [14:11] * tantek has quit (Read error: 104 (Connection reset by peer))
# [14:12] * tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) has joined #whatwg
# [14:14] * mpt (n=mpt@121-72-132-150.dsl.telstraclear.net) has joined #whatwg
# [14:18] <Hixie> anyone know what "apply sort field" does on a selection in iTunes?
# [14:28] <billmason> If you have data in one of the "sort" fields on that selection, you can apply that data to songs that match whatever "same-whatever" you choose. Or something like that.
# [14:28] <billmason> http://blech.vox.com/library/post/sort-fields-in-itunes-71.html is a better explanation
# [14:29] * Hixie reads, hoping it explains it
# [14:30] <billmason> It has to be more coherent than my ramblings. :)
# [14:30] <billmason> I don't use it much. The UI doesn't help to discover it.
# [14:36] <Hixie> wow, yeah, that explained it
# [14:36] <Hixie> cool
# [14:36] <Hixie> thanks
# [14:36] <Hixie> glad that it was just added and i hadn't missed it for ages
# [14:39] <billmason> you're welcome
# [14:51] <Hixie> hm
# [14:51] <Hixie> i just realised
# [14:51] <Hixie> that in the html5 spec we haven't defined how <script> actually works in XML
# [14:51] <Hixie> since it's defined to execute when inserted
# [14:51] <Hixie> and the html5 parser is careful not to insert until the script has been appended
# [14:52] * marcosc has quit (Read error: 104 (Connection reset by peer))
# [14:52] <Hixie> but that wouldn't work for an xml parser
# [14:53] * dhyatt (n=hyatt@c-24-6-91-161.hsd1.ca.comcast.net) has joined #whatwg
# [15:17] * othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) has joined #whatwg
# [15:18] <othermaciej> good evening
# [15:21] * csarven has quit ()
# [15:21] * zcorpan_ (n=zcorpan@esk-ba-1-nomad.net.mdh.se) has joined #whatwg
# [15:23] * csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) has joined #whatwg
# [15:25] * mpt has quit ("This computer has gone to sleep")
# [15:27] * sayrer (n=chatzill@user-12ld2ss.cable.mindspring.com) has joined #whatwg
# [15:30] <Hixie> so othermaciej, if we say that something happens when you parse the </video> tag in HTML5, that still doesn't solve the XML problem
# [15:31] <othermaciej> Hixie: I don't think we should say that, on further thought
# [15:32] * jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) has joined #whatwg
# [15:32] * karlUshi wonders if the ordering in iTunes follows the hiragana japanese ordering.
# [15:33] <Hixie> so then the problem is what do we wait for to trigger downloads? the 'load' event on body?
# [15:34] * htmlr has quit ()
# [15:50] * mpt (n=mpt@121-72-132-150.dsl.telstraclear.net) has joined #whatwg
# [15:53] <Lachy_> I don't understand the XML problem regarding the downloading of <video> content
# [15:54] * htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au) has joined #whatwg
# [15:56] <Hixie> same as the <script> problem
# [15:59] <Lachy_> yeah, I don't understand that one either
# [15:59] <Hixie> so <script> is defined to execute when it's inserted into the document
# [15:59] <Lachy_> why is it a problem? Why can't you just specify that the script executes as soon as the script element is finished
# [15:59] * sayrer thanks Hixie for his rude email
# [16:00] <othermaciej> Hixie: anyway, back to </video>
# [16:00] <othermaciej> here's my proposed rules for fallback
# [16:00] <othermaciej> 1) at parse time, you process the <source> elements one at a time, the first successful one becomes the content source
# [16:01] <othermaciej> 2) if you change the contents of <video> in a way that would change which is the first <source> that's successful, redo the fallback algorithm
# [16:01] <othermaciej> (either change which is first, or change what URL it points to)
# [16:01] <Hixie> Lachy_: well, there are two options i see: do it on insertion and have the html parser delay insertion until it's filled the child nodes (the script) -- this doesn't handle xml -- or, have different rules for xml, html, and dynamically created elements
# [16:02] <othermaciej> the specific changes that would trigger #2 include changing type on the first successful <source> or one before it, removing the first successful <source> or one before it, or inserting a <source> before the first successful one
# [16:02] <othermaciej> but you don't have to limit it
# [16:02] <othermaciej> can just say that if the same URL ends up being the final src don't make any changes
# [16:02] <Hixie> othermaciej: i really don't want to have to rerun the algorithm every time you change the DOM. You'd end up firing dozens of HTTP requests only to cancel them.
# [16:02] <sayrer> option 3: don't specify it because it doesn't work
# [16:02] <Hixie> othermaciej: and doing things when the DOM changes is a source of constant bugs
# [16:02] <othermaciej> I don't think you would fire a lot of HTTP requests
# [16:02] <othermaciej> in the common parsing case, exactly one
# [16:03] <othermaciej> or zero if no <source> elements have a good type
# [16:03] <Hixie> othermaciej: i mean in the DOM manipulation case
# [16:03] <Hixie> e.g. if i am moving <source>s about
# [16:03] <Hixie> in a DOM inspector or something
# [16:03] <othermaciej> yes, well, you don't necessarily have to start the load until the particular script in question is done
# [16:03] <Hixie> i'd much rather have an explicit "look at the elements and start the load" step.
# [16:04] <Hixie> we can certainly run that algorithm every time you add a <source> element
# [16:04] <othermaciej> hmm
# [16:04] * h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com) has joined #whatwg
# [16:04] <othermaciej> usually rendering reacts to DOM changes without the need to make an explicit call
# [16:04] <Hixie> which would work fine for load time
# [16:04] <Hixie> yeah but this isn't just rendering
# [16:04] <Hixie> i mean, it would interrupt active playback and everything
# [16:04] <Hixie> and it's a very rare edge case we're talking about
# [16:04] <Hixie> so it's extra complexity that isn't worth it
# [16:05] <Hixie> sayrer: regarding the e-mails, apologies if it sounded rude, it wasn't meant that way. your reply seems to be missing a verb in the first sentence which is preventing me from understanding what you mean.
# [16:05] <othermaciej> haven't thought that deeply about the dynamic case, but I usually prefer things where the state of the document is reflected in the rendering regardless of how you got there
# [16:05] <sayrer> Hixie: yeah, I skipped "know"
# [16:05] <othermaciej> even though that can be complicated to implement
# [16:05] <othermaciej> you are right that swapping two <source> elements you wouldn't want to interrupt the video
# [16:05] <othermaciej> if it doesn't change which one applies
# [16:06] <othermaciej> but I think more commonly you'd update the src and type of all the <source> elements in order
# [16:06] <sayrer> Hixie: "I hate to be the one to break this to you" is pretty much universally interpreted as condescending and rude
# [16:06] <sayrer> especially when followed by things that everyone knokws
# [16:07] <sayrer> I should have been clearer with the patent point, though
# [16:07] <sayrer> if you have to pay someone, that means someone owns something
# [16:08] <sayrer> which is a pretty good definition of proprietary
# [16:08] <othermaciej> sayrer: ordering everyone to take patent discussion to a separate list you just created is pretty rude
# [16:08] <sayrer> othermaciej: I didn't order anyone. I thought it was pretty obviously a joke.
# [16:10] <othermaciej> sayrer: wasn't obvious to me, since you objected to patent discussion repeatedly
# [16:10] <sayrer> I do object to it
# [16:10] <sayrer> I don't think participating in WHATWG should include getting weird legal email from Apple. Sorry.
# [16:10] <othermaciej> if you don't want to hear about patents you are free to unsubscribe
# [16:11] <Hixie> just ignore the mails you don't care about, sheesh
# [16:11] <Hixie> we have to sort out this codec thing, and that means discussing patents
# [16:11] <Hixie> deal with it
# [16:11] <othermaciej> however, they are sadly a relevant issue to web standards
# [16:11] <Hixie> othermaciej: i think you'd want to update the srcs and then when you're done run the algorithm once.
# [16:12] <Hixie> othermaciej: i don't think you'd want to have the algorithm run as you're updating, with the UA flashing a "no available streams" message for a few milliseconds or something
# [16:12] <othermaciej> Hixie: that's probably so
# [16:12] <Hixie> othermaciej: or have the UA start playing one of the previous set of sources or something
# [16:12] <othermaciej> Hixie: I wish this could be like CSS style resolution
# [16:12] <othermaciej> where you can change multiple styles
# [16:12] <othermaciej> but the style recalc only happens after a delay
# [16:12] <othermaciej> or if you do something that demands the knowledge immediately
# [16:12] <othermaciej> (happens at next async opportunity that is)
# [16:13] <Hixie> i dunno, i think it makes sense to just have it be something you have to invoke. trying to see if i can think of other examples of this though.
# [16:14] <Hixie> one example would be XMLHttpRequest, it doesn't send off the request just because you've updated the headers
# [16:14] <Hixie> there's an explicit commit step
# [16:14] <Hixie> (two of them, even, with that API)
# [16:14] <othermaciej> yes, but explicit sending of a request is what the API is all about, and how network APIs normally work
# [16:14] <Hixie> i dunno, we can make it watch mutations... it just seems painful
# [16:15] <othermaciej> updating the rendering to reflect the markup is how display in browsers normally works
# [16:15] <othermaciej> even if some loads are involved
# [16:15] <Hixie> as a general rule i wouldn't put too much stock in precedent of how html works :-P
# [16:15] <othermaciej> I agree that having to explicitly update sounds easier to implement
# [16:15] <othermaciej> but it also seems unwebby
# [16:16] <othermaciej> anyway my opinion on this point isn't that strong, either way it will be better than <object>
# [16:17] <Hixie> fwiw, for some precedent the other way, <script> doesn't reexecute when you change it.
# [16:18] <Hixie> does changing <param> elements respawn the <object>'s plugin?
# [16:18] <othermaciej> no
# [16:19] <othermaciej> not even changing the data attribute changes the contents, I believe
# [16:19] <Hixie> hm, html5 says to relaunch plugin when data= or type= change, but ignores changes to <param>
# [16:19] <Hixie> might need to look into that at some point then
# [16:21] <Hixie> i'm gonna say changing the <source>s doesn't change the <video>, but we can change that later if we want. no biggie.
# [16:21] <othermaciej> ultimately I think we want something that works in the dynamic case (after all, it's "Web Apps 1.0") but that seems ok for starters
# [16:22] <Hixie> oh well don't get me wrong
# [16:22] <Hixie> there's already a method to manually trigger the algorithm
# [16:22] <Hixie> you just call video.load() and it redoes it all
# [16:22] <othermaciej> oh
# [16:22] <othermaciej> that seems ok
# [16:22] <Hixie> the question is just whether to implicitly call that for anything
# [16:22] <Hixie> the problem is what to call it for during parse time
# [16:23] * Lachy_ wonders how these test cases are useful and why they were posted to public-html? http://accessibleinter.net/html/testcases/
# [16:23] <Hixie> wait for document load event? hook it into the parser?
# [16:24] <othermaciej> I think at parse time loading the first successful one you see is fine
# [16:24] <Hixie> oh, right, we can still do that, yeah
# [16:24] <othermaciej> explicit load() can be required only if you change things after one has succeeded
# [16:25] <Hixie> yeah
# [16:33] <billmason> Lachy_: I don't know either, and because I was asked to.
# [16:33] * mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) has joined #whatwg
# [16:33] * KevinMarks reads scrollback
# [16:34] <Lachy_> I don't recommend blindly doing everything you are asked to do
# [16:34] <KevinMarks> so alternates for video are now in <source>
# [16:34] <Hixie> yeah
# [16:34] <Hixie> i'm speccing it now
# [16:34] <Hixie> should be done in an hour or so
# [16:35] * zcorpan_ has quit (Read error: 110 (Connection timed out))
# [16:35] <Lachy_> billmason: test cases are useful when trying to determine support for some specific feature in browsers and when they have clear pass/fail conditions.
# [16:36] <KevinMarks> dang, what a backlog of comments
# [16:36] <Lachy_> in the case of abbr/acronym, browser support is well known already, and your test cases don't specify any pass/fail conditions
# [16:38] <billmason> You're not telling me anything I don't know, I'm afraid.
# [16:38] <KevinMarks> have you looked at hreflang on source as a possible choice driver?
# [16:38] <sayrer> hehe, it gets better and better
# [16:39] <sayrer> content negotiation ftw
# [16:39] <KevinMarks> QT's content alternatives stuff supports that
# [16:39] <Hixie> KevinMarks: this is purely about getting the right codec, if you want to do language selection, just offer the languages to your users
# [16:39] <Hixie> or use HTTP Accept-Language
# [16:40] <sayrer> oh speaking of QT, is ok to do stuff in the <video> that isn't strictly video?
# [16:40] <Hixie> like what?
# [16:40] <sayrer> like, can I put Flash movie in it?
# [16:40] <Hixie> you mean an FLV file?
# [16:40] <sayrer> or an interactive QT thing?
# [16:40] <Hixie> sure
# [16:40] <Hixie> if your browser supports the FLV codecs
# [16:40] <Hixie> (which truly _are_ proprietary, unlike MPEG4)
# [16:40] <sayrer> no, I mean full on flash movies
# [16:40] <KevinMarks> well, the microformat draft did do that:
# [16:40] <KevinMarks> http://microformats.org/wiki/alternates#Strawman_6_.28lists_.2B_explicit_alternator_.2B_using_existing_HTML_idiom.29
# [16:41] <Hixie> you mean flash applications? as in swf files?
# [16:41] <Hixie> no
# [16:41] <sayrer> yep
# [16:41] <sayrer> ok, does the spec say that?
# [16:41] <Hixie> not sure what it would say
# [16:41] * mw22 has quit (Read error: 60 (Operation timed out))
# [16:41] <Hixie> it won't work, because the UA won't support that codec
# [16:41] <sayrer> does it also rule out the quicktime stuff, and any other weird interactive technologies?
# [16:41] <Hixie> because it's not a codec
# [16:42] <sayrer> well, some mime types imply a codec
# [16:42] <Hixie> if UAs want to work out what it would mean for that to work, i personally wish them luck
# [16:42] <Hixie> i don't see any reason to disallow it
# [16:42] <sayrer> (not trying to be a jerk... this will happen eventually)
# [16:42] <Hixie> actually, the spec does require one thing
# [16:42] <Hixie> it requise that the playback position increase monotonically
# [16:43] <Hixie> requires
# [16:43] <sayrer> ah, that's good
# [16:43] <Hixie> which pretty much throws out all that stuff
# [16:43] <sayrer> not too clear that stuff like DVD menus is out
# [16:43] <KevinMarks> chapters are useful, but they are hard to make now
# [16:43] <Hixie> well anyway
# [16:44] <Hixie> <source> is the current topic at hand
# [16:44] <Hixie> (as far as editing goes)
# [16:44] <Hixie> (feel free to discuss other things amongst yourselves!)
# [16:44] <sayrer> (well that won't work, no one has done it yet)
# [16:45] <KevinMarks> got ot get my train
# [16:45] * KevinMarks has quit ("The computer fell asleep")
# [16:46] <dhyatt> sayrer: btw not sure why you're ratholing on patents
# [16:46] <dhyatt> sayrer: maciej raised a technical objection to theora as well
# [16:46] <dhyatt> sayrer: but you just assumed he was talking about patents again when he wasn't
# [16:46] <sayrer> dyhatt: I saw one about hardware playback?
# [16:46] <dhyatt> correct.
# [16:46] <Hixie> oh god, yeah, theora is doomed on hardware-constrained devices
# [16:46] <dhyatt> you can't play video using theora in software on low end devices
# [16:47] <Hixie> without hardware support there's no way
# [16:47] <dhyatt> and even on those where you could sort of do it, the battery drain would be unacceptable
# [16:47] <sayrer> dhyatt: I asked if something about theora prevented hardware playback
# [16:47] <Hixie> yeah really
# [16:47] <dhyatt> you *need* hardware support right now
# [16:47] <dhyatt> this is a really serious issue that people are glossing over
# [16:47] <dhyatt> theora chips aren't going to magically materialize any time soon
# [16:47] <Hixie> sayrer: nothing prevents it, but it's academic if there are no hardware chips (there aren't any)
# [16:47] <sayrer> I asked a direct question about it
# [16:48] <sayrer> I'm not glossing over it
# [16:48] <dhyatt> anway my point was just that maciej is mainly concerned about that
# [16:48] <dhyatt> not about patents
# [16:48] <dhyatt> there are sound technical reasons to object to theora
# [16:48] <dhyatt> ranging from tools for putting video together not supporting it to hardware playback to etc
# [16:49] <sayrer> certainly there are sound reasons to refuse it as the /only/ option
# [16:49] <dhyatt> although maybe the former is not a big deal and i am just ignorant there :)
# [16:49] <dhyatt> my opinion is that we shouldn't even mandate a baseline codec
# [16:49] <sayrer> which some have suggested
# [16:49] <dhyatt> since <img> doesn't do that
# [16:50] <dhyatt> telling mobile devices that can play mpeg in hardware but nothing else that they just can't support the <video> element because they don't do theora is crazy imo
# [16:50] <sayrer> well, they wouldn't be compliant
# [16:50] <Hixie> oh the spec already allows you to not do ogg theora if you can't
# [16:50] <dhyatt> ah ok
# [16:50] <Hixie> it's a should-level requirement only at the moment
# [16:50] <dhyatt> got it
# [16:50] <sayrer> yes, you changed it
# [16:50] <Hixie> (it has never been a must)
# [16:50] <sayrer> the question is whether that's interesting when the spec is four years out
# [16:52] <sayrer> Hixie: there is a comment in there about it not being a must. I assumed you had changed it from some previous state.
# [16:52] <Hixie> nope
# [16:52] <sayrer> there is a comment in there, right?
# [16:52] <sayrer> "this isn't a must because of legal issues"
# [16:53] * billmason has quit ()
# [16:54] <Hixie> there's a comment, yes
# [16:55] <Hixie> it's to remind me of why it's a should, should anyone try to convince me to change it to a must :-)
# [16:55] * yod has quit ("This computer has gone to sleep")
# [16:55] <Hixie> i used to not leave notes to myself, and then i ended up in loops where i'd respond to feedback from one person, go must->should, a year later i'd go should->must, and back and forth year after year
# [16:55] <Hixie> until i realised what was going on
# [16:56] <Hixie> and now i put guards against that in these kinds of situations
# [16:58] * dhyatt has quit (Remote closed the connection)
# [16:59] * dhyatt (n=hyatt@c-24-6-91-161.hsd1.ca.comcast.net) has joined #whatwg
# [17:01] * Charl (n=charlvn@196.209.167.214) has joined #whatwg
# [17:04] * h3h has quit ()
# [17:14] * dhyatt has quit ()
# [17:18] * dhyatt (n=hyatt@c-24-6-91-161.hsd1.ca.comcast.net) has joined #whatwg
# [17:35] * Lachy_ has quit ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]")
# [17:54] * dhyatt has quit ()
# [18:07] <Hixie> tada!
# [18:07] <Hixie> spec updated for <source>
# [18:09] * sayrer has quit (Read error: 110 (Connection timed out))
# [18:11] <othermaciej> woo hoo
# [18:12] * peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) has joined #whatwg
# [18:13] <othermaciej> I see you also split out the media element generic stuff from <video>
# [18:16] <Hixie> yeah
# [18:16] <Hixie> gonna collapse <audio> and Audio()
# [18:16] <Hixie> and make them inherit from HTMLAudioElement like in your propasl
# [18:22] <othermaciej> cool
# [18:24] * KevinMarks (n=Snak@h-68-164-93-9.snvacaid.dynamic.covad.net) has joined #whatwg
# [18:24] <othermaciej> I guess I will wait til you are done adding stuff to compare the result to our proposal w/ my Apple cohorts and to raise any issues
# [18:25] <othermaciej> and after that I will raise for discussion features we did not even propose a spec for, like metadata access, track info, timed text support, etc
# [18:25] * jcgregorio has quit ("Chatzilla 0.9.77 [Firefox 2.0.0.2/0000000000]")
# [18:25] <othermaciej> although I am not sure it is worth raising such things on the whatwg list w/o a spec proposal
# [18:25] <othermaciej> since there don't seem to be a lot of media experts there, either that or they don't want to chime in
# [18:25] <othermaciej> hello KevinMarks
# [18:26] <Hixie> feel free to raise use cases and feature requests
# [18:26] <KevinMarks> hi
# [18:26] <KevinMarks> sorry, I should review it, I have had a hectic couple of days
# [18:26] <Hixie> i'll talk to the various experts i have access to (including apple people if they'll talk to me), look at existing apis, and see what we can come up with
# [18:26] <Hixie> don't review it today
# [18:27] <Hixie> tomorrow it should be in better state
# [18:27] <KevinMarks> OK
# [18:27] <Hixie> i'm slowly merging a bunch of the apple proposals
# [18:27] <othermaciej> did you mean the stuff in the whatwg spec or apple's proposals?
# [18:27] <othermaciej> apple's proposals aren't going to change, so you can read them, but Hixie is changing some stuff as he merges it in
# [18:27] <Hixie> oh sorry i assumed he meant the whatwg spec
# [18:27] <KevinMarks> I read the main apple one
# [18:28] <KevinMarks> but I haven't read the whatwg spec recently, though I did plough through some of ian's mmaoth collations
# [18:28] <KevinMarks> *mammoth
# [18:28] <Hixie> hehe
# [18:28] <othermaciej> one important but minor point is that time should really be floating point (and so probably seconds) instead of integer milliseconds
# [18:28] <Hixie> ew, really?
# [18:28] <othermaciej> I can write an email explaining why if you want
# [18:28] <othermaciej> well, it wasn't an accident that our spec had it that way
# [18:28] <Hixie> i'll change it, but, i'd love to see the reasoning, yes
# [18:29] <Hixie> when i looked at it it seemed like a really bad idea
# [18:29] <othermaciej> 1) milliseconds are not precise enough for audio
# [18:29] <Hixie> precise enough to do what with audio?
# [18:29] <KevinMarks> get the right sample
# [18:29] <othermaciej> 2) using integer milliseconds you start getting roundoff error accumulation
# [18:29] <KevinMarks> really, you want to use fractions like QT does
# [18:29] <othermaciej> audio has very high sample rates
# [18:30] <othermaciej> yeah, rational numbers of some kind would work best
# [18:30] <othermaciej> we are still discussing a proposal for that
# [18:30] <othermaciej> it's hard to come up w/ something sane
# [18:30] <Hixie> floats in general seem like a really bad idea due to the loss in precision as you go higher
# [18:30] <KevinMarks> yes
# [18:30] <othermaciej> well, JS numbers are all floats anyway
# [18:30] <Hixie> (not to mention the general disaster that floats give you)
# [18:30] <Hixie> but ok
# [18:30] <KevinMarks> and video frames are actually 30000/1001 per second in the US
# [18:31] <othermaciej> television video signals, yes
# [18:31] <othermaciej> thus the wonder that is smpte drop frames
# [18:31] <Hixie> to be honest i wasn't seeing seeking to precise frames and audio samples as a feature with demand
# [18:31] <Hixie> all the seeking i've seen happen seems to just be for scrub bars
# [18:31] * karlUshi has quit ("Where dwelt Ymir, or wherein did he find sustenance?")
# [18:31] <KevinMarks> and chapters
# [18:31] <othermaciej> we'd like something that can at least be extended to pro-type applications in the future
# [18:32] <KevinMarks> I need to write up something on chapters
# [18:32] <othermaciej> even if it doesn't handle them in the HTML5 version
# [18:32] <KevinMarks> HTML EDLs?
# [18:32] <othermaciej> we had a vague comment on chapters in our open issues list
# [18:32] <Hixie> lord, i hope y'all don't want to reimplement Final Cut Express in HTML
# [18:32] <KevinMarks> chapters are a common case for podcasts
# [18:33] <KevinMarks> little running order posts with time offsets
# [18:33] <othermaciej> I doubt FCE is coming but a simple video editor web app might not be out of the question
# [18:33] <KevinMarks> maybe that's a microformat rather than an html 5 feature
# [18:33] <othermaciej> or something to review HD video dailies
# [18:33] <Hixie> how high can JS Numbers go before they lose too much precision for accurate seeking?
# [18:34] <othermaciej> they are IEEE floating point doubles, they can go pretty high
# [18:34] <Hixie> k
# [18:34] <KevinMarks> they are 64 bit?
# [18:34] <othermaciej> 52 bit mantissa, 11 bit exponent, 1 bit sign
# [18:35] <othermaciej> not sure if that is sufficient even for streaming applications where you leave the stream running for days
# [18:35] <othermaciej> but there you don't generally support seeking anyway
# [18:35] <KevinMarks> and you have to futz with the samples to stay in sync cos of the 2 clocks problem
# [18:36] * KevinMarks is getting fashbacks
# [18:36] <othermaciej> I don't think our proposal is totally ready for the streaming case
# [18:36] <KevinMarks> it's marginal anyway...
# [18:36] <othermaciej> web video chat?
# [18:36] <othermaciej> live broadcasts?
# [18:37] <KevinMarks> hm, maybe
# [18:37] <othermaciej> internet radio?
# [18:37] <KevinMarks> that got killed
# [18:38] <KevinMarks> they have indefinite duration
# [18:38] <KevinMarks> I think you covered that
# [18:38] <othermaciej> if you want 10 digits after the decimal, IEEE double is enough for a 139,461 year long stream
# [18:38] <othermaciej> so probably more than enough
# [18:39] <othermaciej> we did cover indefinite duration
# [18:39] <othermaciej> did not really cover inability to seek or some of the other grungy details
# [18:42] <KevinMarks> Hixie, did I show you my example fo a qt movie with chapters?
# [18:42] <Hixie> no?
# [18:43] <othermaciej> KevinMarks: do you have in mind chapters that exist as metadata in the media file, or external chapters that just link a name to some point in time?
# [18:43] <Hixie> othermaciej: btw did you have a list of names i should add to the acknowledgements of people who wrote your proposal?
# [18:43] <othermaciej> Hixie: I'm not sure they all want to be credited but I'll ask
# [18:43] <KevinMarks> http://epeus.blogspot.com/2007/01/iphones-great-step-back-from-ichat.html
# [18:43] <Hixie> othermaciej: k
# [18:44] <Hixie> othermaciej: (i generally add anyone who says anything that results in the spec changing, whether the change is what they wanted or not, and whether they want to be associated with the spec or not)
# [18:44] <Hixie> right, converted to floats/seconds
# [18:45] <KevinMarks> not in the media file. I think specifying them in the html, so that your soft controller can do the chapterlist thing
# [18:45] <KevinMarks> maybe they're just a <select>
# [18:47] <othermaciej> KevinMarks: but in your example I assume the chapters are in the media file?
# [18:47] <KevinMarks> they aren't in apple's media file
# [18:48] <othermaciej> for chapters purely in html, you don't really need special support
# [18:48] <KevinMarks> I authored them in apple's not-quite xml format, and rendered them into a movie
# [18:48] <othermaciej> unless you somehow want to feed them into native controller UI
# [18:48] <othermaciej> for chapters in the media file, you want a metadata API to get the names, and to seek to chapter by name
# [18:49] <KevinMarks> http://docs.info.apple.com/article.html?path=QuickTime%20Player/7.0/en/c3qt20.html
# [18:49] * hlb has quit (Read error: 104 (Connection reset by peer))
# [18:50] <KevinMarks> hm, I think that used to have screenchots in
# [18:55] <KevinMarks> here's the timestamp format
# [18:55] <KevinMarks> http://developer.apple.com/documentation/QuickTime/RM/ImportExport/DataExchange/F-Chapter/chapter_6_section_7.html
# [18:59] <othermaciej> we wanted to put a way to use that timestamp format in the API to specify times
# [18:59] <othermaciej> and in the CSS stuff
# [18:59] <othermaciej> didn't have time to spec it out before publishing though
# [19:00] <othermaciej> (not necessarily the brackets, but the genral idea of a clock time with fractional seconds)
# [19:00] <Hixie> yeah maybe we need a helper function like atob()
# [19:00] <Hixie> ctos() (clock to seconds)
# [19:00] <othermaciej> we thought conversion functions back and forth might cut it, yeah
# [19:00] <Hixie> ctos('22h33m21s.02')
# [19:01] <Hixie> though some people have said they need to be able te specify exact frames in video
# [19:01] <othermaciej> I think 22:33:21:0.02 is more legible
# [19:01] <Hixie> for which that wouldn't work
# [19:01] <Hixie> either's fine
# [19:01] <othermaciej> for exact frames you basically need a frame number, since some formats have variable-duration frames
# [19:01] <Hixie> (the h/m/s/. format has the advantage of allowing you to omit seconds)
# [19:02] <KevinMarks> dear god, what is that xml format it exports?
# [19:02] <Hixie> yeah
# [19:03] <KevinMarks> http://homepage.mac.com/kevinmarks/macworld2007.txt is the text version
# [19:03] <KevinMarks> which could map to HTML cleanly IMO
# [19:03] <KevinMarks> http://homepage.mac.com/kevinmarks/macworld2007.xml is a total rats nest
# [19:05] <othermaciej> yeah, with colons you can only omit from the larger unit
# [19:05] <KevinMarks> timeScale="30" s the key
# [19:05] <othermaciej> but that is generally ok
# [19:05] <othermaciej> it is also more likely to be what you want to display to the user
# [19:05] <othermaciej> though I guess Date already has format capabilities
# [19:06] <Hixie> in this locale, at least
# [19:06] <Hixie> in french locale, 7h20m10s is quite common
# [19:06] <Hixie> at least for wallclock
# [19:06] <KevinMarks> is the interval version of Date in javascript?
# [19:06] <othermaciej> JavaScript Dates are absolute times, not time intervals
# [19:07] <othermaciej> I don't think there is a way to represent a time interval, other than a number
# [19:09] <KevinMarks> there is in 8601 iirc
# [19:10] <Hixie> 8601 isn't a standard
# [19:10] <KevinMarks> http://www.faqs.org/rfcs/rfc3339.html
# [19:10] <KevinMarks> then
# [19:10] <Hixie> it's the result of a brainstorming session
# [19:10] <KevinMarks> though that is only decimal seconds
# [19:11] <Hixie> (i'm being facetious, but seriously, who the hell did 8601, it's ridiculous)
# [19:11] <KevinMarks> yes, it is a bit overbroad
# [19:12] <KevinMarks> rfc3339 is a more sensible subset
# [19:16] * met_ (n=Hassman@r5bx220.net.upc.cz) has joined #whatwg
# [19:21] <Hixie> ok, behold <audio>.
# [19:23] <Hixie> need to add looping then we can retire Audio()
# [19:23] <Hixie> (with new Audio() creating an HTMLAudioElement instead)
# [19:26] <Hixie> othermaciej?
# [19:26] <Hixie> othermaciej: do you know the use case for loopStartTime/loopEndTime?
# [19:27] <Hixie> i guess if your audio samples are from one file
# [19:28] <othermaciej> Hixie: yeah, if you want multiple samples from one file; we also have the possibility of intro and outro besides the looping section but that might be excessive
# [19:29] <othermaciej> but at least the lead-in can be useful for some background sound-effects
# [19:29] <othermaciej> intro then loop
# [19:29] <Hixie> true
# [19:29] <othermaciej> loopEndTime is mainly for symmetry
# [19:29] <Hixie> so should we have start/end, start/loopStart/end, or start/end/loopStart/loopEnd?
# [19:30] <Hixie> or should we do looping simply by providing a cue point api
# [19:30] <Hixie> and requiring people to do it themeselves?
# [19:31] <othermaciej> programmatic looping is more likely to glitch
# [19:31] <Hixie> audio.addCuePoint(93.3, function () { audio.seek(12.0); });
# [19:31] <Hixie> yeah
# [19:31] <Hixie> true
# [19:31] <othermaciej> especially if you are discarding buffers, or for audio
# [19:31] <othermaciej> for audio especially even dropping one sample (at a very high sample rate) can audibly glitch
# [19:31] <Hixie> yeah
# [19:32] <othermaciej> CuePoint sounds like a better name than TimeTrigger (which is what we had)
# [19:32] <Hixie> cool, i'll use CuePoint then (i think i have CueMark in the comments right now)
# [19:32] <Hixie> how about semi-declarative cue points, as in audio.addAutoSeekCuePoint(99.3, 12.0)
# [19:32] <Hixie> i guess that wouldn't do finite looping
# [19:32] <Hixie> ok so we need something
# [19:33] <Hixie> start/end/loopStart/loopEnd, i guess
# === Lachy end ===
# [09:33] <krijnh> Whoops
# [09:40] * Joins: dhyatt (n=hyatt@c-24-6-91-161.hsd1.ca.comcast.net)
# [10:07] <Hixie> gonna go home
# [10:07] <Hixie> might work some more from home
# [10:08] <dhyatt> seeya
# [10:19] * Looking up krijnh user info...
# [10:19] * Disconnected
# [10:20] * Attempting to rejoin channel #whatwg
# [10:20] * Rejoined channel #whatwg
# [10:20] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
# [10:20] * Set by Hixie on Thu Mar 22 01:25:40
# [10:20] * Joins: marcosc (n=chatzill@131.181.148.226)
# [10:24] * Quits: marcosc (n=chatzill@131.181.148.226) (Client Quit)
# [10:44] * Quits: Charl (n=charlvn@196.209.167.214) (Read error: 60 (Operation timed out))
# [10:53] * Joins: ROBOd (n=robod@86.34.246.154)
# [10:57] * Joins: Charl (n=charlvn@196.209.167.214)
# [11:18] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
# [11:20] * Quits: dhyatt (n=hyatt@c-24-6-91-161.hsd1.ca.comcast.net)
# [11:24] * Joins: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [11:25] * Joins: welly (n=welly@62-31-59-92.cable.ubr12.azte.blueyonder.co.uk)
# [11:39] * Quits: Charl (n=charlvn@196.209.167.214) ("Leaving")
# [11:39] * othermaciej is now known as om_sleep
# [11:40] * Quits: welly (n=welly@62-31-59-92.cable.ubr12.azte.blueyonder.co.uk)
# [11:44] * Parts: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [11:47] <Hixie> i wonder whether loop() should automatically seek() to the begin point first
# [11:51] <met_> for video or audio?
# [11:52] <Hixie> both
# [11:52] <Hixie> though if you think they should be different, do say
# [11:53] <met_> when compare with e.g. mp3 players, there you can switch on/off repeat during listening and it contiues play without switching
# [11:53] <met_> same tape-recorders
# [11:53] <met_> do not see seek before loop in any system I know
# [11:54] <met_> dvd players the same I think
# [11:55] <Hixie> the problem is if you don't seek() when you call loop(), then it's not clear how to either (a) restart a loop, or (b) do a loop with pre- and post-roll sfx
# [11:56] <Hixie> (a) would require the author to explicitly seek() to start pos when paused before calling loop(), otherwise nothing would happen when you called loop()
# [11:57] <Hixie> i'm gonna get some sleep, think about it when i get up.
# [11:57] <Hixie> ttyl
# [11:57] <met_> gn
# [12:05] * Quits: htmlr (n=cjb@CPE-138-130-176-60.nsw.bigpond.net.au)
# [12:56] * Quits: aroben (i=adamrobe@nat/apple/x-30016eb399fbee49)
# [13:01] * Joins: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [13:12] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
# [13:29] * moeffju[ZzZz] is now known as moeffju
# [13:30] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
# [13:31] * Parts: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [13:47] * Joins: bzed (n=bzed@dslb-084-059-125-163.pools.arcor-ip.net)
# [14:06] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
# [14:11] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 60 (Operation timed out))
# [14:17] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [14:17] * mw22____________ is now known as mw22
# [14:28] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
# [14:39] * Joins: jcgregorio (i=chatzill@nat/ibm/x-ba0c1a27e30e7cd6)
# [14:42] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [14:53] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 60 (Operation timed out))
# [14:53] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [14:57] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 54 (Connection reset by peer))
# [15:01] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [15:04] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
# [15:06] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
# [15:13] * Joins: Charl (n=charlvn@196.21.192.15)
# [15:15] * Joins: icaaq_ (n=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [15:16] * Joins: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [15:18] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Get thee behind me, satan.")
# [15:21] * zcorpan_ is skipping all the Codec emails
# [15:36] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
# [15:36] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com) (Read error: 104 (Connection reset by peer))
# [15:37] * Joins: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
# [15:50] * Joins: sayrer (n=chatzill@user-12ld2ss.cable.mindspring.com)
# [16:03] * Quits: h3h (n=w3rd@cpe-70-95-237-98.san.res.rr.com)
# [16:08] * Joins: zcorpan (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [16:16] * Quits: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
# [16:25] * Quits: sayrer (n=chatzill@user-12ld2ss.cable.mindspring.com) (Read error: 110 (Connection timed out))
# [16:29] * Parts: zcorpan (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [16:37] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [16:47] * Joins: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [16:52] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
# [16:56] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
# [16:57] <tylerr> Morning everyone.
# [16:58] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [17:01] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [17:03] <zcorpan_> morning tylerr
# [17:03] * Joins: sayrer (n=chatzill@user-10876hc.cable.mindspring.com)
# [17:04] <tylerr> Hey there zcorpan_, how was the rest of the day yesterday?
# [17:04] <zcorpan_> fine i guess
# [17:05] <tylerr> Good good, any plans for the (rest of the) day?
# [17:06] <zcorpan_> yeah, i'll play duke nukem 3d at "damn i'm good" :D
# [17:06] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [17:07] <zcorpan_> i'm almost through the second episode
# [17:07] * Quits: jcgregorio (i=chatzill@nat/ibm/x-ba0c1a27e30e7cd6) ("Chatzilla 0.9.77 [Firefox 2.0.0.2/0000000000]")
# [17:09] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [17:09] * mw22____________ is now known as mw22
# [17:09] <zcorpan_> what about you?
# [17:11] <tylerr> Just got into the office and have to clean up the work of another vendor that our client has building pages. It's rather frustrating seeing a professional vendor produce such garbage pages.
# [17:18] * Quits: Charl (n=charlvn@196.21.192.15)
# [17:25] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [17:43] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [17:45] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [18:00] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [18:00] * mw22____________ is now known as mw22
# [18:15] * Quits: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com) ("later")
# [18:19] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
# [18:22] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [18:34] * Quits: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
# [18:42] * moeffju is now known as moeffju[Away]
# [18:45] * Joins: epeus (i=KevinMar@nat/google/x-b73a71f7881caa02)
# [18:45] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [18:47] * Quits: annevk (n=annevk@5352CE6F.cable.casema.nl) (Read error: 110 (Connection timed out))
# [18:49] * Joins: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [18:54] * Joins: smfr (i=smfr@nat/apple/x-d8130a80382439f7)
# [18:57] * Quits: epeus (i=KevinMar@nat/google/x-b73a71f7881caa02) ("The computer fell asleep")
# [18:58] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [19:00] * Joins: epeus (i=KevinMar@nat/google/x-8dec44b798d26fe4)
# [19:03] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [19:05] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
# [19:06] * Parts: icaaq_ (n=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [19:06] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [19:09] * hsivonen tries not be too snide when replying to a message motivated by failure to comprehend Apple's lawyer talk
# [19:09] <hsivonen> seriously, software and Web design people should learn to parse lawyer speak
# [19:10] <hsivonen> this working around of patent ghosts where there's no reason to work around is silly
# [19:17] * Quits: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [19:21] <hasather> hehe: http://my.opera.com/hallvors/blog/2007/03/23/hp-com-no-clue-noscript
# [19:22] <hsivonen> wow
# [19:23] * Joins: hendry (n=hendry@91.84.53.136)
# [19:26] * Joins: nickshanks (n=nicholas@home.nickshanks.com)
# [19:49] * Joins: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [20:02] * Quits: epeus (i=KevinMar@nat/google/x-8dec44b798d26fe4) ("The computer fell asleep")
# [20:15] <tylerr> hsivonen: We need a <legal> tag that auto-parses. ;)
# [20:17] <hendry> "Leading the Forefront - with IRC ! ?" lol
# [20:18] <tylerr> :-)
# [20:25] * Quits: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
# [20:31] * Joins: epeus (i=KevinMar@nat/google/x-b30aa7d4d79cf281)
# [20:31] * Joins: tantek (n=tantek@scil-socketset2.Stanford.EDU)
# [20:33] * Quits: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk) ("Leaving")
# [20:33] * Joins: deltab (n=deltab@82-46-154-93.cable.ubr02.smal.blueyonder.co.uk)
# [20:46] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [20:50] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [20:50] * Quits: epeus (i=KevinMar@nat/google/x-b30aa7d4d79cf281) ("The computer fell asleep")
# [20:51] * om_sleep is now known as othermaciej
# [20:51] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [20:55] * Joins: epeus (i=KevinMar@nat/google/x-c4ee4a7775431087)
# [21:09] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [21:13] <othermaciej> good morning
# [21:21] * Joins: aroben (i=adamrobe@nat/apple/x-6e74cbf6c844b7d0)
# [21:22] * Quits: aroben (i=adamrobe@nat/apple/x-6e74cbf6c844b7d0) (Client Quit)
# [21:23] * Joins: aroben (i=adamrobe@nat/apple/x-4503e90f9e2f3248)
# [21:27] * moeffju[Away] is now known as moeffju
# [21:30] * Joins: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [21:33] <zcorpan_> othermaciej: morning
# [21:35] * Joins: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se)
# [21:40] * Joins: psa (n=yomode@posom.com)
# [21:41] * Joins: tantek_ (n=tantek@scil-socketset2.Stanford.EDU)
# [21:48] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
# [21:53] <othermaciej> hello zcorpan_
# [21:53] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [21:55] * Quits: epeus (i=KevinMar@nat/google/x-c4ee4a7775431087) ("The computer fell asleep")
# [21:55] * Quits: tantek_ (n=tantek@scil-socketset2.Stanford.EDU)
# [21:57] * Quits: tantek (n=tantek@scil-socketset2.Stanford.EDU) (Read error: 110 (Connection timed out))
# [22:01] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
# [22:08] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [22:08] * mw22____________ is now known as mw22
# [22:11] * gavins is now known as gavin
# [22:16] <zcorpan_> Hixie: there are three IDs "video" in the spec
# [22:17] <krijnh> Still?
# [22:17] * othermaciej is now known as om_food
# [22:18] <zcorpan_> yes
# [22:25] <zcorpan_> "Perhaps not, but this will: applet { display: none !important; }" LOL
# [22:26] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [22:29] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [22:29] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Remote closed the connection)
# [22:30] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [22:32] * Joins: epeus (i=KevinMar@nat/google/x-24c18160aee2934a)
# [22:39] * zcorpan_ updated html5-elements
# [22:43] * Joins: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl)
# [23:01] * Quits: mw22 (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [23:02] * om_food is now known as othermaciej
# [23:14] * Quits: icaaq_ (i=icaaaq@c-f535e455.231-7-64736c10.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
# [23:22] * Joins: webben (n=benjamin@91.84.131.217)
# [23:23] * Quits: mw22____________ (n=chatzill@h8441169151.dsl.speedlinq.nl) (Read error: 110 (Connection timed out))
# [23:28] * Quits: kingryan (n=kingryan@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [23:42] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [23:52] * Joins: tantek (n=tantek@dsl092-180-242.sfo1.dsl.speakeasy.net)
# [23:54] * Quits: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se) (Read error: 54 (Connection reset by peer))
# [23:54] * Joins: zcorpan_ (n=zcorpan@84-216-40-94.sprayadsl.telenor.se)
# [23:56] * Joins: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# Session Close: Sat Mar 24 00:00] 2007

The end :)