/irc-logs / freenode / #whatwg / 2007-04-09 / end

Options:

# Session Start: Mon Apr 09 00:00:00 2007
# Session Ident: #whatwg
# [00:19] * Quits: hendry (n=hendry@91.84.53.136) ("nn")
# [00:53] * Quits: mpt (n=mpt@121-72-128-156.dsl.telstraclear.net) ("Leaving")
# [00:55] <Lachy> the idea for the generic script data attr is interesting.
# [00:56] <Lachy> I've used class="" in the past for such things
# [00:56] <Dashiva> Yeah, and I predict that if role is ever made common, people will use role for it too
# [00:57] <Lachy> If they did, it would be abuse
# [00:57] <Lachy> but I doubt role will ever become successful
# [00:58] <Dashiva> As long as the validator didn't complain, that's all that would matter
# [00:58] <Lachy> I'd like to know more about the use cases ppk has in mind for it
# [00:59] <Lachy> I'll ask him.
# [00:59] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
# [00:59] <Dashiva> An example would be declarative form validation before wf2
# [00:59] <webben> Lachy, Isn't role already becoming successful for a tech that hasn't even been standardized yet?
# [00:59] <webben> (leaving aside the Q of whether role is well specced)
# [01:00] <Dashiva> You could either make up attributes and face invalidation (scary) or use class
# [01:00] <Lachy> only in a very limited market
# [01:01] <Lachy> I haven't seen it used beyond a few experimental pages so far
# [01:01] <webben> I think Dojo are either using it or planning on using it.
# [01:01] <Lachy> what for?
# [01:02] <webben> Lachy, WAI
# [01:02] <webben> (ARIA support in FF and major screen readers)
# [01:02] <Lachy> for what purpose?
# [01:02] <webben> increased accessibility of weird widgets
# [01:02] <webben> and (I suppose) live regions
# [01:03] <Lachy> I don't understand what it's for. HTML5 elements and form controls seem to cover everything role does, and more
# [01:03] <webben> see e.g. http://dojotoolkit.org/node/549
# [01:03] <webben> Lachy, I'm not sure HTML5 yet has a way of expressing the priority of live updates?
# [01:04] <webben> Lachy, might as well ask what Dojo is for
# [01:04] <webben> the important thing is that Dojo apps if built be made accessible, i think
# [01:06] <webben> Lachy, I suspect at least some of this reflects authors' desire to style form widgets
# [01:06] <webben> but I don't really know
# [01:07] <Lachy> styled form controls are a problem that CSS will solve
# [01:07] <webben> do we have HTML5 tree widgets?
# [01:08] <webben> Lachy, I thought CSS was abstaining from defining how UAs should render form widgets
# [01:09] <Lachy> http://www.w3.org/TR/css3-ui/
# [01:10] <Lachy> and also see Web Controls 1.0
# [01:10] <webben> Is there anything to indicate that Safari is likely to implement those?
# [01:11] <webben> (I single out Safari for being the greatest stickler for native-looking widgets)
# [01:12] <Lachy> no idea
# [01:14] <Dashiva> Safari looks like the OS extension IE is ;)
# [01:15] <webben> because if not ... people are likely to continue to use divs and spans
# [01:15] <webben> especially as those work in IE6-7
# [01:15] <Hixie> safari does a lot of css3-ui already
# [01:16] <webben> really? I'll have to try that out. (not that i particularly like styling widgets to look non-native, but oh well)
# [01:17] * Parts: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
# [01:24] <Lachy> http://www.quirksmode.org/blog/archives/2007/04/html_5.html (see comments 7 and 8)
# [01:26] * Lachy needs to blog about why xhtml2 is not the future
# [02:07] <deltab> Lachy: it's the flying-car future
# [02:17] * Joins: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au)
# [02:22] * Joins: karlUshi (n=karl@dhcp-246-23.mag.keio.ac.jp)
# [02:23] * Quits: webben (n=benjamin@91.84.131.217) ("Leaving")
# [02:32] * Quits: bzed (n=bzed@dslb-084-059-121-097.pools.arcor-ip.net) ("Leaving")
# [02:36] * aroben is now known as aroben|food
# [02:53] * Joins: ericcarlson_ (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [02:53] * Quits: ericcarlson (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
# [02:53] * Quits: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au)
# [02:55] * Joins: yod (n=ot@dhcp-246-8.mag.keio.ac.jp)
# [03:27] * Joins: tantek (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net)
# [04:20] * Quits: Philip` (n=excors@zaynar.demon.co.uk)
# [04:27] * Quits: tantek (n=tantek@c-71-202-121-218.hsd1.ca.comcast.net)
# [04:48] * aroben|food is now known as aroben
# [04:49] * aroben is now known as aroben|phone
# [05:27] * Quits: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com) (Connection reset by peer)
# [05:27] * Joins: gsnedders (n=gsnedder@host86-139-123-225.range86-139.btcentralplus.com)
# [05:35] * aroben|phone is now known as aroben
# [06:10] * Quits: kingryan (n=kingryan@dsl081-240-149.sfo1.dsl.speakeasy.net)
# [06:16] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [07:08] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [07:45] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [08:30] * Joins: met_ (n=Hassman@r5bx220.net.upc.cz)
# [08:34] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [08:42] * Quits: aroben (n=adamrobe@adsl-70-231-237-176.dsl.snfc21.sbcglobal.net)
# [08:49] * Joins: MikeSmith (i=mike@tea17.w3.mag.keio.ac.jp)
# [09:30] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
# [09:32] * Joins: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
# [09:32] * Parts: peepo (n=Jay@host86-129-175-144.range86-129.btcentralplus.com)
# [09:37] * Quits: yod (n=ot@dhcp-246-8.mag.keio.ac.jp) ("Leaving")
# [09:44] * Quits: karlUshi (n=karl@dhcp-246-23.mag.keio.ac.jp) ("Where dwelt Ymir, or wherein did he find sustenance?")
# [09:45] <annevk> We could have a state= attribute on certain elements like <xbl:div state>
# [09:45] <annevk> for scripts
# [09:46] <hsivonen> would "private" conflict with ECMA reserved words?
# [09:47] <annevk> iirc, yes
# [09:48] <annevk> I'm not entirely convinced it's need though given XBL2
# [09:50] <hsivonen> http://www.w3.org/2007/uwa/
# [09:50] <hsivonen> how (in)applicable is Web Apps 1.0 when it comes to home monitoring and control, home entertainment, office
# [09:50] <hsivonen> equipment, mobile and automotive
# [09:50] <hsivonen> ?
# [09:51] <annevk> I think that group is about putting device specific APIs into a generic framwork or something
# [09:51] * annevk isn't sure how that helps anyone
# [10:05] <hsivonen> made a lot of progress: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fsimon.html5.org%2Ftemp%2Fw3c-home-in-html5.html
# [10:20] * Joins: ROBOd (n=robod@86.34.246.154)
# [10:34] <Hixie> hsivonen: what are we looking for, progress wise?
# [10:35] <hsivonen> Hixie: compared to the time when zcorpan pasted that URL here, there are a lot less incorrect error messages
# [10:35] <Hixie> ah cool!
# [10:35] <hsivonen> Hixie: I updated the schema layer
# [10:50] <MikeSmith> hsivonen, annevk - the UWA WG is basically the Device Independece WG, renamed
# [10:50] <MikeSmith> as far as what part of it might be applicable ...
# [10:51] <MikeSmith> http://www.w3.org/2006/10/uwa-charter.html#dci
# [10:51] <MikeSmith> http://www.w3.org/2006/10/uwa-charter.html#device-coordination
# [10:52] <annevk> I didn't care much for their specs either
# [10:55] <MikeSmith> annevk - some criticize them as being overengineered
# [10:55] <annevk> yeah, though that goes for most of the W3C :)
# [10:56] <hsivonen> http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fsimon.html5.org%2Ftemp%2Fw3c-home-in-html5.html
# [10:56] <hsivonen> yay
# [10:57] * Joins: bzed (n=bzed@dslb-084-059-100-245.pools.arcor-ip.net)
# [10:58] <annevk> the "conforming
# [10:58] <annevk> message should be clearer
# [10:59] <MikeSmith> annevk - perhaps so (about W3C). and perhaps more people are learning that or have learned it -- the hard way, by not seeing their specs get implemented more widely
# [10:59] <hsivonen> annevk: intentional weasel words at this point :-)
# [10:59] <hsivonen> annevk: or, rather, intentional in the parentheses
# [11:00] <hsivonen> annevk: what would you suggest before the parentheses?
# [11:00] * Joins: hasather (n=hasather@81-235-209-174-no62.tbcn.telia.com)
# [11:01] <Hixie> i love the "valid html5" icon he made
# [11:01] <Hixie> that's awesome
# [11:01] <annevk> "Congratulations, your document is conforming HTML5"
# [11:01] <annevk> or something
# [11:01] <annevk> with some !!11! following it...
# [11:05] <annevk> hsivonen, http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fannevankesteren.nl%2F I don't get the "bad value for attribute href" messages...
# [11:05] <annevk> hsivonen, is that because my href has http:// at the start and @ somewhere in it?
# [11:09] <hsivonen> annevk: the line numbers are weird. do you mix Unix and Windows line breaks?
# [11:09] <annevk> maybe, dunno
# [11:10] <annevk> I'm including some standalone files that may or may not have UNIX line endings...
# [11:10] <hsivonen> anyway, TextWrangler and my parser have a different notion of line numbers
# [11:11] <hsivonen> but yeah, chances are that @ is the problem
# [11:11] <annevk> (use it as a testcase)
# [11:11] <annevk> per HTML5 line endings shouldn't matter
# [11:12] <hsivonen> either @ isn't allowed unescaped in HTTP IRIs or the IRI library has a bug in it
# [11:13] <hsivonen> annevk: my parser should decide the nature of a line break on a line-by-line basis, but TextWrangler sniffs the top and assumes the same kind of line breaks throughout the file
# [11:16] <annevk> time to update HTTP IRIs then :)
# [11:16] <hsivonen> annevk: did you already figure out if it is a library bug or an RFC bug?
# [11:17] <annevk> oh no
# [11:18] <hsivonen> annevk: can't be just @. you have more than two instances of such IRIs
# [11:19] <annevk> ipchar seems to allow a literal @
# [11:19] <annevk> what are the IRIs that trigger it?
# [11:20] <hsivonen> annevk: I don't know, because the line numbers are all weird
# [11:20] <annevk> the line numbers from the validator are correct?
# [11:21] <annevk> ah, it's "irc://irc.w3.org:80/html-wg"
# [11:21] <hsivonen> annevk: hopefully. :-)
# [11:21] <hsivonen> now, *that's* weird
# [11:21] <annevk> and "irc://irc.freenode.net/whatwg"
# [11:22] <hsivonen> the library should apply generic IRI processing to irc: IRIs
# [11:22] <hsivonen> and obviously those should be fine as far as the generic processing goes
# [11:22] <hsivonen> irc on port 80?
# [11:22] <annevk> yeah
# [11:23] <hsivonen> firewall thing?
# [11:23] <Hixie> and people tell _me_ off for misusing port 80. pah.
# [11:23] <annevk> to work around certain firewalls that block on port rather than functionality
# [11:24] <hsivonen> annevk: added to my todo list
# [11:24] * Joins: hendry (n=hendry@91.84.53.136)
# [11:24] <hsivonen> annevk: thanks
# [11:26] <annevk> it also complains about accesskeys and my doctype which apparently triggers quirks in an unused browser
# [11:26] * hsivonen expects a bug report email when the first person hits the transparent content model of <video> inside <figure>
# [11:26] <hsivonen> annevk: are accesskeys in HTML5 already?
# [11:27] <Hixie> hsivonen: yeah that's a bug
# [11:27] <Hixie> in the spec
# [11:27] <annevk> I suppose they aren't
# [11:27] <Hixie> need to rework how <figure> works to allow <ol>s, though, so i'll fix it later
# [11:27] <annevk> and <svg:svg>
# [11:27] <Hixie> accesskeys aren't in because nobody has yet explained how to fix them
# [11:28] <hsivonen> Hixie: <ol>s?
# [11:28] <Hixie> and <ul>s, and <pre>, and whatever else people have argued should be figurable
# [11:28] <Hixie> assuming we want to do that
# [11:28] <hsivonen> oh
# [11:30] <annevk> would <figure> <legend/> <object> <p>test </p> <p> test </p> </object> </figure> be ok?
# [11:30] <Hixie> who are you asking?
# [11:31] <hsivonen> annevk: IIRC, yes, provided that you put a required attribute on <object>
# [11:31] <annevk> k
# [11:32] <hsivonen> annevk: also, I haven't updated the significant inline stuff to deal with legend
# [11:34] <MikeSmith> Hixie - what's broken about accesskey?
# [11:36] <Hixie> what's not broken
# [11:36] <Hixie> it has never been implemented in a usable way
# [11:36] <Hixie> it isn't device independent
# [11:36] <Hixie> it isn't i18n-compatible
# [11:36] <Hixie> it isn't well specified
# [11:37] <annevk> chaals claims Opera now has a somewhat useful impl
# [11:37] <Hixie> shipped?
# [11:37] <Hixie> does he mean the modal toggle?
# [11:37] <annevk> yeah, I believe we expose the access keys of a page in a sidebar the user can invoke in some way
# [11:37] <annevk> maybe
# [11:37] <Hixie> steps to reproduce?
# [11:38] <annevk> maybe later, haven't played with it myself
# [11:40] <Hixie> well in opera 9.00 it isn't usable
# [11:42] <annevk> ah, Shift+Esc
# [11:42] <annevk> try that on my homepage for instance
# [11:43] <MikeSmith> Hixie - I think it's implemented is some mobile browsers, including Openwave's browser, and very widely used in mobile-specific sites
# [11:44] <Hixie> oh it's used
# [11:44] <Hixie> but all uses suffer from the problems i described
# [11:44] <MikeSmith> yeah, true
# [11:44] <Hixie> it's not too bad in walled-garden device-specific scenarios
# [11:44] <Hixie> but of course that's hardly what we care for here
# [11:44] <Hixie> annevk: again, not usable
# [11:45] <Hixie> anyway
# [11:45] <Hixie> bed time
# [11:50] <annevk> g'night
# [12:01] <MikeSmith> unfortunate fact about accesskey as far as mobile users go is that because it is something that's so widely used in mobile sites, if a content provider wants to move his site from being a walled garden/WAP site to being a Web site, lack of accesskey support is basically a regression in application behavior as far as they are concerned
# [12:01] <MikeSmith> or as far as users of their site will be
# [12:02] <MikeSmith> that's true for inputmode too (which most non-WAP browsers don't support)
# [12:05] <MikeSmith> at least here in Japan, sites use accesskey a lot, and users expect it on sites
# [12:06] <MikeSmith> Konqueror has accesskey support
# [12:07] <MikeSmith> if you press and release Ctrl, it shows tooltip text over each link, with letter of corresponding access key
# [12:09] <MikeSmith> I think if a site doesn't provide accesskey info in the markup, Konq actually generates accesskeys for the page
# [12:09] * Quits: met_ (n=Hassman@r5bx220.net.upc.cz) ("Chemists never die, they just stop reacting.")
# [12:10] <hasather> MikeSmith: yea, that seems to be the case
# [12:11] <hasather> wow, that's cool
# [12:17] <MikeSmith> Konqueror has a lot nice features
# [12:21] * Joins: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au)
# [12:52] * Joins: Philip` (n=excors@zaynar.demon.co.uk)
# [13:12] * Joins: mpt (n=mpt@121-72-128-156.dsl.telstraclear.net)
# [14:20] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [14:21] * Quits: ericcarlson_ (n=ericcarl@adsl-67-115-144-162.dsl.snfc21.pacbell.net)
# [14:37] * Parts: ravenn (n=ravenn@203-206-240-219.dyn.iinet.net.au)
# [16:21] * Joins: h3h (n=h3h@66-162-32-234.static.twtelecom.net)
# [16:32] * Joins: ericcarlson (i=ericcarl@nat/apple/x-facfe8654f493f1b)
# [16:32] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 104 (Connection reset by peer))
# [16:48] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [17:08] <annevk> zcorpan, <map> no longer has name=
# [17:17] * Joins: psa (n=yomode@posom.com)
# [17:25] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [17:25] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [17:29] * Joins: tylerr (n=tylerr@outbound.wa1.ascentium.com)
# [17:46] * Joins: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net)
# [18:03] * Quits: KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) ("off to work")
# [18:32] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [18:52] * Joins: tantek (n=tantek@dsl092-187-033.sfo1.dsl.speakeasy.net)
# [18:54] * Joins: aroben (i=adamrobe@nat/apple/x-4312f51e30858222)
# [19:19] * Quits: ericcarlson (i=ericcarl@nat/apple/x-facfe8654f493f1b)
# [19:20] * Joins: othermaciej (i=mjs@nat/apple/x-8df79b90936a30fd)
# [19:25] * Quits: aroben (i=adamrobe@nat/apple/x-4312f51e30858222) (Read error: 54 (Connection reset by peer))
# [19:26] * Joins: aroben (i=adamrobe@nat/apple/x-0791e4fa6fffbff7)
# [19:30] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
# [19:34] <Philip`> Since someone mentioned setTimeout: Mozilla passes the timeout handlers a ""secret" final argument that indicates timeout lateness in milliseconds". Is that already known, and is it at all relevant/interesting to anything, like whether it contradicts the spec and should be removed, or whether it should be adopted by the spec, or whether it's fine if nothing changes?
# [19:36] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [19:42] <othermaciej> that's pretty weird
# [19:47] <deltab> it's not mentioned on MDC
# [19:51] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 104 (Connection reset by peer))
# [19:52] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
# [19:52] <Philip`> http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#6818 is the only place I've seen it mentioned
# [19:54] <gavin_> I'm sure you'll be interested to know that that "secret argument" was in the original revision of nsGlobalWindow, 1.1 <kipp@netscape.com> 1998-07-15 18:16
# [19:55] <gavin_> good luck on finding the reason why it was added! :)
# [19:55] <othermaciej> does anything actually use it?
# [19:56] <othermaciej> seems like checking the current time will almost always be better than a lateness value
# [19:56] <gavin_> per rule #432, someone surely must :)
# [19:57] <gavin_> it's relatively well hidden, though, so maybe we could remove it
# [19:58] <gavin_> I'm not sure it's very useful
# [20:00] <deltab> oh, it is mentioned on MDC, on a talk page: http://developer.mozilla.org/en/docs/Talk:DOM:window.setTimeout
# [20:01] <gavin_> https://bugzilla.mozilla.org/show_bug.cgi?id=10637 has some background info
# [20:02] <gavin_> "It was very useful to *us* at Netscape in performance testing of animation
# [20:02] <gavin_> using intervals, since a script could detect when the CPU became saturated, i.e.
# [20:02] <gavin_> the timeout lateness was increasing monotonically with each timeout."
# [20:03] <Dashiva> A feature nobody knows about that was last used in NS4?
# [20:04] <deltab> and that complicates bindings to non-JS languages
# [20:09] * Joins: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks)
# [20:09] * Quits: dbaron (n=dbaron@c-71-198-189-81.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
# [20:19] * Joins: dbaron (n=dbaron@corp-242.mountainview.mozilla.com)
# [20:32] <Philip`> According to bug 263945 it is "an underdocumented feature", which seems like an understatement since the only documentation is the source code and the comments on two bug reports
# [20:39] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
# [20:45] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
# [20:47] * Quits: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net) (Client Quit)
# [20:48] * Joins: kingryan (n=kingryan@dsl092-187-033.sfo1.dsl.speakeasy.net)
# [20:50] * Quits: aroben (i=adamrobe@nat/apple/x-0791e4fa6fffbff7)
# [20:51] * othermaciej is now known as om_food
# [20:52] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
# [20:59] * Joins: KevinMarks (i=KevinMar@nat/google/x-c655862639c15cfa)
# [21:04] * Quits: tylerr (n=tylerr@outbound.wa1.ascentium.com) ("Leaving")
# [21:42] * Joins: jgraham (n=jgraham@81-178-84-187.dsl.pipex.com)
# [21:46] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
# [22:02] * Joins: aroben (i=adamrobe@nat/apple/x-dbb9c8610eedd3f5)
# [22:03] * Joins: aroben_ (i=adamrobe@nat/apple/x-57f496e78643a168)
# [22:15] * Quits: aroben (i=adamrobe@nat/apple/x-dbb9c8610eedd3f5) (Read error: 104 (Connection reset by peer))
# [22:15] * Joins: aroben (i=adamrobe@nat/apple/x-d0c838f4e9fb7867)
# [22:24] * Joins: mw22 (n=chatzill@guest-228.mountainview.mozilla.com)
# [22:26] * Quits: KevinMarks (i=KevinMar@pdpc/supporter/active/kevinmarks) ("The computer fell asleep")
# [22:30] * Quits: aroben_ (i=adamrobe@nat/apple/x-57f496e78643a168) (Read error: 110 (Connection timed out))
# [22:30] * Joins: KevinMarks (i=KevinMar@nat/google/x-8f9f98d49137a889)
# [22:31] * Joins: ericcarlson (i=ericcarl@nat/apple/x-8328bb595e090460)
# [22:37] * Joins: aroben_ (i=adamrobe@nat/apple/x-acd2bb5f0ade68a4)
# [22:40] <hsivonen> http://wiki.whatwg.org/wiki/Video_type_parameters in case anyone cares to continue
# [22:41] <Hixie> cool, thanks
# [22:42] <annevk> ouch
# [22:42] <annevk> looks amazingly complicated
# [22:43] <Hixie> welcome to video
# [22:43] <annevk> when I was welcomed there was <video>, three methods and a couple of .ogg files :)
# [22:43] <Hixie> hehe
# [22:45] <hsivonen> frankly, I think the codec RFC is way too hard for authors. if the codecs parameters is supposed to work, we need sniffer tools that take a file and print out the appropriate MIME type with the codecs parameter
# [22:46] <hsivonen> annevk: and I'm only covering sane and contemporary container/codec combos...
# [22:46] <annevk> hopefully we just have <video src=blah> for the majority of cases
# [22:47] <annevk> maybe the wiki page should document the signature of the files as well?
# [22:47] <hsivonen> annevk: feel free to edit. I'm never fully grokked how MP4-derived magic numbers are supposed to work
# [22:48] * Joins: SimonW (n=simon@dyn-62-56-54-4.dslaccess.co.uk)
# [22:48] <Hixie> i'm not a fan of the rfc either
# [22:48] <Hixie> but do we have something better?
# [22:49] <annevk> RFC42815
# [22:49] <Hixie> ?
# [22:49] <hsivonen> Hixie: nothing better that all the relevant vendors would agree to, no
# [22:49] <annevk> Hixie, last digit
# [22:49] <Hixie> what do you have that's better which vendors wouldn't agree to?
# [22:49] <Hixie> annevk: ?
# [22:49] <annevk> Hixie, oh, and it's a joke
# [22:50] <hsivonen> Hixie: mandated Ogg :-)
# [22:50] <annevk> and RFC4281 is the current RFC
# [22:50] <Hixie> annevk: oh i see
# [22:50] <Hixie> annevk: well even for that, we'd have to have something better to put _in_ that spec
# [22:50] <annevk> fair enough
# [22:50] <Hixie> hsivonen: no i mean for codec description. even if we mandate codec support, we can't disallow other codecs.
# [22:50] <Hixie> hsivonen: so ogg doesn't solve this problem.
# [22:51] <annevk> and we want authors to be able to provide multiple versions?
# [22:51] <hsivonen> Hixie: I know. but having one true codec would. but not gonna happen
# [22:51] <Hixie> christ, people in the csswg again trying to open new issues in things that aren't problems.
# [22:52] <Hixie> hsivonen: one true codec would not ever be a solution. there's no one codec that solves all problems. e.g. a codec that's good for screencaps isn't going to be good for slow moving video.
# [22:52] <Hixie> if there's a solution that really is better than 4281, i'm open to it
# [22:52] * om_food is now known as othermaciej
# [22:53] <annevk> so the answer to my question is yes?
# [22:53] <Hixie> yes
# [22:53] <othermaciej> hsivonen: now that I know more about it, it does sound way too hard
# [22:53] <Hixie> we'll be adding a media="" attribute to <source> anyway
# [22:53] <Hixie> which takes a media query
# [22:53] <hsivonen> Hixie: well, killing all the ISO profiles and using plain FourCCs in as codec identifiers would make things easier. but not gonna happen, either
# [22:54] <hsivonen> s/in as/as/
# [22:54] <Hixie> hsivonen: why wouldn't it happen? (i have no idea what FourCC is)
# [22:54] <annevk> Hixie, based on the beforeprint discussion?
# [22:54] <othermaciej> hsivonen: the codecs need to have comprehensible names
# [22:54] <Hixie> annevk: ? no
# [22:54] <othermaciej> FourCC is a four-character code
# [22:54] <annevk> Hixie, a use case for that came up there
# [22:54] * Quits: aroben (i=adamrobe@nat/apple/x-d0c838f4e9fb7867) (Read error: 110 (Connection timed out))
# [22:54] <Hixie> annevk: onbeforeprint will be added in due course.
# [22:54] <hsivonen> Hixie: because ISO has gone profile-crazy. too late to undo it, I think
# [22:54] <Hixie> hsivonen: ah
# [22:54] <Hixie> hsivonen: well if you have any solutions that actually would work, let me know :-)
# [22:55] <hsivonen> Hixie: a FourCC is a four-character identifier that you put in a container to identify the type of a data stream
# [22:55] <annevk> actually, if media="" is added to source you might want to add start end, etc. to <source> as well
# [22:55] <annevk> so for non interactive media you can start at a specific location
# [22:55] <Hixie> annevk: we're not trying to encourage different media being seent, if they have different timelines that's bad
# [22:55] <hsivonen> Hixie: so FourCC is kind of like an intra-file magic or HFS type code
# [22:56] <annevk> or show a specific frame, so to say (which is the use case that came up)
# [22:56] <Hixie> annevk: oh you're misunderstanding. this wouldn't be for screen vs print. it would be for highres vs lowres, or b&w vs color, etc
# [22:56] <Hixie> hsivonen: ah
# [22:56] <annevk> Hixie, k
# [22:57] * annevk goes to read the RFC
# [22:57] <hsivonen> If I had the power to fix MPEG-4, I'd have two video codecs: Visual Simple Profile without any levels or subprofiles and H.264 without any levels or subprofiles
# [22:58] <Hixie> hsivonen: so would you also introduce a new version every year as hardware improved?
# [22:59] <hsivonen> Hixie: At least I'd give the new version a different marketing name and FourCC instead of defining it as an Advanced Extended High 10:2:2 profile level 5.2 of something pre-existing
# [23:00] <Hixie> fair enough
# [23:00] <Hixie> so we'd have H.264, H.265, H.266, etc?
# [23:00] <hsivonen> Hixie: for example
# [23:00] <Hixie> makes sense
# [23:00] <Hixie> oh well
# [23:00] <Hixie> sadly we are not the ISO
# [23:02] <gsnedders> MPEG-5 anyone? :P
# [23:02] <Hixie> that's one that i will definitely NOT be ever doing
# [23:03] * gsnedders has absolutely no clue about the technical details of codecs
# [23:04] <annevk> at some point bandwidth will be less of an issue and all the linked files can simply be inspected...
# [23:05] <Hixie> i doubt that point will come any time soon
# [23:05] <Hixie> at least not in the next two or three decades
# [23:07] <annevk> isn't the required data not in the first few KiBs?
# [23:08] <Hixie> now scale that up by a billion and imagine what it would do to a site like youtube.
# [23:09] <Philip`> Would latency still be an issue, even if the bandwidth is insignificant?
# [23:09] * aroben_ is now known as aroben
# [23:09] <Hixie> that too
# [23:10] <hsivonen> what annevk said is more likely to work, though, than requiring authors to write codec identifiers
# [23:10] <Philip`> (unless you had a server-side script that quickly inspected all the files and then told the browser what they all were)
# [23:11] <hsivonen> I wouldn't dismiss magic-based sniffing and HTTP request closing as crazy when type parameters aren't available
# [23:11] <hsivonen> YouTube has staff to figure out RFCs
# [23:11] * Parts: ericcarlson (i=ericcarl@nat/apple/x-8328bb595e090460)
# [23:11] <Hixie> i don't think this will be used much on sites that don't have staff.
# [23:11] <Hixie> if you don't have staff, you'll likely just use one file.
# [23:11] * Joins: ericcarlson (i=ericcarl@nat/apple/x-787288ecc95c227e)
# [23:12] <hsivonen> Hixie: that's true
# [23:12] <hsivonen> though I don't have staff and I've provided dual videos: Theora and H.264
# [23:13] <Hixie> that's an easy one
# [23:13] <Hixie> don't even need codec="" for that
# [23:13] <hsivonen> right
# [23:13] <hsivonen> actually, you do
# [23:13] <Hixie> why? just stick ogg first
# [23:13] <hsivonen> what if Ogg contains Dirac and the UA supports Theora and H.264?
# [23:14] <Hixie> nobody supports dirac. it's not even done yet.
# [23:14] <hsivonen> or, rather, how's the UA going to know that the Ogg file contains Theora, not Theora
# [23:14] <Hixie> and why would you put dirac in an ogg container?
# [23:14] <annevk> because authors are silly?
# [23:14] <hsivonen> Hixie: I thought the plan was to put Dirac in Ogg
# [23:14] <Hixie> oh.
# [23:15] <Hixie> well then you use the codec value
# [23:15] <Philip`> http://wiki.xiph.org/index.php/OggDirac
# [23:15] <ericcarlson> I don't think this will really be such a big issue for authors
# [23:15] <hsivonen> Hixie: does that mean that you are going to define default codecs for containers?
# [23:15] <annevk> can't you have other things inside Ogg as well?
# [23:15] <Hixie> i'm open to better schemes, but requiring the browser to sniff the data stream is simply not a workable solution.
# [23:15] <Hixie> hsivonen: i'll probably put your wiki page in the spec in due course (or refer to it), but i'd rather just have a better solution.
# [23:16] <hsivonen> ericcarlson: I think it will be. How do I even figure out what AVC level QuickTime made when I encode?
# [23:17] <ericcarlson> People compressing media for the web export to a "profile" so they
# [23:17] <ericcarlson> know a class of user/devide will be able receive and decode it
# [23:17] <annevk> another problem with those codec= stuff is that authors will just copy and paste it and change the src= value and sometimes it will work and sometimes it won't (though arguably this is a minor issue)
# [23:17] <ericcarlson> When exporting you choose the profile, and that defines the parameters passed to the encoder
# [23:17] <hsivonen> ericcarlson: OK, if I check Baseline in QuickTime, how do I figure out what to put in the AVC level "xx" placeholder in Dave Singer's email?
# [23:18] <Hixie> for the people arguing that the current type="" codec= RFC4281 solution is bad: i agree. giving more reasons why it's not an optimal solution is not required. What's required is a more optimal solution.
# [23:18] <ericcarlson> and it defines the characteristics of the file that comes out the other end (bitrate, B-frames or not, size, etc)
# [23:19] <hsivonen> Hixie: I'm not arguing why it is bad. I'm trying to discover useful data that authors will need when they use it.
# [23:19] <Hixie> i was mostly talking to anne :-)
# [23:19] * Hixie would like to know the answer to your question too
# [23:19] <hsivonen> ericcarlson: How do I map QuickTime export dialog values to the RFC indentifiers?
# [23:23] <ericcarlson> hsivonen: which dialog values?
# [23:23] <hsivonen> Movie to MPEG-4, Options...
# [23:24] <Hixie> ericcarlson: if he checks Baseline in QuickTime, how can he figure out what to put in the AVC level "xx" placeholder in Dave Singer's email?
# [23:24] <hsivonen> dialog titled MPEG-4 Export Settings
# [23:25] <hsivonen> ericcarlson: there's no setting for AVC level
# [23:25] <ericcarlson> That information has to come out of the encoded file, so someone (me ;-) will have to write a utility
# [23:25] <hsivonen> ericcarlson: ok :-)
# [23:25] <Hixie> ew
# [23:26] <hsivonen> presumably Movie to iPod will lower the AVC level to a magic value (still without telling me)
# [23:27] <ericcarlson> Yes, but the level is chosen for you based on the "dial-able" parameters.
# [23:28] <ericcarlson> hsivonen: Yes, any preset that doesn't allow any parameter tweaking will be fixed.
# [23:31] <Hixie> i'm about to check in a big set of media/video/audio changes, if anyone wants to give it a look-see while i go grab some food to see if there are any mistakes, i'll fix them before checking in
# [23:31] <Hixie> page will be genned in about 60 seconds
# [23:32] <annevk> some of my reported bugs haven't yet been fixed
# [23:32] <annevk> no apparent visual bugs though
# [23:37] <Hixie> oh?
# [23:37] <annevk> HTMLSourceElement member names in the IDL
# [23:37] <annevk> haven't checked others
# [23:37] <Hixie> ooh, good catch
# [23:38] <annevk> attribute float currentLoop -> unsigned long currentLoop
# [23:38] <Hixie> cool
# [23:38] <Hixie> any others?
# [23:39] <annevk> not right away
# [23:39] <Hixie> hm, i forgot to define seekable
# [23:39] <ericcarlson> I don't see anything obvious
# [23:40] <annevk> in that case, you also forgot to define some events such as volumechange
# [23:40] <ericcarlson> Well, "position" still doesn't have the right name.
# [23:40] <Hixie> yeah name changes and events are next
# [23:40] <ericcarlson> OK
# [23:40] * annevk wonders what's wrong with position
# [23:41] * Joins: ajnewbold (n=fax_mach@unaffiliated/chuangtzu)
# [23:41] <Hixie> apple prefers currentTime, and nobody has argued anything else
# [23:41] <annevk> currentTime is hard to type
# [23:41] * annevk misspelled it while typing it in, even!
# [23:41] <Hixie> true, i often type it as currenTTime
# [23:42] <annevk> I forgot the first t
# [23:42] <Hixie> ericcarlson: what were the arguments for currentTime and against position, again?
# [23:43] <ericcarlson> It is a temporal property, and "position" doesn't really have meaning in the time domain.
# [23:43] <othermaciej> Hixie: "position" is more vague and sounds like it would be spacial, not temporal
# [23:43] <Hixie> ah yes, there you go
# [23:44] <annevk> I suppose "location" has the same issues?
# [23:44] <annevk> maybe more
# [23:44] <othermaciej> location sounds like it should be a URL
# [23:44] <Hixie> even worse, yeah
# [23:44] <Hixie> btw did we say that seeking to outside the current loop boundaries should clamp?
# [23:45] <ericcarlson> I think it should
# [23:45] <ericcarlson> For whatever that is worth.
# [23:45] * Joins: aroben_ (i=adamrobe@nat/apple/x-0ad9bde13e1cda01)
# [23:45] <annevk> and how about position -> time, currentLoop -> loop
# [23:46] <Hixie> that might work
# [23:46] <ericcarlson> "loop" sounds like a boolean
# [23:46] * Quits: aroben (i=adamrobe@nat/apple/x-acd2bb5f0ade68a4) (Read error: 104 (Connection reset by peer))
# [23:46] * Joins: aroben (i=adamrobe@nat/apple/x-8ec6a5f27e5b67a0)
# [23:48] <ericcarlson> The video element still fills with black
# [23:49] <Hixie> i haven't done any of the changes from our lunch
# [23:49] <othermaciej> time might be doable though it is a little more vague
# [23:49] <annevk> what should it be? transparent black?
# [23:49] <Hixie> annevk: should just use css background
# [23:49] <annevk> makes sense
# [23:50] <Hixie> though i think we should have video { background: black } in the UA stylesheet
# [23:50] <Hixie> personally
# [23:50] <Hixie> but that might just be me
# [23:51] <ericcarlson> sounds good for a page with a black background :-)
# [23:51] * Quits: hendry (n=hendry@91.84.53.136) ("leaving")
# [23:53] <annevk> I still think .position is a good pick as everybody will understand what it means and it's way easier to remember and type than .currentTime
# [23:53] <Philip`> Is it possible for the video content to be (semi-)transparent, so you'd need that background colour behind the video rather than just in the areas that don't contain the video?
# [23:53] <Hixie> jesus, just this update to use the new states rather than the old state system is a 2000 line patch
# [23:54] <Hixie> Philip`: if you count animated gifs as video, i guess
# [23:54] <othermaciej> Philip`: there are such things as codecs with alpha
# [23:54] <annevk> Philip`, it's possible with Flash
# [23:54] <annevk> prolly also with FLV
# [23:55] <annevk> Hixie, I suppose it's less than 2000 for /source?
# [23:55] <Hixie> no that was /source :-/
# [23:55] <Philip`> Okay - I just saw the currently-online version talks about "Areas of the element's playback area that do not contain the video should be filled with pure black", which doesn't seem to cover that case, though I don't know if that's been changed already
# [23:56] <Hixie> it's going to change
# [23:56] <Hixie> but later
# [23:56] <Hixie> :-)
# [23:56] <othermaciej> compositing onto the (possibly transparent) background seems like the right thing for alpha codecs
# [23:57] <Hixie> yeah
# [23:57] <annevk> HTMLSourceElement is still not changed fwiw
# [23:57] <Hixie> haven't regenned yet
# [23:57] <annevk> (I say this because currentLoop is)
# [23:57] <Hixie> oh
# [23:57] <Hixie> wait, what?
# [23:57] * Hixie looks again
# [23:57] <Hixie> oh, there was more broken than i thought
# [23:57] <Hixie> oops
# [23:58] <Hixie> oh heh
# [23:58] <Hixie> i fixed it the wrong way -_-
# [23:58] <KevinMarks> I've said for a while that Apple needs to invent a marketing name for h264
# [23:58] <KevinMarks> they're good at that
# [23:58] <othermaciej> iCodec
# [23:58] <othermaciej> (or Final Codec Pro?)
# [23:59] <KevinMarks> Pixlet Pro?
# [23:59] <annevk> iVideo
# [23:59] <KevinMarks> AVC/H264 is such a non-Apple name
# [23:59] <SimonW> hi all... I'm putting together a "what the heck is HTML 5" talk for a local geek event here in Oxford... is there anywhere online that explains the implications of the Apple <canvas> patent e-mail?
# [23:59] <KevinMarks> especially as the original QT codec from 1990 was called AVC
# [23:59] <SimonW> or is it safe to just ignore that bit?
# Session Close: Tue Apr 10 00:00:00 2007

The end :)