| 04:07 | <zcorpan_> | <meta http-equiv=content-access-control> should perhaps be allowed, as the html version of <?access-control?> |
| 06:08 | <Hixie> | zcorpan_: can't be an element, access control has to be done before you create the root element |
| 06:10 | <othermaciej> | you could use a pre-parser, but that's lame |
| 06:10 | <othermaciej> | that reminds me, I owe a review of access-control |
| 06:27 | <zcorpan_> | ok |
| 08:08 | <zcorpan_> | http://www.brucelawson.co.uk/index.php/2007/wcag-2-released/ |
| 08:13 | <Lachy> | that links to http://juicystudio.com/article/wcag2surpriserelease.php ... |
| 08:13 | <Lachy> | which links to http://accessify.com/news/2007/04/wcag-20-finally-here/ ... |
| 08:13 | <Lachy> | and then to ... http://boxofchocolates.ca/archives/2007/04/01/wcag2-a-done-deal ... |
| 08:13 | <othermaciej> | looks like they coordinated |
| 08:13 | <Lachy> | http://www.einfach-fuer-alle.de/blog/eintraege.php?id=2044_0_1_0 and finally back to Bruce Lawson's |
| 08:14 | <zcorpan_> | fishy eh |
| 08:14 | <Lachy> | it's an april fools joke |
| 08:14 | <zcorpan_> | yup |
| 08:14 | <zcorpan_> | othermaciej has another :) |
| 08:15 | <Lachy> | I got suspicious of that when I noticed that bruce didn't actually link to the new spec |
| 08:18 | <othermaciej> | who, me? |
| 08:18 | othermaciej | looks innocent |
| 08:19 | <zcorpan_> | hehe |
| 08:19 | zcorpan_ | looks forward to safari 3 using trident |
| 08:21 | <Lachy> | excellent! Now we just need Opera and Mozilla to drop their engines and adopt trident to, and we'll have 4 fully interoperable browsers! |
| 08:21 | <othermaciej> | apparently mozilla is adopting WebKit: http://burntelectrons.org/index.php?itemid=219 |
| 08:24 | <Lachy> | so when will apple begin shipping vista on all new macs? |
| 08:25 | <zcorpan_> | 1 april 2008 |
| 08:25 | <othermaciej> | I cannot comment on future product releases |
| 08:25 | hsivonen | goes find the latest RFC |
| 08:29 | <hsivonen> | doesn't IETF have an April 1 RFC this year at all? |
| 08:30 | <othermaciej> | maybe they have not posted it yet |
| 08:33 | <Lachy> | http://en.wikipedia.org/wiki/April_1st_RFC - they didn't post one last year either |
| 08:34 | <othermaciej> | maybe they decided it wasn't funny any more |
| 08:36 | <othermaciej> | haha, UTF-9 |
| 08:36 | <Lachy> | we should post something on whatwg blog. hmm. any ideas? |
| 08:37 | <othermaciej> | adopting XHTML2 might be too obvious |
| 08:37 | <Lachy> | that's what I thought |
| 08:37 | <othermaciej> | how about a new RDF serialization of HTML5? |
| 08:37 | <othermaciej> | probably also too obvious |
| 08:37 | <Lachy> | adopting the role attribute? |
| 08:38 | <othermaciej> | that might not be obvious enough :-) |
| 08:39 | <hsivonen> | a few years back Jukka Korpela wrote about a new version of HTML on April 1st, but, in reality, XSL-FO was pretty much like his joke... |
| 08:40 | <Lachy> | yeah, XHTML 3.0! |
| 08:40 | <hsivonen> | http://www.cs.tut.fi/~jkorpela/html/xhtml3.html |
| 08:42 | <hsivonen> | an N3 serialization for HTML5 would take the RDF idea a step further |
| 08:44 | <hsivonen> | (in general, I'm not a big fan of April Fools jokes polluting the information space) |
| 08:52 | <Hixie> | if someone posts an april 1st blog entry, they better have an april 2nd blog entry lined up |
| 08:53 | <Lachy> | why? To explain that the first was a joke? |
| 08:54 | <Hixie> | no, to not confuse people when april fools is over |
| 08:54 | <Lachy> | ok |
| 08:54 | <Hixie> | :-) |
| 09:26 | <ROBOd> | will someone post an April fools joke? :) |
| 09:26 | <Lachy> | if someone comes up with a good idea for one |
| 09:27 | <mjshtml> | Hixie to be replaced as HTML5 editor by Chris Wilson |
| 09:27 | <Lachy> | LOL! |
| 09:27 | <ROBOd> | "The WHATWG will disolve given that Chris Wilson has taken over doing a great job" (scary joke) |
| 09:28 | <Lachy> | who wants to write it? |
| 09:28 | <mjshtml> | or Steven Pemberton, take your pick |
| 09:28 | <mjshtml> | maybe that can be the 4/2 clarification |
| 09:29 | <Lachy> | nah, Steve's doing a great job with XHTML2. Chris is more believable since he's actually joining the HTMLWG |
| 09:30 | <mjshtml> | "doing a great job with XHTML2" |
| 09:30 | <mjshtml> | parse error |
| 09:31 | <hsivonen> | people may take a Chris Wilson joke too seriously |
| 09:31 | <hsivonen> | RDF fun is safer |
| 09:32 | <mjshtml> | Chris Wilson may take a Chrisl Wilson joke too seriously |
| 09:32 | <Lachy> | I don't know RDF well enough to write anything about it |
| 09:32 | <ROBOd> | "Due to many complaints we've decided rewrite the entire HTML 5 specification, from scratch" |
| 09:32 | <mjshtml> | I think it would be funny if written right, you just have to get more outrageous as you go along |
| 09:32 | <mjshtml> | start believable and work your way up |
| 09:33 | <ROBOd> | mjshtml: exactly |
| 09:36 | <Lachy> | what about a reason for Hixie no longer doing it? Lack of time? motivation? support? illness? something else? |
| 09:36 | <ROBOd> | another joke .. but this might be also taken too seriously and it's quite subtle: start from this email http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/002069.html |
| 09:38 | <hsivonen> | I think writing the spec from scratch with outrageous technical details is the best one so far (I'd avoid stuff that might start serious PR problem rumors. like Hixie getting sick or legal stuff) |
| 09:38 | <ROBOd> | yes |
| 09:38 | <Lachy> | how about adopting XForms Transitional? |
| 09:39 | <ROBOd> | Lachy: just looked yesterday at XForms Transitional... uhm... that's soo "very" Web Forms2 (IIANM) |
| 09:39 | <ROBOd> | (besides being still a work in progress...) |
| 09:40 | <hsivonen> | XForms Transitional, XSL-FO, RDF, XHTML 2.0, W3C XML Schema, SOAP, ... |
| 09:40 | <mjshtml> | forget XForms Transitional, how about straight-up XForms? |
| 09:40 | <Lachy> | XForms transitional does seem to be an effort to rewrite WF2 from scratch |
| 09:40 | <ROBOd> | Lachy: what's the use? |
| 09:40 | <mjshtml> | the <style> element will no longer contain CSS, instead it will include an inline XSLT stylesheet |
| 09:40 | <Lachy> | the use of what? |
| 09:41 | <mjshtml> | the global href attribute from XHTML2 will be replaced by a global xlink:href attribtue from XLink |
| 09:41 | <ROBOd> | Lachy: of rewriting from scratch WF2? |
| 09:41 | <Lachy> | I don't know, ask DanC |
| 09:41 | <mjshtml> | the global src attribute will also be replaced by a global xlink:href attribute from XLink |
| 09:41 | <ROBOd> | Lachy: he's not around :) |
| 09:41 | <mjshtml> | it writes itself |
| 09:41 | <mjshtml> | actually, DaveR would be the one to ask |
| 09:42 | <Lachy> | oh, yes, sorry |
| 09:42 | <ROBOd> | mjshtml: yes, Dave Ragget? |
| 09:42 | <mjshtml> | yes |
| 09:42 | <othermaciej> | he invented it |
| 09:42 | <hsivonen> | HTML5 will be rewritten from scratch to separate semantics (RDF) from presentation (XSL-FO) and behavior (the XML script thing from XForms). the normative schema will be in XSD and the for enterprise-readiness, the transport will be SOAP with WS-Security for making it bullet-proof |
| 09:44 | <ROBOd> | hsivonen: for it to be a good joke, you must reference some Microsoft proprietary format :) |
| 09:44 | <hsivonen> | ROBOd: it can be deployed today thanks to WPF/E? |
| 09:44 | <othermaciej> | hah |
| 09:45 | <ROBOd> | "HTML 5 will be based off the new ISO standard by Microsoft: Office Open XML" |
| 09:45 | <othermaciej> | haha |
| 09:45 | <othermaciej> | the problem with redesigning HTML in a bad way is it's hard to fit in all the possible bad technologies |
| 09:45 | <ROBOd> | 90% of the users will have support for viewing the documents |
| 09:46 | <ROBOd> | othermaciej: exactly, so pick one really bad. OOXML :) |
| 09:48 | <ROBOd> | advantages must also be stated clearly: "1. market penetration (even your secretary knows how to view and edit such OOXML documents). 2. we firmly believe that this ISO standard is written for better interoperability between implementations, making life easier for developers and users." |
| 09:48 | <ROBOd> | and 3. we do not really want to reinvent the wheel :) |
| 09:49 | <othermaciej> | hah |
| 09:50 | <hsivonen> | ROBOd: you can have the best of both worlds by defining an XSLT mapping between OOXML and RDF/XSL-FO |
| 09:50 | <ROBOd> | hsivonen: hahahaha, exactly that's what i was writing! |
| 09:50 | <ROBOd> | lol |
| 09:51 | <Lachy> | ROBOd, are you writing the post? |
| 09:51 | <ROBOd> | the greatest advantage is you can use only one can XSLT to convert your HTML4 (error on purpose) to OOXML HTML5, and vice-versa |
| 09:51 | <othermaciej> | maybe it should use a combination of GRDDL and XSLT |
| 09:51 | <othermaciej> | GRDDL to generate RDF, and XSLT to generate XSL-FO |
| 09:52 | <ROBOd> | Lachy: yeah :). how can I do this? |
| 09:52 | <ROBOd> | if you want i can write it |
| 09:52 | <ROBOd> | (i am not *writing* it as we speak, of course) |
| 09:52 | <Lachy> | go for it |
| 09:53 | <ROBOd> | Lachy: do i have to signup somewhere and login? or i shall write the HTML document and send it to you via email? |
| 09:54 | <Lachy> | just write it, put a draft somewhere so we can review it, then I can publish the final version for you |
| 09:54 | <ROBOd> | Lachy: ok, will do |
| 09:54 | <Lachy> | or you can just register on blog.whatwg.org and do it yourself |
| 09:54 | <ROBOd> | i suppose it doesn't have to be long :P (the blog post) |
| 09:55 | <Lachy> | no, just 2 or 3 paragrahs should be sufficient |
| 09:56 | <ROBOd> | yes |
| 09:57 | <Lachy> | is anyone able to understand this? http://www.w3.org/mid/711a73df0704010055i13fe8c38vc710cb1016f6e344⊙mgc |
| 09:57 | <hsivonen> | the serialization could be OOXML but the *architectural model* could be RDF/XSL-FO/XForms-script-thing |
| 09:58 | <othermaciej> | hah |
| 09:58 | <othermaciej> | make sure to work in the word "backplane" |
| 10:00 | <hsivonen> | Lachy: assuming that Dave P isn't joking today, I am rather surprised by his position |
| 10:04 | <Lachy> | I just don't understand why downstream processijng of xml requires validation, or what versioning has to do with that |
| 10:05 | <hsivonen> | Lachy: it requires validation if your processing code barfs on invalid stuff |
| 10:06 | <hsivonen> | Lachy: what I don't understand is how versioning saves you in that case |
| 10:06 | <hsivonen> | Lachy: basically, validating first allows for less robust Java/Python/whatever code |
| 10:06 | <Lachy> | I also don't understand what that has to do with HTML and CSS, which the thread is about |
| 10:06 | <hsivonen> | Lachy: since the code can assume the doc met the constraints already |
| 10:07 | <hsivonen> | Lachy: Dave P is an XML guy, so perhaps he isn't thinking about a browser use case but a semi-private system use case |
| 10:09 | <ROBOd> | done |
| 10:09 | <ROBOd> | the document is available locally... i don't like pasting links on the channel (it's logged) |
| 10:09 | <ROBOd> | Lachy: can I PM you? |
| 10:09 | <Lachy> | sure |
| 10:09 | <ROBOd> | thanks |
| 10:10 | <hsivonen> | Lachy: can I see it as a draft in WP? |
| 10:10 | <Lachy> | yeah |
| 10:11 | <ROBOd> | erm, there are some typos and grammar errors :) |
| 10:13 | <hsivonen> | whoa: http://www.w3.org/TR/backplane/ |
| 10:13 | <Lachy> | Should we call it HTML6 intead? |
| 10:14 | <othermaciej> | did you mention the backplane? |
| 10:14 | <othermaciej> | it's essential for maximum ludicrousness value |
| 10:14 | <hsivonen> | enterprise-strength backplane |
| 10:14 | <Lachy> | people might find it hard to believe that we're dropping everything we've already done, it would be more believable if they think it's the future replacement |
| 10:14 | <ROBOd> | othermaciej: change the article, if you have access |
| 10:14 | <othermaciej> | people will believe anything |
| 10:15 | <othermaciej> | I don't |
| 10:15 | <ROBOd> | Lachy: good point |
| 10:16 | <hsivonen> | Lachy: dropping everything is good |
| 10:16 | <ROBOd> | name it HTML 6 ... "we are now planning for the future HTML 6, since ... HTML 5 is already being worked on by the W3C" |
| 10:16 | <hsivonen> | Lachy: otherwise HTML5 needs to become HTML6 Transitional |
| 10:16 | <Lachy> | hsivonen, that would be DaveR's job |
| 10:16 | <ROBOd> | :) |
| 10:17 | <hsivonen> | the good thing with global warming is that ocean boiling requires less additional energy |
| 10:18 | <ROBOd> | Lachy: let me know when the joke is posted :) |
| 10:19 | <Lachy> | I'm just making a few modifications to call it HTML6 and change the first paragraph accordingly |
| 10:19 | hsivonen | hopes the X people won't get too bitterly offended |
| 10:19 | <Lachy> | othermaciej, I don't know what to say about the backplane |
| 10:19 | <Lachy> | hi annevk |
| 10:19 | <ROBOd> | Lachy: just say something about the b*l*ackplane |
| 10:19 | <ROBOd> | :) |
| 10:19 | <hsivonen> | Lachy: I can try to work the backplane in |
| 10:20 | <Lachy> | ok, I'll save the draft |
| 10:21 | hsivonen | looks |
| 10:21 | <annevk> | maybe we should have something about the UN negotiating a truce between the W3C and WHATWG? |
| 10:21 | <othermaciej> | Lachy: what you say doesn't have to mean anything |
| 10:21 | <othermaciej> | that's the key |
| 10:21 | <othermaciej> | "backplane" means whatever you want it to mean |
| 10:21 | <annevk> | othermaciej, btw, review the dev.w3.org version of access-control, not the thing published on /tr/ |
| 10:22 | <hsivonen> | ok if I work in a bit more X stuff along the lines I said earlier? |
| 10:22 | <ROBOd> | Lachy: in the advantages say ... |
| 10:22 | <annevk> | "backplane" is the XForms data model + more of where that came from |
| 10:22 | annevk | isn't sure what the XForms data model is, exactly |
| 10:23 | <ROBOd> | "Having XML as the backplane, developers will see the immediate benefit of using their existing XML parsers and serializers" |
| 10:23 | <annevk> | you want "XML toolchain" I think |
| 10:24 | <ROBOd> | annevk: xforms doesn't fit into the OOXML archtecture model |
| 10:24 | <annevk> | yeah, well, what does? |
| 10:24 | <Lachy> | annevk, HTML6 does, apparently :-) |
| 10:24 | <ROBOd> | annevk: yeah, whatever :) ... the XML toolchain, saw fit to use parser and serializer |
| 10:25 | <annevk> | maybe we should also state something that's not a joke |
| 10:25 | <annevk> | after HTML5 we'll focus on SVG5 |
| 10:28 | <ROBOd> | "We also sent a proposal to the CSS WG: we would like CSS 4 to marry the syntax of XSLT and the power of CSS" (lol) |
| 10:28 | <ROBOd> | css3-syntax-sugar :) |
| 10:29 | <ROBOd> | (which is available as a css 3 module; future revisions becoming css 4) |
| 10:30 | <hsivonen> | still editing |
| 10:31 | <ROBOd> | :) |
| 10:33 | <annevk> | you mean the syntax of XSL-FO |
| 10:33 | <annevk> | XSLT is sort of orthogonal to CSS at this point |
| 10:34 | <ROBOd> | annevk: hence... the idea :) |
| 10:35 | <ROBOd> | annevk: i also stated that XSLT can be used to transform HTML4 to HTML 6 OOXML :) |
| 10:35 | <ROBOd> | a simple XSLT document, that is |
| 10:35 | <hsivonen> | ok. I worked in some more buzzwords |
| 10:36 | <ROBOd> | but keep it believable :) at least for newbies :) |
| 10:36 | <hsivonen> | minor edit still |
| 10:36 | <hsivonen> | Lachy: did you intend to publish take two tomorrow? |
| 10:37 | <hsivonen> | still a bit more editing |
| 10:38 | <Lachy> | oh, oops, I meant to take that out of the draft. ROBOd added that for tomorrows post, but I don't think we need it. |
| 10:38 | <hsivonen> | done |
| 10:38 | <Lachy> | we could just publish something on a more serious topic |
| 10:38 | <Lachy> | like <video> |
| 10:39 | <hsivonen> | Lachy: do you approve of my edits? are they offensive? |
| 10:39 | <annevk> | seen http://www.google.com/tisp/ already? |
| 10:39 | <ROBOd> | annevk: yeah, kinda ... weak |
| 10:39 | Lachy | looks |
| 10:40 | <ROBOd> | i liked http://www.google.com/tisp/notfound.html |
| 10:42 | <annevk> | heh http://groups.google.com/group/google-tisp/ |
| 10:43 | <hsivonen> | Lachy: FWIW, I think what I wrote is pretty tame compared to real suggestions. the potentially offensive part is framing stuff that reads like real suggestions as a joke |
| 10:45 | <Lachy> | it's funny. Most people will find it believable because they have no idea what on earth you're talking about :-) |
| 10:46 | <annevk> | do we have multiple posts? |
| 10:46 | <Lachy> | I took out the take two section aswell |
| 10:46 | <Lachy> | no, just the one on blog.whatwg.org |
| 10:47 | <hsivonen> | Lachy: are you editing still? I suggest chaging "integration with SOAP-based" to "binding with..." |
| 10:47 | othermaciej | looks forward to seeing it |
| 10:47 | annevk | too |
| 10:47 | <Lachy> | hsivonen, fixed |
| 10:48 | <hsivonen> | Lachy: thanks |
| 10:48 | <annevk> | "Founded in 1998 by Stanford Ph.D. wannabes Larry Page and Sergey Brin," |
| 10:51 | <Lachy> | I think it's ready to publish, unless you have any last minute changes |
| 10:51 | <Lachy> | I changed the title to Plans for HTML6 |
| 10:51 | <hsivonen> | Lachy: the second to last paragraph isn't funny enough, but I don't have good fixes |
| 10:53 | <hsivonen> | afk. |
| 10:53 | <othermaciej> | if someone sends by privmsg I can make suggestions |
| 10:53 | <othermaciej> | or y'all can just post it, I'm sure it's amusing enough |
| 10:53 | <ROBOd> | othermaciej: agreed |
| 10:53 | <Lachy> | I'll put it online temporarily for those of you without blog accts... |
| 10:54 | <ROBOd> | registered |
| 10:55 | <Lachy> | you probably won't be able to see it cause your not its editor or an admin |
| 10:55 | <annevk> | you can also just publish it and make changes later... |
| 10:56 | <ROBOd> | ah, yes |
| 10:57 | <othermaciej> | the only change I'd make is to remove "The above being said, " |
| 10:58 | <othermaciej> | it's pretty amusing |
| 10:58 | <ROBOd> | it's pretty good |
| 10:58 | <Lachy> | othermaciej, done |
| 10:58 | <ROBOd> | good additions |
| 11:06 | <ROBOd> | still editing? |
| 11:06 | <hsivonen> | Using a fairly simplistic XSLT should probably be "Using a fairly simplistic XSLT style sheet" |
| 11:09 | <hsivonen> | let's ship it! |
| 11:09 | <Lachy> | hsivonen, done. |
| 11:10 | <hsivonen> | Lachy: thanks |
| 11:11 | <othermaciej> | is it there yet? |
| 11:13 | <Lachy> | just making a few minor changes that annevk PM'd me |
| 11:14 | <Lachy> | http://blog.whatwg.org/html6-plan |
| 11:14 | <annevk> | I think we should have something like "reveal our behind-closed-doors-decided plans ..." |
| 11:14 | <hsivonen> | thanks to everyone who participated |
| 11:16 | <ROBOd> | :) |
| 11:16 | annevk | submits a comment |
| 11:16 | <othermaciej> | lol |
| 11:16 | <ROBOd> | annevk: already did |
| 11:17 | <ROBOd> | seriously now... any ETA? |
| 11:17 | <ROBOd> | lol |
| 11:17 | <Lachy> | annevk, lol! |
| 11:18 | <ROBOd> | i think the use of WHATTF name adds to the point :) |
| 11:18 | <hsivonen> | http://whattf.org/ |
| 11:18 | <Lachy> | oh crap, we got the expansion wrong for WHATF |
| 11:18 | <Lachy> | *WHATTF |
| 11:18 | <ROBOd> | hsivonen: precisely |
| 11:21 | annevk | changes topic to 'WHATWG (HTML6) -- http://www.whattf.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 11:21 | annevk | changes topic to 'WHATTF (HTML6) -- http://www.whattf.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 11:21 | <ROBOd> | :) |
| 11:46 | <ROBOd> | we have the HTML 6 plans blog post, the HTML 6 topic, .... we only need a HTML 6 thread on the mailing list |
| 11:47 | <hsivonen> | I think the blog comment work better today than email |
| 11:48 | <ROBOd> | someone digg&slashdot the article |
| 11:51 | <ROBOd> | i have to go now, i'll be back later |
| 11:57 | <Lachy> | it would be funny if it made slashdot and people thought it was sersious :-) |
| 12:51 | <Dashiva> | "A++++ would implement again" |
| 12:51 | <Lachy> | what? |
| 12:52 | <Dashiva> | I was just thinking of a comment for the HTML6 post |
| 12:56 | met_ | just read about HTML 6 |
| 13:00 | <hsivonen> | hmm. I have 21 slides for a 15-minute presentation about HTML5 conformance checking |
| 13:01 | <hsivonen> | have to practice some more to squeeze it a bit |
| 13:01 | <Lachy> | that should be enough |
| 13:01 | <Lachy> | how long are you spending on each slide? |
| 13:01 | <hsivonen> | slightly less than a minute on average. my last practice run was 18 minutes |
| 13:02 | <annevk> | wow, that's a lot of slides |
| 13:02 | <hsivonen> | yes :-( |
| 13:02 | annevk | had eight / nine for a twenty minute presentation |
| 13:02 | <hsivonen> | but these are Keynote slides not PowerPoint slides |
| 13:03 | <annevk> | what does that mean? one word per slide? |
| 13:03 | <hsivonen> | annevk: something like that :-) |
| 13:03 | <hsivonen> | I have 5 slides up front about what HTML5 and WHATWG are |
| 13:03 | <hsivonen> | I think I should try to squeeze that part |
| 13:04 | <Lachy> | can we see the slides? |
| 13:04 | jgraham | has managed both 40 minute talks on <30 slides and 17 minute talks on 25 slides... |
| 13:04 | <Lachy> | oh, never mind, I don't have keynote anyway |
| 13:05 | <hsivonen> | Lachy: http://hsivonen.iki.fi/thesis/dippaesitelma.pdf |
| 13:05 | <Lachy> | hmm. Apparently a trial version of keynote came with my mac. Nice! |
| 13:07 | <jgraham> | hsivonen: Do you know the projector you're using? We have one with an odd issue with white-on-black (move your head and you see rainbows) |
| 13:07 | <hsivonen> | jgraham: I don't |
| 13:07 | <hsivonen> | jgraham: I could make an inverted backup |
| 13:08 | <jgraham> | I've only ever seen the problem with this one projector but it is quite annoying... |
| 13:10 | <hsivonen> | perhaps I should get rid of references to the WHATWG and not explain the context on that level |
| 13:13 | <hsivonen> | pruned to 18 slides |
| 13:13 | <Lachy> | which ones did you take out? |
| 13:13 | <hsivonen> | the ones about the WHATWG and new and old features |
| 13:14 | <hsivonen> | not that relevant to the implementation of conformance checking |
| 13:14 | <Lachy> | yeah, I was going to suggest those because they're not relevant |
| 13:35 | <hsivonen> | when I had the presentation about Gecko bug 18333, I made sure that I don't go overtime and then I was too quick... |
| 13:47 | <hsivonen> | I wonder if there a drop-in color invert filter for Quartz... |
| 19:20 | <Hixie> | i think i know why i'm uncomfortable with the proposed ready states |
| 19:20 | <Hixie> | they don't all apply to audio |
| 19:25 | <Hixie> | also, i don't like the idea of a readyState-like API not only incrementing |
| 19:43 | <virtuelv> | Hixie: huh? care to elaborate (about readyStates incrementing) |
| 19:43 | <Hixie> | for <video> |
| 19:43 | <Hixie> | http://webkit.org/specs/HTML_Timed_Media_Elements.html#mediastatus |
| 19:44 | <virtuelv> | I got that part, but why are you uncomfortable with a non-incremental value for readyState? |
| 19:48 | <virtuelv> | (if anything, I'm a bit uncomfortable not being able to predict when the buffer will be empty beforehand |
| 19:49 | <Hixie> | the proposal from apple has the state going 0..2..3..4..2..3..2..3..4..5..2..3..4..2..6 |
| 19:49 | <Hixie> | instead of 0..1..2..3..4..55 |
| 19:50 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#media is what i'm thinking of using |
| 19:50 | <Hixie> | (not yet specced out) |
| 19:50 | <Hixie> | (just in the idl) |
| 19:53 | <annevk> | loaded is 10 because you expect many more states at some point? |
| 19:53 | <Hixie> | actually loaded was 10 in order to have the buffered and networking states in sync |
| 19:53 | <Hixie> | but screw that |
| 19:54 | <Hixie> | we don't need loaded and partial under buffering |
| 19:56 | <annevk> | so which states don't make sense for audio? |
| 19:57 | <Hixie> | pausable |
| 19:57 | <Hixie> | but i think we'll deal with it |
| 19:58 | <annevk> | also, how about replacing .seek() with a read/write .position |
| 19:59 | <virtuelv> | again, what worries me a bit is that there's insufficient information in both suggestions to determine when to start playing back and be guaranteed a skip-free playback |
| 19:59 | <annevk> | that will also allow you to do the theoretical .advance() easily |
| 19:59 | <annevk> | virtuelv, i think ENDABLE is for that |
| 20:00 | <virtuelv> | annevk: that is not neccesarily always what you want |
| 20:00 | <virtuelv> | the latency for that might be too long, depending on the length of the media |
| 20:01 | <Hixie> | yes seek() is going away |
| 20:01 | <Hixie> | one thing at a time |
| 20:03 | <Hixie> | virtuelv: the state will become ENDABLE when the UA believes that at the current buffering rate, you'll be able to reach the end just as the end is downloaded. |
| 20:03 | <Hixie> | is that what you meant? |
| 20:09 | <virtuelv> | it is what I meant, but you can't always guarantee that endable is a definite state |
| 20:10 | <Hixie> | could you elaborate? |
| 20:10 | <virtuelv> | someone might, for instance, start a download at the same time, at which point the movie will no longer be endable |
| 20:10 | <Hixie> | yup, then the state will no longer be that |
| 20:12 | <Hixie> | what information would you want instead? |
| 20:14 | <virtuelv> | usually, someone streaming media will know the size and duration of the media, and knowing exactly how much is in the browser's buffer/cache and the current download rate would make more sense to me |
| 20:15 | <Hixie> | that information is already available in the api |
| 20:42 | <othermaciej> | Hixie: what you came up with seems pretty complicated |
| 20:42 | <othermaciej> | Hixie: three separate state enums? |
| 20:43 | <othermaciej> | plus a bunch of booleans |
| 20:43 | <othermaciej> | I think the only one of Apple's states that might not apply to pure audio is PRESENTABLE |
| 20:49 | <Hixie> | i removed a bunch of hte booleans that were there before actually |
| 20:50 | <Hixie> | the only real difference between this and the apple proposal is the splitting of the 'state' into two, one for network state, and one for the ready state |
| 20:50 | <Hixie> | which are orthogonal anyway |
| 20:50 | <Hixie> | since 'ready' state can be affected by things like seeking even when the whole file is downloaded |
| 20:51 | <othermaciej> | that and you made playback state a quad-state instead of a boolean |
| 20:51 | <Hixie> | well that was there before |
| 20:51 | <Hixie> | you need it to be quadstate, otherwise you don't know when to show the "i'm _trying_ to play!" spinner |
| 20:52 | <othermaciej> | you could just say paused reflects only the user-chosen playback state |
| 20:53 | <othermaciej> | I'm not sure there's a need to reflect EMPTY vs. PAUSED (in purely playback terms, as opposed to the EMPTY state in the two other concepts of state) or PLAYING vs. WAITING |
| 20:54 | <othermaciej> | wouldn't the state of the controls be exactly the same in case of the latter two? |
| 20:55 | <Hixie> | the controls would be, but in waiting you'd have a spinner |
| 20:55 | <Hixie> | this is something that the quicktime and frontrow renderers do really badly actually |
| 20:55 | <othermaciej> | you would? |
| 20:55 | <Hixie> | they just freeze when they're seeking or buffering, with no indication to the user that they're working and not locked up |
| 20:56 | <Hixie> | obviously there's no requirement that the author provide such a ui |
| 20:56 | <Hixie> | but it should at least be possible |
| 20:56 | <othermaciej> | as does YouTube |
| 20:56 | <othermaciej> | and Google Video |
| 20:56 | <othermaciej> | does anyone's actual UI show a spinner in such a case? |
| 20:57 | <Hixie> | those two at least shows the buffered bar, so there's some indication of why it's paused |
| 20:57 | <othermaciej> | yes, so does QuickTime |
| 20:58 | <othermaciej> | that's kind of the de facto standard for such things |
| 20:58 | <Hixie> | well for some reason i am much more often confused as to whether quicktime is locked up or not |
| 20:58 | <Hixie> | in any case, i don't see the disadvantage of exposing this information. Is it hard to implement or something? |
| 20:59 | <othermaciej> | no, it's just more complicated to use |
| 20:59 | <othermaciej> | since you have extra states that don't relate to anything you'd do in the UI |
| 20:59 | <Hixie> | how about if i make paused = 0 and playing and waiting 1 and 2 respectively |
| 20:59 | <Hixie> | then you can do if (video.playing) |
| 20:59 | <Hixie> | or playbackState or whatever it's called |
| 21:01 | <othermaciej> | the fact that "waiting" is useful only for a UI idea you had that no one actually uses makes me doubt it should be overloaded onto the same variable that tells you playing vs. paused |
| 21:01 | <Hixie> | i suggested having two booleans and you were against that too |
| 21:03 | <othermaciej> | well, Apple's proposal gives you enough info to tell if you are really advancing in time without having a specific state value or bool for it, since it is of marginal value for reflection in the UI |
| 21:04 | <othermaciej> | I'm not sure if your version still does, since I don't know what the states mean or what the allowed transitions are |
| 21:04 | <othermaciej> | but I gotta say that three separate state enums, all of which are primarily useful to tell you what actions are allowed now, triggers my complexity overload alert |
| 21:05 | <Hixie> | well it's a complicated problem |
| 21:05 | <Hixie> | the three states are orthogonal |
| 21:06 | <Hixie> | (regarding the rate thing -- that part of the apple proposal wasn't really clear to me) |
| 21:06 | <Hixie> | (i couldn't work out what values the currentRate would have other than 0 and the playbackRate, at which point it is exactly the same as a boolean) |
| 21:06 | <Dashiva> | As long as a "basic user" can ignore most of the states and still get a sensible interface, the complexity isn't necessarily bad |
| 21:06 | <othermaciej> | Hixie: you could tell even without looking at the rate, since you can see whether your current state is playable, and if you are not paused; only if both are true are you actually advancing |
| 21:06 | <Hixie> | (and i don't see that two booleans, playing and 'playbackRate', which can never be false and true respectvely, is better than a three-state attribute) |
| 21:07 | <Hixie> | "(playable || endable) && (!paused)" |
| 21:08 | <Hixie> | and even that's not true, because in the autoplay case you'll wait for endable, not playable |
| 21:08 | <othermaciej> | video.readyState < PLAYABLE && !video.paused is your WAITING state |
| 21:08 | <othermaciej> | in the autoplay case, you are paused until autoplay starts |
| 21:08 | <Hixie> | so paused _isn't_ the user's state. |
| 21:08 | <othermaciej> | (that's how it should be anyway, since the user should still be able to hit "play" early) |
| 21:08 | <Hixie> | how can the user prevent autoplay then? |
| 21:09 | <othermaciej> | you can't |
| 21:09 | <Hixie> | ... |
| 21:09 | <othermaciej> | you have to hit pause after it autoplays |
| 21:09 | <othermaciej> | unless there is some special control for it |
| 21:09 | <Hixie> | what would the control do? |
| 21:09 | <othermaciej> | that's how things that autoplay work now |
| 21:09 | <othermaciej> | no idea |
| 21:09 | <othermaciej> | remove the "autoplay" attribute? |
| 21:10 | <Hixie> | so autoplay would be implemented as a default action of the transition to endable? |
| 21:10 | <Hixie> | i guess that could work |
| 21:10 | <othermaciej> | I really don't like endable as a name either |
| 21:10 | <Hixie> | (i'm not sure designing the api around current UIs to the exclusion of better UIs is good design, though) |
| 21:10 | <othermaciej> | it implies the author or user could take the action of ending in that state |
| 21:10 | <Hixie> | the names can be sorted out later |
| 21:11 | <othermaciej> | well, some of the names actively confuse me |
| 21:11 | <othermaciej> | I don't know what pausable means |
| 21:11 | <Hixie> | same as your presentable |
| 21:11 | <othermaciej> | I don't know what the distinction between "loading" and "buffering" is (aren't the two words basically synonymous in normal computer use?) |
| 21:11 | <Hixie> | loading = we don't have metadata, buffering = we do have metadata |
| 21:12 | <Hixie> | i'm open to any name changes |
| 21:13 | <othermaciej> | let's set aside the name changes right now and talk about the actual states and transitions first |
| 21:13 | <gsnedders> | does anything apart from Gecko trunk support getElementsByClassName? |
| 21:14 | <othermaciej> | my net connection is too fast because even on the QuickTime trailers site I can't find in-page video that's large enough that it doesn't autoplay promptly |
| 21:14 | <othermaciej> | was gonna give a link to an example of such |
| 21:15 | <Hixie> | oh i've seen that ui often |
| 21:15 | <Hixie> | drives me crazy |
| 21:15 | <Hixie> | i can't go through opening a bunch of videos in tabs and go through and pause them all before they play |
| 21:16 | <Hixie> | because if i hit pause, they play instead. |
| 21:16 | <Hixie> | but i agree that that's ok |
| 21:16 | <Hixie> | we can do autoplay as a default action from the paused state when you transition to 'endable' |
| 21:16 | <othermaciej> | I think that is true of all autoplaying UIs (though I don't have a dialup connection handy to test it for youtube) |
| 21:17 | <othermaciej> | in Safari we don't start plugins in background tabs so they won't play until you switch to the tab anyway |
| 21:17 | <Hixie> | they won't start downloading either |
| 21:17 | <Hixie> | so i have to go to the tab to start the download, then start them, then pause them |
| 21:17 | <Hixie> | it's annoying |
| 21:17 | <othermaciej> | that is true |
| 21:17 | <Hixie> | then when i'm ready i have to rewind and play |
| 21:18 | <othermaciej> | it would be nice to preload videos in tabs w/o them playing |
| 21:18 | <Hixie> | instead of what i'd like to do, which is just, when i'm ready, switch the tab and hit play |
| 21:18 | <othermaciej> | I often want that when I'm gonna ride the train |
| 21:18 | <Hixie> | but <video> will help with this |
| 21:18 | <othermaciej> | it could load but not autoplay |
| 21:18 | <othermaciej> | in a background tab |
| 21:18 | <Hixie> | since we can have user prefs to disable autoplay |
| 21:18 | <othermaciej> | until you switch to the tab |
| 21:18 | <othermaciej> | or user prefs |
| 21:18 | <Hixie> | or that |
| 21:18 | <othermaciej> | but we don't tend to go to prefs as the first thing to solve UI problems |
| 21:19 | <Hixie> | yeah the automatic thing is better |
| 21:19 | <Hixie> | just not autoplaying in bg tabs |
| 21:20 | <Hixie> | anyway |
| 21:20 | <Hixie> | so i've collapsed the currentRate 'boolean' and the playing boolean to just the playing three-state thing |
| 21:21 | <Hixie> | and split the state in the apple proposal into two states, since the apple proposal didn't allow for the case where even though everyhting is loaded you might not have the current frame ready yet (seeking) |
| 21:21 | <Hixie> | those don't seem like an increase in complexity, they seem like a lateral move |
| 21:21 | <Hixie> | and an improvement |
| 21:22 | <Hixie> | (reload the spec for the latest strawman: http://www.whatwg.org/specs/web-apps/current-work/#media ) |
| 21:24 | <othermaciej> | I think CAN_PLAY_THROUGH makes more sense than ENDABLE -- first thought was CAN_PLAY_TO_END, but the end isn't even relevant on an infinite stream |
| 21:24 | <othermaciej> | and yet you can be in this state (but only if your transfer rate is fast enough) |
| 21:25 | <othermaciej> | I think dropping LOADED might be better than this split |
| 21:25 | <othermaciej> | LOADED is only useful in theory to tell you that not only can you play through everywhere and do everything, but also that can't possibly change |
| 21:26 | <othermaciej> | but if seeking can temporarily change that, then it doesn't have much value |
| 21:27 | <othermaciej> | I still don't think WAITING is justified and I don't think you have really countered my argument against it (can discover from other info and UI value is questionable) |
| 21:27 | <Hixie> | i disagree, i think you need is so that controllers who join part way can establish what the state of the network connection is |
| 21:27 | <Hixie> | (re loaded) |
| 21:27 | <Hixie> | since they won't get the progress events |
| 21:28 | <othermaciej> | hmm |
| 21:29 | <othermaciej> | the thing is, you might not currently be using the network even when not in LOADED state |
| 21:30 | <othermaciej> | if an implementation caches the remote resource in chunks for instance |
| 21:30 | <othermaciej> | and won't load the next ever if you pause in the middle of the current one |
| 21:30 | <othermaciej> | and it may be impossible to achieve LOADED |
| 21:30 | <Hixie> | once you're LOADED, you can go offline without any troubles ever |
| 21:31 | <Hixie> | if you're not in LOADED, going offline could show a warning |
| 21:31 | <othermaciej> | if you are presenting an rtsp stream, or if your implementation discards buffers |
| 21:31 | <othermaciej> | ok, that seems like a valid use |
| 21:31 | <othermaciej> | this makes me think LOADING vs. BUFFERING distinction really belongs in the other state, since it is not about network progress but about what you can currently do with the data |
| 21:32 | <othermaciej> | (you may be in BUFFERING state when in fact not currently doing a network transfer or planning to) |
| 21:32 | <othermaciej> | so perhaps it should be EMPTY, LOADING, LOADED, ERROR for one |
| 21:32 | <othermaciej> | and EMPTY, HAVE_METADATA, HAVE_FRAME, PLAYABLE, CAN_PLAY_THROUGH for the other |
| 21:33 | <Hixie> | could do |
| 21:33 | <Hixie> | not sure it's more useful though |
| 21:33 | <othermaciej> | well, HAVE_METADATA vs. HAVE_FRAME seems more clear than LOADING vs. BUFFERING |
| 21:34 | <Hixie> | you mean the names? |
| 21:34 | <Hixie> | the names can change |
| 21:34 | <othermaciej> | and LOADING vs. BUFFERING is not about the state of networking, it is about what level of presentation is available, which is what the readyState is about |
| 21:35 | <Hixie> | well it's kind of networking -- LOADING means you haven't received enough data yet to know if you'll go to ERROR or not |
| 21:35 | <Hixie> | BUFFERING means you've received enough data to know you're happy and to have initialised the rest of the object |
| 21:37 | <Hixie> | the problem with putting METADATA in the readyState is that you then have this awkward EMPTY METADATA HAVE_FRAME distinction |
| 21:37 | <Hixie> | where EMPTY becomes effectively useless |
| 21:37 | <othermaciej> | EMPTY means you can't do anything |
| 21:37 | <Hixie> | since you'll never be EMPTY once you've recieved METADATA |
| 21:38 | <othermaciej> | yeah, it's an initial state you can't come back to |
| 21:38 | <othermaciej> | much like the network-related EMPTY state |
| 21:38 | <Hixie> | conceptually, the current strawman has one state that always increases in value, and the readyState which can switch randomly across all states |
| 21:38 | <othermaciej> | you can switch back to EMPTY? |
| 21:38 | <Hixie> | i don't really like making the second one parially random-access but partially ordered |
| 21:39 | <Hixie> | sure, EMPTY is just "i don't have a frame or anything for this playback position" |
| 21:39 | <othermaciej> | I think it is overly simplistic to say state machines must either be linear or always allow transition to all states |
| 21:39 | <othermaciej> | I mean, you couldn't build a coke machine with those constraints |
| 21:39 | <Hixie> | they don't have to |
| 21:39 | <Hixie> | but it makes it way simpler if they do :-) |
| 21:39 | <othermaciej> | and that's the canonical example of a simple state machine |
| 21:39 | <othermaciej> | simpler for who? |
| 21:39 | <othermaciej> | the spec author, who can get out of drawing a state transition diagram? |
| 21:40 | <Hixie> | authors to understand, me to spec, implementors to follow... |
| 21:40 | <gsnedders> | it's easier to understand when implementing |
| 21:40 | <othermaciej> | when implementing, you have to understand every single transition arc |
| 21:40 | <Hixie> | right, so it's simpler if those are easyto enumerate |
| 21:41 | <othermaciej> | if you can go from any state to any other, that's n^2-n transition arcs |
| 21:41 | <Hixie> | there are no more transitions in your proposal (METADATA in readyState) than mine (METADATA in networkState) |
| 21:41 | <othermaciej> | that is in fact maximal complexity for an n-state machine, not minimal |
| 21:42 | <Hixie> | our proposals have the same number of transitions |
| 21:42 | <othermaciej> | sure, I'm just debating the premise that a "random access" state machine is somehow good for implementors |
| 21:42 | <Hixie> | i'm not saying that |
| 21:43 | <Hixie> | i'm saying that two state machines one of which is purely linear and the other of which is purely random-access is better than two state machines where one is linear and the other is bigger than the random access one, adding one extra arc that isn't random access |
| 21:44 | <othermaciej> | and I think if you want to partition state, you should do it by how the state will be used and what it represents, not by what the state transitions look like |
| 21:45 | <Hixie> | that's actually what i said originally when you originally suggested that |
| 21:45 | <Hixie> | i think having METADATA in the network state is more useful |
| 21:45 | <othermaciej> | [ EMPTY --> LOADING --> METADATA --> LOADED ] doesn't make logical sense |
| 21:46 | <Hixie> | [ EMPTY -> opening connection -> received metadata -> receiving data -> received all ] makes logical sense |
| 21:46 | <Hixie> | however, one argument against this is you'd never stay in the metadata state |
| 21:46 | <othermaciej> | it would if "receiving metadata" was actually a separate step |
| 21:47 | <othermaciej> | but having the metadata is a side effect of being in the "I'm transferring bytes now" step, not a separate operation |
| 21:47 | <Dashiva> | But the "all metadata available" event would be useful, so it has to get into there somehow |
| 21:48 | <Hixie> | that's a point |
| 21:48 | <Hixie> | having it in the readyState means you'll get that message more often |
| 21:48 | <Hixie> | though |
| 21:48 | <Hixie> | no |
| 21:48 | <othermaciej> | you'll get it any time you seek to a place where you don't have a frame ready immediately |
| 21:48 | <Hixie> | we could just say that when you don't get the BUFFERING state until you have the metadata |
| 21:48 | <Hixie> | s/when// |
| 21:48 | <othermaciej> | but otherwise you would have gotten the readyState EMPTY state then |
| 21:49 | <Dashiva> | Or make metadataLoaded a separate boolean with associated event... mhrr |
| 21:49 | <Hixie> | actually we can get rid of this step altogether if we have the states split.... |
| 21:50 | <Hixie> | you just define BUFFERING to happen only after you have metadata |
| 21:50 | <Hixie> | then you're set |
| 21:50 | <othermaciej> | I'm not sure what that means or how it is different than what the doc says now |
| 21:51 | Hixie | gets himself really confused |
| 21:51 | <Hixie> | i just went through three arguments in a row that put me straight back to where i was initially |
| 21:51 | <Hixie> | i am not dizzy |
| 21:51 | <Hixie> | now |
| 21:51 | <othermaciej> | you have [ EMPTY -> LOADING -> BUFFERING -> LOADED ] right now |
| 21:52 | <Hixie> | right. that's what i think we want. EMPTY = nothing done. LOADING = sent request. BUFFERING = got back metadata, other fields now are initialised. LOADED = all data now downloaded, you can go offline safely. |
| 21:52 | <othermaciej> | I think LOADING vs. BUFFERING is descriptively poor as a way to say whether you have the metadata, and I think having the metadata belongs logically with presentability state, not networking state |
| 21:52 | <Hixie> | LOADING doesn't mean you have the metadata |
| 21:52 | <Hixie> | LOADING means you don't have anything, but you've requested it |
| 21:52 | <othermaciej> | LOADING means you don't have the metadata |
| 21:52 | <Hixie> | SENT maybe would be better |
| 21:52 | <othermaciej> | BUFFERING means you do |
| 21:53 | <othermaciej> | that is the only difference |
| 21:53 | <othermaciej> | otherwise they both mean you are receiving some octets over the network |
| 21:53 | <Hixie> | right. |
| 21:53 | <Hixie> | so what's wrong with that? |
| 21:54 | <othermaciej> | the names of the states have no relation to this distinction |
| 21:54 | <othermaciej> | and in fact sound like synonyms |
| 21:54 | <Hixie> | i'm open to new names |
| 21:54 | <othermaciej> | (because from a purely networking POV, they are) |
| 21:55 | <Dashiva> | So you will be in BUFFERING state even if you're playing back with fast enough download to never enter buffering mode before end? |
| 21:55 | <Hixie> | i thought we weren't discussing names yet :-) |
| 21:55 | <othermaciej> | I think the problem with the names is because they are trying to draw a distinction that, from the point of view of networking, does not exist |
| 21:55 | Hixie | changes the names to EMPTY SENT LOADING LOADED |
| 21:55 | <Dashiva> | FINISHED :) |
| 21:56 | <Hixie> | finished, like language, initialised, and various other words, are bad in APIs because people mistype them too much |
| 21:56 | <othermaciej> | SENT vs. LOADING is misleading, since you might take it to mean that in SENT state you have not received any bytes yet |
| 21:56 | <othermaciej> | which is not the distinction it is trying to draw |
| 21:57 | <othermaciej> | seriously, having the metadata or not is a presnetability issue not a networking issue |
| 21:57 | <othermaciej> | putting it into the readyState immediately makes it super clear, for this reason |
| 21:57 | <Hixie> | UNSENT, SENT, RECEIVING, DONE? that's what XHR uses. |
| 21:57 | <othermaciej> | it's true that you can't go back to not having metadata |
| 21:57 | <Hixie> | it totally is a network issue |
| 21:58 | <Hixie> | until you have this part of the data, nothing else makes any sense |
| 21:58 | <othermaciej> | it is no more a network issue than having the first frame is a network issue |
| 21:58 | <Hixie> | except that you can go and lose the first frame |
| 21:58 | Dashiva | wonders about mistyping finished |
| 21:58 | <Hixie> | but you can never lose the metadata |
| 21:59 | <othermaciej> | whether you can lose that level of presentability is not in any way due to networking |
| 21:59 | <othermaciej> | it's because having a frame is dependent on where you are on the timeline |
| 22:00 | <Hixie> | granted, but i don't see why that matters. how is having it in the attribute that tells you the state of frame playbackability useful? |
| 22:01 | <Hixie> | it seems to me that having the metadata is closer to the network state (it's a milestone along the download) than it is to the seeking and decoding state |
| 22:01 | <othermaciej> | that's the state you normally need to track to know what state to put the controls in |
| 22:02 | <Hixie> | controls don't disable themselves just because you're not able to play the current frame in current UIs |
| 22:03 | <Hixie> | they enable themselves once, when you have enough data to know wtf you're looking at |
| 22:03 | <othermaciej> | it's really only the first transition to having a frame that significantly matters, really |
| 22:04 | <othermaciej> | since most things only show placeholder UI before you have the first frame, when you seek they usually stick on the last frame seen |
| 22:04 | <Hixie> | agreed |
| 22:05 | Hixie | ponders on this |
| 22:08 | <Hixie> | (on names, HAVE_FRAME doesn't really work for audio) |
| 22:08 | <othermaciej> | that state isn't really relevant to pure audio |
| 22:09 | <othermaciej> | since audio is more purely time-based, there's no such thing as presenting a static view of the current time |
| 22:10 | <Hixie> | there could be (e.g. embedded static images, captions, visualisation) |
| 22:12 | <othermaciej> | a static image along the lines of cover art would be considered metadata, not a playable track |
| 22:12 | <othermaciej> | if there is a text track displayed as captions, it's probably reasonable to consider each piece of text a "frame" |
| 22:13 | <othermaciej> | probably better than calling the state CAN_SHOW_STATIC_VIEW_OF_CURRENT_TIME |
| 22:13 | <om_coffee> | will be back |
| 22:45 | <hsivonen> | what's the process of getting something published in w3.org/TR/? |
| 22:45 | <hsivonen> | I mean: why is the backplane stuff there? |
| 22:49 | <karlUshi> | http://www.w3.org/TR/2006/NOTE-backplane-20061116/ |
| 22:49 | <karlUshi> | *W3C Coordination Group Note* |
| 22:50 | <karlUshi> | "Publication as a Coordination Group Note does not imply endorsement by the W3C Membership. " |
| 22:51 | <karlUshi> | ok time to prepare to take a shower |
| 22:56 | <othermaciej> | hsivonen: a W3C Working Group can publish just about anything it wants to as a W3C Note |
| 22:59 | <Hixie> | othermaciej: i updated the strawman proposal |
| 22:59 | <Hixie> | got rid of WAITING |
| 22:59 | <Hixie> | went in the other direction than you were pushing me for the networkState vs readyState though |
| 22:59 | <Hixie> | since that gives us useful one-shot events for free |
| 23:00 | <Dashiva> | Is the strawman available online? |
| 23:00 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#media |
| 23:00 | <Hixie> | in the IDL |
| 23:00 | <othermaciej> | Hixie: looking |
| 23:19 | <othermaciej> | Hixie: I like that somewhat better |
| 23:19 | <Hixie> | ooo, progress :-) |
| 23:19 | <mpt> | "can display text to the user informing them of how to access the video contents" |
| 23:19 | <mpt> | ... or an alternative, such as a slideshow or animated GIF |
| 23:20 | <othermaciej> | Hixie: I'll have to mull on it a bit |
| 23:20 | <Hixie> | k |
| 23:20 | <Hixie> | i have to go offline now anyway |
| 23:20 | <othermaciej> | ok |
| 23:20 | <othermaciej> | ttyl |
| 23:46 | <othermaciej> | Hixie: you should update the copyright on Web Apps 1.0 to say "Apple Inc." instead of "Apple Computer, Inc." |