| 00:32 | <Hixie> | we need a better term than readyState |
| 00:32 | <Hixie> | for the CAN_SHOW_/CAN_PLAY_ states |
| 00:36 | <Hixie> | readyState would be fine except that XHR and IE use it for network status |
| 00:37 | <othermaciej> | yeah |
| 00:37 | <othermaciej> | the accurate but too long name would be presentabilityState |
| 00:38 | <othermaciej> | or playabilityState if you wanna be a bit less accurate |
| 00:38 | <othermaciej> | or just playability |
| 01:45 | <Hixie> | is an event that fires every few 100ms while playing useful, or should position ui be updated via timeouts? |
| 01:47 | <othermaciej> | timeouts + notification of reasons for rate change seem sufficient (that being pause or becoming unplayable) |
| 01:47 | <Hixie> | ok. |
| 01:49 | <Hixie> | oh another thing, do we want paused to be a mutable attribute, or do we prefer play()/pause() ? |
| 01:49 | <Hixie> | this baby is going to have six bazillion events, jesus |
| 01:49 | Hixie | has the events up on his whiteboard |
| 01:49 | <othermaciej> | hmm |
| 01:50 | <othermaciej> | play() / pause() seems a lot more natural, even though normally I'd be more inclined to a read/write attribute |
| 01:50 | <Hixie> | that was my conclusion too |
| 01:50 | <KevinMarks> | don't they map to setplayrate anyway? |
| 01:51 | <Hixie> | it's not clear what we're going to do with the proposed playRate stuff |
| 01:51 | <Hixie> | but that's not today's problem anyway |
| 01:51 | Hixie | is trying to spec out all the states first |
| 01:51 | <KevinMarks> | play() == setPlayRate(1.0) pause == setPlayRate(0) rewind=setPlayRate(-1) |
| 01:51 | <KevinMarks> | etc |
| 01:52 | <KevinMarks> | if you're doing a property approach, that fits |
| 01:53 | Hixie | ponders whether we need an event specifically for when playback stops despite it not being paused, in addition to the event we have for entering the readyState UNAVAILABLE state (which can also fire for other reasons, e.g. seeking to unbuffered data) |
| 01:54 | <othermaciej> | KevinMarks: Apple's proposal didn't work quite like that |
| 01:56 | <Hixie> | i'd use 'stalled' but we're using that for indicating lack of network progress |
| 01:56 | <Hixie> | maybe 'onwaiting'? |
| 01:56 | <Hixie> | i'll call it 'waiting' for now and we can work out what to do later. |
| 01:57 | <Hixie> | ok that's 20 events for <video> and <audio> |
| 01:58 | <othermaciej> | I think you should read Kevin Calhoun's message about networking models |
| 01:58 | <othermaciej> | I'm not sure 'stalled' makes sense, depending on your access strategy |
| 01:58 | <othermaciej> | (or things like 'bufferRate') |
| 01:58 | <othermaciej> | but he said it better |
| 01:58 | <Hixie> | the one he sent earlier today? |
| 01:58 | <othermaciej> | yes |
| 01:59 | <Hixie> | i've already rolled most of his feedback into the strawman proposal |
| 01:59 | <Hixie> | stalled just means that the UA isn't getting data but is expecting it |
| 01:59 | <Hixie> | provides an easy way to give a "your connection may be broken" message |
| 02:00 | <Hixie> | (or for greasemonkey scripts, e.g., to go in and provide that) |
| 02:00 | <Hixie> | the "seekable" attribute was added in response to his message, btw |
| 02:00 | <Hixie> | i'll reply to it in detail when i go through the e-mail feedback though |
| 02:04 | <othermaciej> | I think "readonly attribute TimeRanges seekable" may be more general than needed, in practice I would expect you have only a single range at the beginning or you pretend any point is available |
| 02:04 | <othermaciej> | I think keeping a list of buffered ranges is just not applicable to some loading strategies so maybe we should think about what problem it is trying to solve |
| 02:05 | <othermaciej> | and I think bufferingRate isn't useful |
| 02:06 | <othermaciej> | if you want to estimate bytes per second, there's always progress events for that |
| 02:06 | <othermaciej> | although I'm not really sure how progress events would apply to an RTSP stream, or something that buffers incrementally using byte range requests |
| 02:22 | <KevinMarks> | othermaciej: think about the bittorrent case, where you may have multiple blocks cached but not all |
| 02:23 | <othermaciej> | KevinMarks: bittorrent isn't the only case where that can happen |
| 02:23 | <KevinMarks> | I know, I'm using it as an example |
| 02:23 | <othermaciej> | KevinMarks: but bittorrent isn't something you'd use as a protocol to back video playback, since it gives you the data in random order |
| 02:23 | <othermaciej> | which is useless unless you are willing to download the whole thing up front |
| 02:24 | <KevinMarks> | no, you can treat it statistically like a fast-start |
| 02:25 | <KevinMarks> | when you have enough contiguous pieces from the start to play for longer then expected remaining download time, you can play |
| 02:27 | <Hixie> | hm, there are two error states really |
| 02:27 | <Hixie> | one where the media is still partly playable |
| 02:27 | <Hixie> | and one where it's not |
| 02:27 | <KevinMarks> | Kevin Calhoun wrote a usenet datahandler that would collect chunks from alt.binaries postings |
| 02:28 | <othermaciej> | the thing is, with bittorrent, the timewise first chunk could be the last you get |
| 02:29 | <KevinMarks> | yes, so at that point you do need to wait for the whole thing |
| 02:31 | <othermaciej> | so yeah, you could make it work, it just wouldn't be advisable to serve page-embedded video by bittorrent |
| 02:32 | <othermaciej> | unless it is small enough to d/l the whole thing quickly |
| 02:32 | <othermaciej> | in which case, why bother w/ torrent |
| 02:33 | <KevinMarks> | I find torrents about the same speed as pulling videos from itunes store via akamai at home |
| 02:34 | <KevinMarks> | so it's a little moot |
| 02:36 | <KevinMarks> | for a fast-start, you know it is mostly coming in order, so you reach the expected completion time sooner, but for a torrent or sliced usenet download you can still reach it before download is complete |
| 02:38 | <othermaciej> | yeah the torrent problem is just that there's no way to bias it towards timewise earlier chunks and it is fine-grained enough that this is likely to hose you |
| 02:40 | <KevinMarks> | well, there is, as which chunk you request is under client control, so you could favour earlier ones between otherwise equivalent ones (the next chunk rule is usually a function of rarity and others estimated rates) |
| 03:04 | <Hixie> | i'm not sure how to handle this error problem |
| 03:04 | <Hixie> | short of having two error states |
| 03:04 | <Hixie> | or three, even |
| 03:05 | Hixie | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!' |
| 03:12 | <Hixie> | hm, the apple proposal doesn't handle this at all, it just has an error state for the early part |
| 03:12 | <Hixie> | not for the later part |
| 05:43 | <Lachy_> | yay! XHTML+RDFa :-) http://www.w3.org/MarkUp/2007/ED-xhtml-rdfa-20070402/ |
| 05:44 | <othermaciej> | it's a day late |
| 05:45 | <Lachy_> | yeah, but got to give them credit for stealing our HTML6 ideas so quickly |
| 05:47 | <othermaciej> | I see exactly three user agent conformance requirements |
| 05:47 | <othermaciej> | all of which are stupid |
| 05:51 | <Lachy_> | I found 3 MUST level and 1 SHOULD level UA requirement |
| 05:52 | <othermaciej> | ah, I missed the SHOULD |
| 05:55 | <Lachy_> | the whole thing is impossible to implement anyway, since it reuses the XHTML1 NS in incompatible ways |
| 05:55 | <othermaciej> | is this supposed to be part of XHTML2? |
| 05:55 | <Lachy_> | it appears to be XHTML1 |
| 05:56 | <Lachy_> | "This document is an internal editors draft for development purposes. However, its content is based upon mature materials from [XHTML2] and is therefore considered nearly complete." |
| 05:56 | <othermaciej> | it seems to assume href on every element |
| 05:56 | <Lachy_> | that explains the problem |
| 05:57 | <othermaciej> | well, XHTML5 presumably won't have modularization so we will be safe |
| 06:16 | <Lachy_> | I just love how easy DTDs make things --> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Apr/0017.html |
| 06:17 | <Hixie> | introducing a new status to mean "not completely loaded but partialy loaded and we're not going to bother getting more" seems like more work than it's worth |
| 06:17 | <Hixie> | (for implementors and authors) |
| 06:17 | <Hixie> | but the alternative is to have the 'error' event send to either ERROR or LOADED depending on whether we passed LOADED_INITIAL_FRAME or not |
| 06:17 | <Hixie> | which seems poor |
| 06:23 | <Hixie> | this sucks |
| 06:23 | <Hixie> | having a network problem or user cancelation nearly arbitrarily result in a LOADED or an ERROR is stupid |
| 06:24 | <Hixie> | in the former case there's no way to catch the error if joining late, e.g. |
| 06:24 | <Hixie> | but we can't use the same code as otherwise you can't tell if the other attributes are safe |
| 06:24 | <Hixie> | maybe we should just have a lastError attribute |
| 06:24 | <Hixie> | which is reset when you get a successful transition |
| 06:24 | <Hixie> | or rather, is reset by load() |
| 06:25 | <Hixie> | or maybe when we have an error or abort we should leave the state in its last state and set an error flag |
| 06:25 | <othermaciej> | I'm not sure you should go to LOADED on a user cancel or late error - probably better to stay in current state with alternate way to get the error (like lastError) |
| 06:25 | <Hixie> | that way you can see where the error occured |
| 06:26 | <othermaciej> | that might obviate the need for an ERROR state I guess |
| 06:26 | <Hixie> | yeah |
| 06:54 | <Hixie> | man, the list of ways in which playback can stop when the media isn't paused is getting longer by the hour |
| 06:55 | <othermaciej> | oh yeah? |
| 06:55 | <othermaciej> | what besides entering non-playable state or reaching the end? |
| 06:57 | <Hixie> | currently: seeking (UNAVAILABLE and paused=false and seeking=true), buffering (UNAVAILABLE or CAN_SHOW_CURRENT_FRAME and paused=false and seeking=false, playback position isn't in the buffered range), ended is true, and a fatal error occured, either network error or during decoding. |
| 06:58 | <Hixie> | currently the first two will fire a 'waiting' event when they occur, the latter two won't. |
| 06:58 | <othermaciej> | fatal error partway should arguably count as truncating the duration |
| 06:59 | KevinMarks | remembers all those arcane QuickTime chapters on clocks |
| 06:59 | <Hixie> | fatal errors might occur decoding the stream half-way, with a later part of the stream still playable if seeked to (i see this on DVDs often, sadly) |
| 06:59 | <Hixie> | not sure we care about that though |
| 07:55 | <Hixie> | should i reuse 'reset' for when we reset the <video> element when load() is invoked on an already-running <video>? |
| 07:58 | <othermaciej> | what else is 'reset' used for? |
| 07:58 | <Hixie> | forms |
| 08:05 | <Hixie> | hm, 'reset' bubbles for forms |
| 08:06 | <Hixie> | i guess i could make one here that doesn't but that seems like it would just confuse matters. |
| 08:07 | <Hixie> | 'emptied' will do for now |
| 08:36 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/source#mediaevents may be of interest |
| 08:41 | <othermaciej> | definition of "stalled" in the prose seems wrong (though description in the table is ok) |
| 08:41 | <othermaciej> | "If at any point the user agent has received no data for more than about three seconds, the user agent must fire a stalled event at the element." |
| 08:42 | <Hixie> | the prose isn't done yet |
| 08:42 | <Hixie> | i just did the table |
| 08:42 | <Hixie> | most of the prose is unchanged from the original checkin before the apple proposal was sent to the list |
| 08:43 | <othermaciej> | event names seem to be a mix of past and present tense |
| 08:44 | <othermaciej> | that is indeed a whole lot of events |
| 08:44 | <Hixie> | yeah at some point we need to do a cleanup of the names in this section |
| 08:44 | <Hixie> | events, constants, methods, attributes |
| 08:44 | <Hixie> | right now i just want to get the thing described |
| 08:45 | <Hixie> | the names can be discussed in the html wg :-P |
| 08:46 | <hsivonen> | ExternalizeBikeshedding as a design principle? :-) |
| 08:46 | <othermaciej> | hah |
| 08:46 | <Hixie> | :-) |
| 08:48 | <othermaciej> | is Murray Maloney a known person in the web standards world? |
| 08:49 | <Hixie> | othermaciej: yes |
| 08:49 | <othermaciej> | I think I upset him by implying that the fact that he agreed or disagreed with something, with no further info, was uninteresting |
| 08:49 | <othermaciej> | (by private email) |
| 08:50 | <Hixie> | hah |
| 08:51 | <Hixie> | http://www.xml.com/pub/au/56 describes for what he's known pretty succintly |
| 10:00 | <MikeSmith> | Hixie, om_sleep - I think Murray was also active back in the day in the IETF HTML WG |
| 10:00 | <MikeSmith> | https://listserv.heanet.ie/cgi-bin/wa?A0=html-wg |
| 10:01 | om_sleep | obviously has no respect for his elders |
| 10:01 | <om_sleep> | I gave Dave Raggett a hard time too |
| 10:04 | <MikeSmith> | om_sleep - Dave's got thick skin. I don't know Murray personally, but I'd guess he's been involved enough in mailing list discussions to not get upset and take stuff personally |
| 10:05 | <MikeSmith> | and I think it's good for him to know how annoying people find those multiple +1 messages |
| 13:26 | <hsivonen> | clearly, http://www.w3.org/TR/2007/WD-curie-20070307/ has not been developed with backwards compat in mind |
| 13:28 | <Lachy> | did you expect it to be? |
| 13:28 | <hsivonen> | Lachy: I didn't. |
| 13:29 | <hsivonen> | but if it becomes a REC, some people might ask it to be supported for the XHTML 1.x namespace. :-( |
| 13:30 | <hsivonen> | qNames in content is already an anti-pattern |
| 13:31 | <Lachy> | I haven't actually read curie yet, how is it supposed to work? |
| 13:32 | <Lachy> | I'll just go read it, since it's quite short |
| 13:32 | <hsivonen> | Lachy: IRIs that start with [ and end with ] are treated as bracketed qNames that are resolved relative to namespace URIs |
| 13:58 | <Lachy> | I just finished reading the spec. It seems curies could be potentially useful in an authoring tool or CMS that processes them and outputs the full URIs to the web |
| 14:44 | <hsivonen> | Hixie: btw, do you have a reference to H.264 Baseline being free of enforceable patents? |
| 14:46 | <hsivonen> | I find it unbelievable that Baseline would be unencumbered. I would have expected to have heard the details by now elsewhere if it was. |
| 17:11 | zcorpan | was in linköping today |
| 17:13 | <tylerr> | Did you say hello to the Cardigans? :-) |
| 17:13 | <hasather> | zcorpan: how did it go? |
| 17:14 | <hasather> | tylerr: they are from Jönköping |
| 17:14 | <hasather> | if I'm not mistaken |
| 17:14 | <zcorpan> | hasather: it went well |
| 17:14 | <tylerr> | Oh! I need to check my sources then. |
| 17:14 | <hasather> | zcorpan: you got the job? |
| 17:14 | <zcorpan> | don't know yet |
| 17:14 | <zcorpan> | but it seems likely |
| 17:14 | <tylerr> | Ah yes you're right hasather, Jönköping. I get my pings confused. :-) |
| 17:14 | <hasather> | ok, but great that it went well |
| 17:15 | <hasather> | tylerr: :) |
| 17:16 | <zcorpan> | they knew more about html5 than last time i was there. talked to two other guys this time (although only one of them seemed to know stuff about html5) |
| 17:16 | <zcorpan> | last time i was there (in august) i talked to an svg guy or something |
| 17:16 | <hasather> | ok |
| 17:18 | <hasather> | zcorpan: did they like your idea about a HTML5 test suite? |
| 17:19 | <zcorpan> | yeah |
| 17:19 | <hasather> | cool |
| 17:19 | <zcorpan> | although they could come up with other stuff i could work on too |
| 17:19 | <zcorpan> | like internal test suites or something |
| 18:07 | <zcorpan> | anyone know what "interoperable" is in swedish? |
| 18:08 | <zcorpan> | samfungerande? |
| 18:14 | <zcorpan> | or simply "interopererande"? |
| 18:18 | <hasather> | zcorpan: both could probably work, don't know a good word for it myself |
| 18:20 | <zcorpan> | http://sv.wikipedia.org/wiki/Interoperabilitet |
| 18:20 | zcorpan | will go with the latter |
| 18:20 | <hasather> | yea, found that |
| 18:21 | <hasather> | zcorpan: ineroperabel maybe |
| 18:21 | <hasather> | +t |
| 18:22 | <hasather> | not a common Swedish word though |
| 18:29 | <zcorpan> | interoperable it is |
| 18:29 | <zcorpan> | er |
| 18:30 | <zcorpan> | interoperabel |
| 20:14 | <Hixie> | hsivonen: no, nobody seems willing to make that kind of claim on record :-( |
| 20:22 | <markp> | all right, this is probably a FAQ, but what's up with accesskey? |
| 20:23 | <markp> | it's mentioned repeatedly in wf2 but not at all in html5 |
| 20:26 | <Hixie> | haven't yet worked out wtf to do with it |
| 20:27 | <Hixie> | it's so fundamentally broken in so many ways... |
| 20:27 | <markp> | documenting current practice isn't sufficient? |
| 20:27 | <markp> | i understand the extent of its brokenness |
| 20:28 | <Hixie> | currnet practice varies dramatically and is fundamentally broken |
| 20:28 | <markp> | that has never stopped you before... |
| 20:30 | <Hixie> | markp: the difference is that for accesskey i don't know how to fix it :-( |
| 20:31 | <markp> | i see |
| 20:36 | <markp> | argh! |
| 20:36 | <markp> | http://msdn2.microsoft.com/en-us/library/ms535181.aspx |
| 20:36 | <markp> | "This example uses the address element to italicize text." |
| 20:36 | <markp> | just shoot me |
| 20:49 | <markp> | http://www.whatwg.org/specs/web-apps/current-work/#area does not define the nohref attribute |
| 20:49 | <Hixie> | what does the nohref attribute do? |
| 20:49 | <markp> | described here: http://www.w3.org/TR/html401/struct/objects.html#adef-nohref |
| 20:50 | <Hixie> | but what does the nohref attribute do? |
| 20:50 | <Hixie> | (there are few UA conformance requirements in the HTML4 spec, and none for nohref, so it's not a good source of information for what things in HTML do) |
| 20:51 | <markp> | i understand |
| 20:52 | <markp> | i believe it's a way of marking that the <area>'s lack of an @href attribute is intentional |
| 20:52 | <Hixie> | so it does nothing? |
| 20:52 | <markp> | i.e. for validation |
| 20:52 | <markp> | checking firefox code |
| 20:53 | <markp> | hang on |
| 20:53 | <Hixie> | (and if we can't trust that the lack of an href attribute is intentional, why can we trust that the presence of a nohref attribute _is_?) |
| 20:54 | <markp> | firefox does precisely nothing with it |
| 20:54 | <markp> | no changes in behavior, nothing |
| 20:54 | <Hixie> | ok then |
| 20:54 | <markp> | http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/nohref.asp says "Sets or retrieves whether clicks in this region cause action." |
| 20:54 | <markp> | which is slightly tantalizing |
| 20:54 | <Hixie> | msdn is wrong. :-) |
| 20:55 | <Hixie> | i tested it a lot, couldn't find that the attribute did anything, so i dropped it |
| 20:55 | <Hixie> | it seemed singularily pointless. |
| 20:55 | <markp> | aha |
| 20:55 | <markp> | http://www.idocs.com/tags/images/_AREA_NOHREF.html |
| 20:55 | <markp> | it is for dead zones in shaped <area>s |
| 20:56 | <markp> | see the idocs link |
| 20:58 | <Hixie> | yes but how does that differ from the lack of an href attribute? |
| 21:00 | <markp> | hacking the idocs test case reveals that there is no difference |
| 21:00 | <markp> | i have discovered html's most useless attribute |
| 21:00 | <Hixie> | pretty much |
| 21:00 | <markp> | or, more likely, rediscovered |
| 21:18 | <aja> | hi all...offering some experience re: 512 scanning for encoding. GRDDL parsing seems to be depending on profile for each microformat...and if one defines each official and draft uF, 512 is rapidly approached. might be something to work out with the GRDDL/hGRDDL WG folks |
| 21:19 | <aja> | 2nd concern: if multiple media and/or alternate stylesheet PI's are used, 512 can become a concern, too |
| 21:49 | <KevinMarks> | what's the significance of 512? |
| 21:51 | <a-ja> | KevinMarks: only first 512 bytes scanned for content encoding |
| 21:52 | <KevinMarks> | you mean explicit content-encoding, or for statistical guessing? |
| 21:52 | <KevinMarks> | oops |
| 21:52 | <a-ja> | explicit |
| 21:52 | <KevinMarks> | so the recommendation is to put the profiles after the content header? |
| 21:54 | <a-ja> | guess putting them on individuaal uF-containing elements rather than on <html> would do....but is that supported already? |
| 21:56 | <Hixie> | a-ja: we've dropped profile="" from HTML5 at the moment |
| 21:56 | <Hixie> | a-ja: based on the principle that nobody on the web was actually using it |
| 21:56 | <a-ja> | tell the GRDDL WG ! |
| 21:57 | <a-ja> | tks, Hixie...wasn't aware of that. did see some related discussion back in Dec though |
| 21:57 | <Hixie> | nobody uses GRDDL either :-) |
| 21:58 | <a-ja> | heheh....certainly not yet anyway |
| 21:58 | <Dashiva> | GRDDL doesn't sound cool enough |
| 21:59 | <a-ja> | doesn't have the same ring to it that RDFa has? |
| 21:59 | <Dashiva> | It's missing at least one X |
| 22:01 | <Hixie> | well more importantly, there doesn't really seem to be much demand for a microformats-to-RDF convertor |
| 22:01 | <Hixie> | most people who consume microformats will just have microformat-specific parsers |
| 22:02 | <a-ja> | true enuff....and i haven't seen one yet that looked for a profile |
| 22:03 | <a-ja> | "in the wild" anyway |
| 22:03 | <KevinMarks> | as publishing profiles is a major pain |
| 22:03 | <KevinMarks> | and grepping for the container class is easier |
| 22:08 | <Hixie> | when someone changes the <video src=""> and invokes .load() again, what should happen? |
| 22:09 | <Hixie> | should everything reset to initial values? |
| 22:09 | <Hixie> | should events be fired for each attribute that's reset? |
| 22:19 | <Dashiva> | Looking at xhr, some kind of abort/unload event coupled with state changes to 0/empty/uninit. More than that could get really messy |
| 22:44 | <othermaciej> | Hixie: sorry for not being in the right place |
| 22:44 | <Hixie> | no worries |
| 22:44 | <Hixie> | i was confused |
| 22:44 | <Hixie> | anyway |
| 22:44 | <Hixie> | 23:17 < Hixie>|when someone changes the <video src=""> and invokes .load() again, what should happen? |
| 22:44 | <Hixie> | 23:17 < Hixie>|should everything reset to initial values? |
| 22:44 | <Hixie> | 23:17 < Hixie>|should events be fired for each attribute that's reset? |
| 22:46 | <Hixie> | in particular, right load you invoke a load() method to restart the video element with a new source |
| 22:46 | <Hixie> | but that needs to fire a whole sequence of events: abort on the previous thing, emptied because we're going back to zero, paused if it was previously playing, unavailable if we had a frame before, begin to indicate we've started a new download |
| 22:47 | <Hixie> | and i'm not really sure what order those events should fire in, and whether they should fire before or after load() returns |
| 22:48 | <Hixie> | it feels like 'abort' should fire after it returns, but it also feels like the attributes should be reset before it returns, and it feels like they should be reset after abort is fired |
| 22:48 | <Hixie> | which is an overconstrained situation |
| 22:48 | <Hixie> | we could just say that you can't re-use a <video> but that seems dumb |
| 22:48 | <Hixie> | i think i'm going to think on this while cycling to work. feel free to describe your thoughts here and i'll read them when i get in. |
| 22:52 | <KevinMarks> | what happened to sequencing? |
| 22:54 | <othermaciej> | Hixie: I think everything should reset but probably a single "emptied" event is ok to express, not sure offhand |
| 22:54 | <othermaciej> | KevinMarks: I don't think sequencing is in yet |
| 22:56 | <KevinMarks> | this kind of stuff is why trying to handle sequencing in the js layer is hard |
| 22:57 | <Hixie> | othermaciej: so not even an 'abort' event? |
| 22:57 | <othermaciej> | Hixie: I'm not up to speed on the current state of the events |
| 22:58 | <hsivonen> | Hixie: I see (Re: no enforceable patents of Baseline) |
| 22:58 | <hsivonen> | markp: I'm glad to see you can finally talk with us. Welcome. |
| 22:59 | <hsivonen> | markp: can you say what your job at Google is? are you going to work on Web Forms 2.0 accessibility in Gecko? |
| 22:59 | <othermaciej> | KevinMarks: the main reason for built-in sequencing is the same as looping, that you can better avoid glitches by appropriately pre-buffering |
| 23:00 | <Hixie> | othermaciej: 'abort' would be the progress event, from DOM Level 0 |
| 23:01 | <othermaciej> | Hixie: would probably make sense to have that, since it has more general purposes than UI control state |
| 23:01 | <Hixie> | yeah, just not sure when to fire it |
| 23:04 | <KevinMarks> | yes |
| 23:08 | <markp> | hsivonen: hi; yes, i can talk to you (on company time, even!); my official title is "lead technical writer"; my position involves some of these things: http://www.google.com/support/jobs/bin/answer.py?answer=53090 ; i am no longer working on firefox or accessibility issues |
| 23:13 | <hsivonen> | markp: ok |