| 00:02 | <zcorpan> | text := <any Unicode text other than cr or lf> |
| 00:03 | <zcorpan> | Hixie: shouldn't that be any Unicode text other than cr, lf, < or &? |
| 00:05 | <othermaciej> | Hixie: HTML WG home page |
| 00:08 | <Hixie> | zcorpan: yeah |
| 00:08 | <Hixie> | othermaciej: k |
| 00:19 | <Hixie> | waaaaah, ArrrrrrrrrrryehGregorrrrrrrr, the wiki brokeded! |
| 00:19 | <Hixie> | it won't let me edit! |
| 00:20 | <erlehmann> | cue "i made you a wiki. but i eated it." |
| 00:20 | <zcorpan> | Hixie: it means it's time to move from wiki land to spec land :) |
| 00:20 | <Hixie> | yeah, guess so |
| 00:20 | <Hixie> | man |
| 00:20 | <Hixie> | i was trying to put that off more |
| 00:20 | <erlehmann> | and thus the standard was born. |
| 00:20 | <Hixie> | as soon as i start writing spec text, the honeymoon is over and people start bitching at me instead of at each otehr |
| 00:22 | <erlehmann> | hixie, the lightning rod of the open web |
| 00:23 | <zcorpan> | Hixie: why the alignment difference for subtitles and captions? |
| 00:23 | <Hixie> | matches existing practice |
| 00:24 | <Hixie> | nessy: yt? |
| 00:24 | <Hixie> | foolip: yt? |
| 00:24 | <nessy> | in a meeting - will be with you in about 30 min |
| 00:25 | <Hixie> | k |
| 00:30 | <zcorpan> | Hixie: i think lang="" is bad because it sets the language of the element and comes with xml:lang confusion baggage |
| 00:31 | <zcorpan> | Hixie: i think hreflang="" is confusing since there's no href="" |
| 00:31 | <TabAtkins> | Isn't it supposed to set the language of the element? |
| 00:32 | <Hixie> | yeah, why is setting the language of the element bad? |
| 00:34 | <zcorpan> | because the element doesn't contain any text |
| 00:34 | <Hixie> | label="" is text |
| 00:34 | <zcorpan> | true |
| 00:35 | <zcorpan> | would xml:lang be used in xhtml? |
| 00:35 | <Hixie> | presumably |
| 00:35 | <zcorpan> | ok |
| 00:35 | <Hixie> | though i agree that'd be a bit of a pain |
| 00:35 | <Hixie> | i can live with srclang="" |
| 00:38 | <zcorpan> | is websrt intended for all kind=""s? |
| 00:39 | <Hixie> | yes |
| 00:39 | <zcorpan> | ok |
| 00:39 | <Hixie> | do we want <track enabled=false> or <track default=off> or <track force=disabled> or something else? (i think we need a three-state default state attribute to allow sites who have offered user preferences to force which titles are enabled by default) |
| 00:40 | <Hixie> | enabled=true/false default=on/off force=enabled/disabled state=show/hide |
| 00:40 | <Hixie> | (third state is missing attribute) |
| 00:41 | <Hixie> | setting the attribute dynamically has no effect |
| 00:41 | <Hixie> | it's only to set the default state |
| 00:41 | <TabAtkins> | force=enabled/disabled |
| 00:41 | <TabAtkins> | makes it clear that you're overriding a default, which isn't obvious from several of the others |
| 00:41 | <Hixie> | force is a verb, though, which is unusual for us |
| 00:41 | <zcorpan> | i don't like force |
| 00:41 | <Hixie> | default=enabled/disabled ? |
| 00:42 | <zcorpan> | it sounds forceful :) |
| 00:42 | <zcorpan> | default=show/hide ? |
| 00:42 | <Hixie> | hm... show/hide may be misleading since some of these, when enabled, don't display any UI |
| 00:42 | <Hixie> | e.g. the metadata tracks |
| 00:42 | <Hixie> | they default to off |
| 00:42 | <Hixie> | but would be turned on by this |
| 00:42 | <Hixie> | and wouldn't show anything, just fire events |
| 00:43 | <TabAtkins> | enabled=forceon/forceoff |
| 00:46 | <zcorpan> | spellcheck and draggable and contenteditable are true/false |
| 00:47 | <zcorpan> | enabled sounds like disabled which is a boolean attribute |
| 00:48 | <Hixie> | we don't seem to have any attributes equivalent to this so far |
| 00:48 | <Hixie> | hmm |
| 00:48 | <zcorpan> | <option> has selected and disabled |
| 00:49 | <Hixie> | selected="" is similar (disabled="" isn't) but it's not two-state |
| 00:49 | <Hixie> | checked="" is similar |
| 00:52 | <zcorpan> | state=on/off |
| 00:52 | <Hixie> | "state" and "default" are too vague really |
| 00:53 | <TabAtkins> | I fear attributes that sound like you're *supposed* to use them. |
| 00:54 | <Hixie> | maybe the solution is to not provide a way to enable/disable a track from markup |
| 00:54 | <Hixie> | and require using JS |
| 00:54 | <TabAtkins> | I don't have a problem with that. The only reason you want to override the user defaults is if you're doing something yourself in script. |
| 00:54 | <gregw> | Hixie: with the experiment for connections through intermediaries, do you know if the intermediaries that didn't send the first packet client to server, would or would not send the first packet server to client |
| 00:55 | <zcorpan> | Hixie: yeah |
| 00:55 | <gregw> | ie do you know if random bytes after the 101 response would be enough for the fail fast |
| 00:56 | <othermaciej> | gregw: Hixie's previous comments were that he didn't have non-anecdotal data on that (yet) |
| 00:56 | <Hixie> | gregw: all i know is that after the handshake completed, data couldn't successfully be sent using websocket. I don't know precisely how it failed. |
| 00:57 | <gregw> | ok - well that leaves the possibility that something sent after the 101 response could detect fail fast and still not interfer with HTTP. |
| 00:58 | <Hixie> | my requirement is that the connection be proven to work by the time the API sends the connected event, and that that happen in as short a time as possible |
| 00:58 | <Hixie> | ideally instantaneously |
| 00:58 | <Hixie> | i haven't been able to find a way to pring it to lower than 1xRTT |
| 00:58 | <Hixie> | 2xRTT seems longer than desired |
| 00:58 | <gregw> | I think that could be done with just the bytes after the 101 response |
| 00:58 | <gregw> | they can be sent in the same packet |
| 00:59 | <gregw> | and the handshake on the client would check for them |
| 00:59 | <gregw> | and the connection would only be open if they are there and correct |
| 00:59 | <Hixie> | if that works, yeah |
| 00:59 | <gregw> | so we need data |
| 01:00 | <Hixie> | we need data either way, idneed |
| 01:02 | <zcorpan> | Hixie: is there a need for <source> in <track>? |
| 01:02 | <Hixie> | yes, to the same extent as there is a need for a <source> in <video>, no? |
| 01:03 | <zcorpan> | not if everyone agrees to implement websrt |
| 01:04 | <zcorpan> | <source> is complex and a source of many bugs |
| 01:05 | <zcorpan> | no pun intended |
| 01:06 | <Hixie> | i'm happy to start off without <source> and only add it when people whine |
| 01:06 | <Hixie> | but that means it's your job to make people not whine enough that i hear it |
| 01:07 | <zcorpan> | i can't make people not whine |
| 01:08 | <Hixie> | but you can convince them they're wrong, right? |
| 01:08 | <zcorpan> | yeah, hopefully |
| 01:12 | nessy | is back - reading up |
| 01:15 | <zcorpan> | would be fun to reverse engineer srt impls |
| 01:15 | <zcorpan> | nn |
| 01:16 | <nessy> | ok, so something has been published I gather? |
| 01:17 | nessy | also needs to catch up on email, I guess |
| 01:19 | <Hixie> | nessy: nothing published |
| 01:19 | <Hixie> | nessy: he was discussing the wiki stuff |
| 01:19 | <nessy> | ah cool |
| 01:19 | <nessy> | I see |
| 01:19 | <Hixie> | though i have begun editing the spec |
| 01:19 | <nessy> | you wanted something? |
| 01:20 | <Hixie> | nessy: i was going to ask you if we really needed to support <trackgroup> |
| 01:20 | <Hixie> | and if so, what it was solving |
| 01:20 | <nessy> | so, there are two things that were a requirement when we designed the <track> element |
| 01:20 | <nessy> | one was that we wanted to be able to have multiple tracks active at the same time |
| 01:21 | <nessy> | so, for this we would simply have multiple <track> elements inside the <video> element |
| 01:21 | <nessy> | then they could all be active at the same time, if the author or user so desired |
| 01:22 | <nessy> | the other requirement was to be able to specify that several <track>s are alternatives to each other and only one of a group should be active at one time |
| 01:22 | <nessy> | for example if you have text audio descriptions in multiple languages, you would only want one of them to be read out by the screenreader at one point in time |
| 01:22 | <othermaciej> | is there a use case for multiple sets of mutually exclusive alternatives? |
| 01:22 | <nessy> | to specify this, we introduced the <trackgroup> |
| 01:23 | <nessy> | then all the <track>s inside the <trackgroup> would work like a radiogroup |
| 01:23 | <othermaciej> | (I guess so if you have both captions and audio descriptions) |
| 01:23 | <othermaciej> | but I'm not sure there is a use case for multiple lists of mutually exclusive alternatives that are all the same type |
| 01:23 | <nessy> | yes, othermaciej, you could have multiple captions in different languages, then multiple text audio descriptions in different languages, then multiple subtitles in different languages |
| 01:24 | <othermaciej> | nor for a set of mutually exclusive alternatives plus some free-floating items that are not part of that set |
| 01:24 | <othermaciej> | again, assuming all are of the same type |
| 01:24 | <nessy> | othermaciej, I tend to agree that that is very unlikely |
| 01:25 | <othermaciej> | I'm not sure what it would mean to have captions in a language and subtitles in a language and to pick both |
| 01:25 | <othermaciej> | does it make sense to enable both french captions and french subtitles? |
| 01:25 | <nessy> | you could have a english subtitle always on and a second subtitle in a different language free for choice |
| 01:25 | <Hixie> | nessy: oh so it's not about having multiple tracks giving the same data in different formats? (like srt and ttml?) |
| 01:25 | <nessy> | well, that, too |
| 01:26 | <othermaciej> | it seems to be mostly about whether the UI shows mutually exclusive options or independently toggle-able items |
| 01:26 | <nessy> | so, in order to deal with all the complexities of different formats, different languages, and different text types, we just made if completely open |
| 01:26 | <othermaciej> | but I'm not sure <trackgroup>+<track> maps very well to the UI use cases |
| 01:27 | <nessy> | just specify what you want active in parallel in multiple <tracks>s and what you want exclusive inside a <trackgroup> |
| 01:27 | <nessy> | what UI use cases? |
| 01:27 | <Hixie> | hmm |
| 01:27 | <Hixie> | so it seems like there's several things going on here |
| 01:27 | <Hixie> | which should be kept separate |
| 01:27 | <nessy> | indeed |
| 01:27 | <othermaciej> | this markup effectively controls the UI for picking auxiliary tracks (or at least the built-in UI) |
| 01:28 | <othermaciej> | I am not sure how to make a pop-up menu that represents a list of radio groups |
| 01:28 | <nessy> | yes, it would - so trackgroup provides a submenu |
| 01:28 | <othermaciej> | or whether that will be understandable for common use cases |
| 01:28 | <Hixie> | it seems like the UI issue is simply a matter of offering each subtitle track as a mutually exclusive group |
| 01:29 | <othermaciej> | if you have submenus you have already failed at creating good UI |
| 01:29 | <Hixie> | just saying that they are subtitles automatically solves the problem |
| 01:29 | <nessy> | I implemented it here: http://www.annodex.net/~silvia/itext/elephant_no_skin.html |
| 01:30 | <othermaciej> | I also have to admit that I'm not sure I understand the difference between subtitles and captions |
| 01:30 | <Hixie> | for the multiple formats issue, zcorpan was suggesting we just not support that |
| 01:30 | <Hixie> | othermaciej: captions include descriptions of sound effects |
| 01:30 | <othermaciej> | I see |
| 01:30 | <Hixie> | othermaciej: captions are useful when the sound is muted; subtitles are useful when you can hear the sound but don't speak the language |
| 01:30 | <othermaciej> | is it common to have both? do typical users understand this difference when presented in the UI? |
| 01:30 | <Hixie> | it is extremely rare to have both |
| 01:31 | <nessy> | anyone who is deaf understands the difference |
| 01:31 | <othermaciej> | but non-deaf people will have to look at this menu |
| 01:31 | <Hixie> | most of the time you have subtitles for all languages except the main one, and a caption track for that one |
| 01:31 | <nessy> | most others don't care |
| 01:31 | <othermaciej> | assuming they watch foreign films |
| 01:31 | <Hixie> | often labeled "English for the hard of hearing" |
| 01:31 | <nessy> | yup, what Ian said :) |
| 01:31 | <othermaciej> | that label would probably be much more clear to people than "Subtitle" vs "Caption" |
| 01:32 | <othermaciej> | also seems like you want it in a flat menu though |
| 01:32 | <othermaciej> | that's what you get on DVDs anyway |
| 01:33 | <nessy> | YouTube only calls them captions |
| 01:33 | <Hixie> | nessy: was there much demand for supporting multiple formats or was that purely a theoretical thing? |
| 01:34 | <nessy> | oh no, that was a discussion that was very keenly held in favor of multiple formats |
| 01:34 | <nessy> | in particular for allowing both srt and dfxp |
| 01:34 | <nessy> | I think you will be killed if you disallow multiple formats ;) |
| 01:35 | <doublec> | that's what they said about video - he's still alive :) |
| 01:36 | <Hixie> | we didn't disallow multiple formats |
| 01:36 | <Hixie> | for video |
| 01:37 | <Hixie> | nessy: so people really wanted to ship two different sets of titles for each track? |
| 01:37 | <Hixie> | nessy: or did they want the option to use one or the other? |
| 01:37 | <Hixie> | because those are different use cases |
| 01:39 | <nessy> | they wanted the option to use one or the other |
| 01:39 | <nessy> | nobody wants to ship multiple formats, I think |
| 01:39 | <Hixie> | oh ok |
| 01:39 | <Hixie> | well then |
| 01:39 | <Hixie> | no need for multiple <source>s for each <track> |
| 01:39 | <nessy> | which is why I gave you the feedback that <source> didn't really solve the problem (did you get the email?) |
| 01:40 | <Hixie> | and the people who want to use ttml can work on convincing the UAs that implementing their beast is a good idea |
| 01:40 | <Hixie> | hmm |
| 01:40 | <Hixie> | i got the one that says: |
| 01:40 | <Hixie> | BTW: did you get my earlier feedback email on your first draft? Was |
| 01:40 | <Hixie> | wondering if you got anything out of it. |
| 01:40 | <nessy> | yeah, that one :) |
| 01:40 | <Hixie> | don't think i got the one before that, unless it was the one entitled "your irc question" |
| 01:41 | <nessy> | might have been that one |
| 01:41 | <Hixie> | k |
| 01:41 | <Hixie> | then i have them in my bucket :-) |
| 01:41 | <nessy> | ah, there was another one I think - let me check |
| 01:42 | <nessy> | the one titled diverse subtitles stuff |
| 01:42 | <annevk> | would be nice if we just had to implement a single captioning/subtitling format |
| 01:42 | <nessy> | that was the one that the last one referred to |
| 01:42 | <annevk> | WebSRT looks pretty extensible if we do the parsing right |
| 01:43 | <annevk> | the wiki throws an internal error? |
| 01:43 | <nessy> | annevk: we can try … but if all the fansubbers have to convert their files and all the professional captioners, too, we might not make many friends |
| 01:44 | <othermaciej> | is WebSRT compatible with existing SRT content? |
| 01:45 | <nessy> | also, the multiple formats option were a means to keep a door open for future time-aligned text formats and for other formats such as a/v to be specified in the <track> |
| 01:45 | <nessy> | in which case <source> makes sense again |
| 01:45 | <nessy> | (yeah - can't get to the wiki right now either) |
| 01:48 | <Hixie> | AryehGregor: if you're around, the wiki is now even more broken :-( |
| 01:48 | <Hixie> | othermaciej: yes |
| 01:49 | <Hixie> | othermaciej: in that existing content will get handled fine |
| 01:49 | <Hixie> | nessy: don't seem to have that one |
| 01:49 | <nessy> | oh really!? |
| 01:49 | <nessy> | let me send it again |
| 01:50 | <nessy> | hopefully it didn't get spam captured ... |
| 01:52 | <Hixie> | foudn it in the spam folder |
| 01:52 | <Hixie> | can you send me a third copy to see if it gets past my spam filter? |
| 01:53 | <Hixie> | gmail figured the second was part of the first and spammed it too |
| 01:53 | <Hixie> | so it never forwarded to my main account |
| 01:53 | <annevk> | nessy, supporting up to fifty subtitling formats in a browser is not really a workable solution imo |
| 01:53 | <annevk> | nessy, fun research project maybe on how to do it efficiently, but there is better use of our time |
| 01:53 | <nessy> | thought that might have happened :( |
| 01:53 | <annevk> | nessy, and conversion is prolly relatively straightforward |
| 02:03 | <nessy> | annevk - fifty is indeed overkill - but three is not that bad - after all we support several image and video formats |
| 02:04 | <Hixie> | with the exception of chrome, we support one video format |
| 02:10 | <Hixie> | nessy: got it the third time |
| 02:10 | <nessy> | ah good! |
| 02:11 | <annevk> | nessy, sure, but I rather we didn't :) |
| 02:11 | <annevk> | nessy, we support one styling language, one scripting language, ... |
| 02:12 | <nessy> | they are not media formats |
| 02:12 | <nessy> | I all for having one baseline format that everyone supports |
| 02:13 | <nessy> | but I also think it may be too restrictive to just rely on one |
| 02:13 | <nessy> | actually - I think "one scripting language" may not be quite true… but I'm not an expert there |
| 02:23 | <othermaciej> | "one scripting language" is pretty much true except for IE |
| 02:23 | <Hixie> | should the default be kind=subtitle or kind=caption? |
| 02:23 | <Hixie> | i guess kind=caption |
| 02:25 | <annevk> | nessy, well, as someone indicated we can support more in the future |
| 02:26 | <annevk> | though I guess that would mean <track> cannot be a void element |
| 02:26 | <annevk> | hmm |
| 02:26 | <nessy> | it's also a question of what attributes we give to track, I guess |
| 02:27 | <annevk> | but then I also don't quite see subtitles as a media format |
| 02:33 | <Hixie> | wow, the [CC] symbol isn't in unicode? |
| 02:35 | <Hixie> | ok, checked in a new <track> element. No processing model yet. |
| 02:37 | <nessy> | wow, it's all happening! |
| 02:42 | <nessy> | I assume when you're ready for input there will be an email thread on the public-html list? |
| 02:46 | <Hixie> | yeah |
| 02:51 | <annevk> | where will the WebSRT format be defined? |
| 02:52 | <annevk> | Hixie, the states are not <dfn>d |
| 02:53 | <Hixie> | WebSRT in section 4.8.9.10.3, probably |
| 02:53 | <Hixie> | hm good point thanks |
| 02:53 | <Hixie> | ok, dinner, bbiab |
| 04:14 | <annevk> | "A HTML5-HTML4 comparison which was as short, dry, accurate and complete as possible would be great." |
| 04:14 | <annevk> | ohuh |
| 04:14 | <annevk> | reading lots of friendly stuff today |
| 04:15 | <annevk> | even an ad hominem attack from Sylvain: http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0007.html |
| 04:45 | <Hixie> | annevk: you kinda brought that one onto yourself :-P |
| 04:46 | <Hixie> | though it's unclear what he's talking about |
| 04:46 | <Hixie> | since as far as i can tell all that you've talked about is CORS |
| 04:51 | <annevk> | oh there's more: http://lists.w3.org/Archives/Public/public-webfonts-wg/2010May/0013.html |
| 04:52 | <annevk> | it seems he missed the part where I said "my bad" about bullshit and explained why... |
| 05:07 | <Hixie> | oh crap, i forgot to handle pause-on-exit |
| 05:10 | <Hixie> | Lachy, AryehGregor: wiki is still down |
| 05:17 | <mcarter> | Hixie, are you the author of the peer-to-peer-connection section? |
| 05:17 | <Hixie> | insofar as anyone has authored anything there, yeah |
| 05:19 | <annevk> | how are embedded timed tracks handled by the way? |
| 05:19 | <annevk> | I missed that |
| 05:20 | <mcarter> | Hixie, I assume sendText, sendBitmap, and sendFile are reliable (i.e, you won't be missing parts of the image, and the data will be in order.) Do you have any thoughts on the protocol that should be used here? |
| 05:29 | <nessy> | annevk: through the same JavaScript API |
| 05:30 | <annevk> | ah, just an API, okay |
| 05:30 | <annevk> | didn't look at the API yet and since the wiki is down... |
| 05:31 | <Hixie> | mcarter: my main thought is that i hope someone else will write it :-) |
| 05:42 | <mcarter> | Hixie, how set on this level of abstraction are you? For instance, would you be opposed to an api that combined Text, Bitmap, and File sending into a sendBuffer method, and a set of functions to convert between buffers and files, bitmaps, and text? |
| 05:53 | <annevk> | mcarter, it's very experimental |
| 05:53 | <annevk> | mcarter, much like the TCPConnection API you fixed ;) |
| 05:53 | <annevk> | mcarter, planning on doing it again? :) |
| 05:54 | <mcarter> | annevk, heh, I would love to have a peer to peer connection in the browser |
| 05:55 | <annevk> | me too |
| 05:55 | <mcarter> | I like the idea of pointing at outside specifications for the bulk of the protocol, but I'm a bit nervous because most external protocol specifications are HUGE |
| 05:55 | <annevk> | would be nice if we had something simple |
| 05:56 | <annevk> | IETF might cry though |
| 05:57 | <othermaciej> | the hard part of p2p is finding the relevant peer |
| 05:57 | <othermaciej> | the second hardest part is connecting to said peer even if you are both behind NAT or firewalls or other unpleasant artifacts of network topology |
| 05:58 | <othermaciej> | the protocol to talk to your peer once you have connected is the easy part |
| 05:58 | <mcarter> | othermaciej, ideally we could just use something like STUN for the connection setup |
| 05:58 | <mcarter> | othermaciej, as far as finding a relevant peer, I think we can just not specify that for now. Developers can easily write web applications to do that |
| 05:59 | <othermaciej> | mcarter: any time I hear an implementation proposal involving the word "just", I assume the person making it has vastly underestimated the complexity |
| 06:00 | <mcarter> | othermaciej, touch� |
| 06:01 | <doublec> | I think the same about 'easily' |
| 06:01 | <othermaciej> | (the people I most often hear "can't you just..." from are security people, though fortunately that happens less often these days) |
| 06:01 | <mcarter> | othermaciej, Yes, STUN is big and complicated, and relatively hard to implement, but I really meant "just" as pointing out that we at least don't necessarily have to re-specify that part of a p2p protocol |
| 06:02 | <othermaciej> | another hard part of this problem: security |
| 06:03 | <othermaciej> | 1) how do you know the person connecting to your socket is your intended peer? |
| 06:03 | <othermaciej> | 2) how do you make the socket listening code robust against attackers throwing garbage at it? now they have a way to push untrusted data into the browser without you even browsing... |
| 06:03 | <othermaciej> | 3) how do you avoid this being used to build botnets? |
| 06:04 | <othermaciej> | not to say it's impossible, but I don't think the end result will be something simple |
| 06:04 | <othermaciej> | gotta run, later folks |
| 06:04 | <mcarter> | othermaciej, take care |
| 06:13 | <annevk> | I wonder if I am the only one who uses cite="" as a replacement for <a> |
| 06:14 | <jwm> | you are |
| 06:17 | <annevk> | I suspect Joe Clark and Karl Dubost might be guilty of it as well |
| 06:20 | <karlcow> | not exactly I use cite to associate the content of the blockquote with a *uri*, not as a replacement for a. Sometimes in the text, you will find the same uri for linking to the page sometimes not. For example, with cite="urn:isbn:978-2-07-034951-7" |
| 06:22 | <nessy> | what does <cite> give you over <a>? |
| 06:25 | <karlcow> | nessy: do you have a content model on how you use a with a blockquote which associates a and the blockquote (and sometimes to a reference which is not an hyperlink)? |
| 06:25 | <nessy> | sure, for that use case |
| 06:26 | <karlcow> | interested to see which solutions you would recommend. |
| 06:26 | <nessy> | what I meant was: when annevk said he would use <cite> instead of <a>, I wondered why - for the simple case where you're linking to a Web page |
| 06:27 | <karlcow> | the "a" is inside the "blockquote" or outside? |
| 06:27 | <nessy> | either |
| 06:28 | <karlcow> | how do we associate the content of the "blockquote" with the "a" |
| 06:28 | <nessy> | (btw: I'm not suggesting anything - I'm trying to learn) |
| 06:28 | <karlcow> | nessy: yes, understood. |
| 06:29 | <nessy> | if I'm not after associating a blockquote with a hyperlink, then <a> would be sufficient, right? |
| 06:29 | <karlcow> | I use cite because I never found a way which was not ambiguous on how associating text of blockquote with a specific uris (knowing in addition that the text can contain sometimes hyperlinks itself.) |
| 06:30 | <nessy> | ah I see |
| 06:30 | <nessy> | we're talking about the cite attribute and not the cite element? |
| 06:31 | <karlcow> | yes cite attribute |
| 06:31 | <nessy> | fair enough |
| 06:31 | <karlcow> | cite element is another issue ;) but once at a time :) |
| 06:34 | <karlcow> | Some use cases I had given when I made a review of xhtml2 in the past, http://lists.w3.org/Archives/Public/www-html/2004Feb/0070 |
| 06:35 | <annevk> | nessy, cite="" over <a>, not <cite> |
| 06:35 | <nessy> | yup, got it :) |
| 06:35 | <annevk> | example: http://annevankesteren.nl/2010/05/h264-licensing |
| 06:37 | <nessy> | damned, I can't click through on the quotes :( |
| 06:37 | <nessy> | maybe safari doesn't support the cite attribute? |
| 06:38 | <nessy> | ah, it's underneath, sorry - that is really irritating |
| 06:39 | <annevk> | ooh, it's not meant to be good :) |
| 06:39 | <annevk> | and that's implemented via JavaScript |
| 06:39 | <annevk> | UAs don't really seem to expose it at all :/ |
| 06:40 | <annevk> | at some point I want to implement it via XBL2 |
| 06:40 | <nessy> | oh - no wonder I don't find it useful ;) |
| 06:40 | <annevk> | create a little popup when you hover the quote |
| 06:40 | <nessy> | anyway - I'm now lost reading the articles - thanks! |
| 06:40 | <annevk> | oops, maybe shouldn't have used a post on video as example :) |
| 06:41 | <nessy> | lol |
| 06:42 | <nessy> | I read the earlier blog post of MS, but wasn't yet aware of this new one |
| 06:42 | <nessy> | too much client work in the last week... |
| 06:50 | <roc> | annevk: I think what Dean is saying is that third-party apps that use Windows codecs are "covered" by Microsoft's license ... but they still have to abide by the limits of that license |
| 06:50 | <roc> | or something like that |
| 06:51 | <annevk> | yeah, I figured |
| 06:52 | <annevk> | he just didn't say anything about developers and paying |
| 06:52 | <annevk> | which was the key point |
| 07:01 | <annevk> | oh, hey TabAtkins__ joined the WebFonts WG |
| 07:01 | <TabAtkins__> | Yus. |
| 07:01 | <annevk> | gonna help me out? |
| 07:01 | <annevk> | just pointed out you guys don't do CORS: http://lists.w3.org/Archives/Public/www-font/2010AprJun/0015.html |
| 07:01 | <TabAtkins__> | I had meant to join it when it formed, but it got lost in the move and affiliations change. |
| 07:03 | <TabAtkins__> | We don't? Interesting. I'll see if I can talk to the guys that did fonts this week. |
| 07:11 | <foolip> | Hixie: here now |
| 07:54 | <foolip> | ok, I see the issue was <trackgroup> |
| 07:56 | <foolip> | I think we want to make it as trivial as possible to handle the typical multi-language subtitle case, i.e. mutually exclusive <track>s |
| 07:57 | <foolip> | still, allowing for parallell tracks of some kinds seems reasonable. |
| 07:57 | <foolip> | if there's a less intrusive way I'd like that, I'm not particularly attached to <trackgroup> |
| 08:10 | <Hixie> | foolip: k |
| 08:12 | <othermaciej> | good evening |
| 08:13 | <Hixie> | oh cool, the wiki works again |
| 08:30 | Hixie | updates the IDL definitions |
| 08:34 | <foolip> | Hixie: do you already have a solution in mind? |
| 08:41 | <nessy> | foolip: http://wiki.whatwg.org/wiki/Timed_tracks |
| 08:42 | <nessy> | foolip: also note http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-track-element |
| 08:51 | <foolip> | nessy: I've skimmed what little there is in the spec, it seems to disallow two <track>s of the same kind/lang/label |
| 08:52 | <foolip> | oh, nice figure: http://wiki.whatwg.org/wiki/Timed_tracks#Architecture |
| 08:54 | <zcorpan> | Hixie: do you envision <track> being used for audio/video captions in the future? or separate <audio>/<video> for that use case? |
| 08:54 | <foolip> | so, looks like the intention is that CSS applied to <video> cascades to the external tracks, which I guess does make sense if one wants to style multiplexed tracks too (cc zcorpan) |
| 08:56 | <foolip> | http://damowmow.com/temp/srtspec |
| 08:56 | <Hixie> | zcorpan: i expect we'll have to sync multiple media elements, rather than have them be part of <track> |
| 08:56 | <Hixie> | zcorpan: since basically we'd have to duplicate all of <video> to do overlaid sign language captions |
| 08:57 | <zcorpan> | Hixie: ok |
| 08:57 | <Hixie> | no plans to do that this time though |
| 09:16 | <annevk> | Hixie, <span title="dom-MutableMediaTrack-addCue">addCue"> doesn't work |
| 09:21 | <Hixie> | thx |
| 09:23 | hsivonen | sighs at the //head/object thread |
| 09:23 | <Hixie> | what order should video.tracks be in? |
| 09:27 | <foolip> | Hixie: first <track>s in document-order, then tracks from the media resource, IMO |
| 09:28 | <Hixie> | so if you insert a <track>, it renumbers existing tracks? |
| 09:28 | <Hixie> | that'd be a bit weird |
| 09:29 | <othermaciej_> | you could do the media resource, then external tracks, in which case you can avoid any renumering by always appending |
| 09:29 | <foolip> | I think with multiple <source>s where only some have internal tracks would be worse, where the script breaks because the order changed |
| 09:29 | <Hixie> | othermaciej_: you get the external ones first |
| 09:30 | <Hixie> | othermaciej_: almost always |
| 09:30 | <othermaciej_> | is it at all common to have both? |
| 09:30 | <Hixie> | othermaciej_: since they are declared in the file, which is likely to be read long before the network returns the video |
| 09:30 | <Hixie> | s/file/html/ |
| 09:30 | <othermaciej_> | ah, I see what you mean |
| 09:30 | <Hixie> | btw there's also a third source, which is scripted tracks |
| 09:31 | <othermaciej_> | I don't think you can avoid renumbering when you add <track>s in the DOM then |
| 09:31 | <othermaciej_> | unless you give up on the track state being inferrable from the DOM |
| 09:31 | <othermaciej_> | generally it's good for DOM APIs not to be path-dependent |
| 09:31 | <othermaciej_> | IMO |
| 09:32 | <Hixie> | well we can add them in first-come-first-served, which trades predictability from run to run for consistency of the index of the objects in the array |
| 09:32 | <foolip> | it's quite likely not all browsers will detect the same resource-internal tracks during a period of implementation, which favors putting them at the end where it creates a smaller mess |
| 09:32 | <Hixie> | or we can do them in a defined order, in which case you can't keep a hold of the position... but then you can keep hold of the object that represents the track, so that's ok |
| 09:32 | <Hixie> | ok, fair enough |
| 09:33 | <Hixie> | <track>, then script-added, then those in the video file |
| 09:33 | <Hixie> | should the <track> ones be sorted in the order they were inserted into the <Video> element, or in DOM order? I guess the latter, if they are removed when you remove the <Track> element |
| 09:37 | <annevk> | DOM order is what most collections do |
| 09:37 | <annevk> | apart from some esoteric form collection iirc |
| 09:38 | <Hixie> | should it be possible to dynamically change a track's kind, label, and language? |
| 09:39 | <othermaciej> | if it's represented by an element and those things are attributes, it would be weird if you couldn't |
| 09:39 | <Hixie> | i guess so |
| 09:39 | <Hixie> | k |
| 10:59 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#timed-tracks - the basic data model definitions |
| 10:59 | <Hixie> | still nothing really useful :-) |
| 11:00 | <Hixie> | nn |
| 11:35 | <mcarter> | Hixie, do you have any familiarity and/or biases for/against the sctp protocol? |
| 12:15 | <nessy> | that was a late Hixie night! |
| 12:16 | <nessy> | good start on video a11y stuff though! |
| 12:16 | <gsnedders> | Late? That's quite early by his standards, no? |
| 12:16 | <Philip`> | Hixie's standards are weird |
| 12:17 | Philip` | may or may not have intended the double meaning |
| 12:17 | <zcorpan> | Hixie's standards are just drafts |
| 12:18 | <nessy> | lol |
| 12:22 | <Dashiva> | They can never become standards with only one implementation, after all |
| 13:46 | <mut> | hey, anyone know if there is a way i can get coordinates of a line i drew on canvas, after i applied a transform() ? |
| 13:50 | <Philip`> | mut: You can't, except by writing code to do the maths yourself |
| 13:51 | <mut> | ok |
| 13:51 | <mut> | is there any documentation on scale/translate functions, so i can see how it works? |
| 13:52 | <Philip`> | (I think "setTransform(m11, m12, m21, m22, dx, dy); moveTo(x, y)" is equivalent to "moveTo(m11*x+m21*y+dx, m12*x+m22*y+dy)") |
| 13:53 | <mut> | ok |
| 13:53 | <mut> | that looks pretty easy |
| 13:53 | <Philip`> | scale/translate are easy - they just multiply or add to the coordinates |
| 13:53 | <mut> | its rotate thats bothering me |
| 13:53 | <mut> | :P |
| 13:54 | <Philip`> | Ah - rotate(a) is like transform(cos(a), sin(a), -sin(a), cos(a), 0, 0) |
| 13:54 | <mut> | ah yea |
| 13:55 | <mut> | so if i recreate those functions, i can actually replace them for my purposes |
| 13:55 | <jgraham> | It's just linear algebra :) |
| 13:55 | <Philip`> | or maybe more like transform(cos(a), -sin(a), sin(a), cos(a), 0, 0) |
| 13:55 | <mut> | heh yea its a long time since ive done any :) |
| 13:55 | <theMadness> | All this math is making me feel like a real programmer (as opposed to a web programmer, of course) |
| 13:56 | <mut> | thanks a lot Philip` |
| 13:56 | <mut> | ill just crack on and write my own functions |
| 14:12 | <workmad3> | Philip`: I think that's just the difference between clockwise and anti-clockwise rotation :) |
| 14:13 | workmad3 | misses playing around with mathes in programming |
| 14:19 | <mr_danie1> | mut: if you have a app where it is important to track the current position of an element, maybe SVG is a better solution for your problem |
| 14:20 | <mr_danie1> | especially when you want to track the mouse as an input source |
| 14:20 | <mut> | hmmm |
| 14:20 | <mut> | well i dont need to track the mouse |
| 14:21 | <mut> | its ok, i think ill be ok now |
| 14:21 | <mut> | its not as hard as i first feared |
| 14:25 | <mut> | and i can overwrite the translate/rotate functions right? |
| 14:29 | <annevk> | http://lists.w3.org/Archives/Member/w3c-ac-forum/2010AprJun/0073.html (W3C Member-only; also o_O) |
| 14:36 | <raider5> | does anyone have any guidance regarding source order vs the visual order? the only decent information we can find is : http://usability.com.au/resources/source-order.cfm |
| 14:38 | <raider5> | The majority of online resources are conflicted on the merits of having content first in the source |
| 14:42 | <JohnnyAmerica> | raider5: It depends on the context |
| 14:44 | <raider5> | JohnnyAmerica: in what way? |
| 14:59 | <theMadness> | By the way, congrats @adactio for the new book. |
| 14:59 | <adactio> | theMadness: thank you. |
| 14:59 | <annevk> | oh hey |
| 14:59 | <annevk> | just read the first chapter |
| 14:59 | <annevk> | read well :) |
| 15:38 | <hsivonen> | annevk: http://lists.w3.org/Archives/Member/tag/2010Apr/ |
| 15:39 | <annevk> | gsnedders, actually Opera doesn't support innerHTML in XML |
| 15:39 | <annevk> | gsnedders, Gecko does |
| 15:39 | hsivonen | kinda wishes innerHTML always used the HTML serialization--even in XML DOMs |
| 15:40 | <gsnedders> | annevk: We do in XHTML |
| 15:40 | <gsnedders> | hsivonen: We do in XHTML |
| 15:41 | <annevk> | gsnedders, no, we use the HTML parser; that's wrong per spec |
| 15:42 | <gsnedders> | That's always using the HTML serialization. |
| 15:42 | <gsnedders> | I know it's wrong per spec. |
| 15:42 | <gsnedders> | Having a bug free impl and supporting something aren't identical, IMO |
| 15:43 | <annevk> | this is a fundamental flaw in the feature implementation |
| 15:43 | <annevk> | but whatever |
| 15:45 | <annevk> | "Internet Explorer web browser use drops below 60%" -- maybe that explains all the markety IE blog posts and Sylvain being cranky :p |
| 15:45 | <theMadness> | That goes without saying. |
| 16:02 | <raider5> | does anyone have any guidance regarding source order vs the visual order? the only decent information we can find is : http://usability.com.au/resources/source-order.cfm |
| 16:21 | <TabAtkins> | raider5: I'd probably listen to actual usability experts, but as far as I know Google puts more weight on content earlier in the page, so having good source order can help your rank at least. |
| 16:26 | <raider5> | TabAtkins: see that's the problem, there a lot of people saying similar things, however there is a lack of any evidence unfortunately. Do you have any concrete links you could point me to? |
| 16:27 | <TabAtkins> | Well, that link you provided is backed up by actual usability testing. |
| 16:27 | <TabAtkins> | And so seems reasonably beleivable. |
| 16:32 | <raider5> | yes but there is debate regarding the results of the testing, it would be good to have some official info from sound sources |
| 16:32 | <TabAtkins> | When you say "debate", are you just referring to the fact that the results were somewhat inconclusive on the question of source order in that study, or are there actual objections to the data in that study? |
| 16:34 | <raider5> | a bit of both really |
| 16:35 | <raider5> | I don't have the links to hand at the moment |
| 16:36 | <raider5> | Bruce Lawson seems to go with content first: http://www.brucelawson.co.uk/2007/navigation-or-content-first/ |
| 16:36 | <TabAtkins> | Kk, then I dunno personally. I personally prefer content-first for organizational purposes, and from everything I've read it's neutral at worst. |
| 16:38 | <raider5> | yeah that's the conclusion I'm coming to... the only thing that is pushing me more towards navigation first is that the majority of sites are structured that way... it's almost a standard which people expect |
| 16:38 | <raider5> | and if there is no benefit, I'd rather stick with convention |
| 16:39 | <rektide> | why oh why did ian give in w/r/t video codecs |
| 16:39 | <rektide> | h.264 everywhere is going to be utter hell |
| 16:39 | <rektide> | i've already seen two posts calling this gif wars 2.0 |
| 16:40 | <erlehmann> | rektide, because he can't change anything. |
| 16:40 | <Lachy> | rektide, there have been many comparisons with gif ever since this issue first came up |
| 16:40 | <erlehmann> | opera, mozilla, google are willing to implement theora in their browsers regardless of if it is mentioned in the spec. |
| 16:41 | <erlehmann> | and apple or microsoft are not gonna give in because of spec text. |
| 16:41 | <erlehmann> | especially not microsoft. |
| 16:41 | <erlehmann> | rektide, html5 is more descriptive than normative |
| 16:41 | <rektide> | microsoft not giving in |
| 16:41 | <rektide> | doesnt mean we shouldnt lord it against them |
| 16:42 | <rektide> | doesnt mean we shouldnt put it in the spec |
| 16:42 | <rektide> | specs are there a model for what you ought to be doing |
| 16:42 | <rektide> | *as a model |
| 16:44 | <Lachy> | rektide, the purpose of the spec is to define things that browsers will interoperably implement. It's not helpful to have the spec define a requirement that browser vendors have stated they will ignore |
| 16:44 | <rektide> | so the only time a spec is worth doing is if its unanimous? |
| 16:47 | <Lachy> | no, decisions made in the spec certainly aren't always unanimous. But they should at least be implementable and there should at least be a willingness among vendors to implement it. |
| 16:48 | <Lachy> | teh bottom line is, everyone knows the situation is not ideal. But trying to get the spec to mandate a specific codec for whatever reason will not help in the slightest to resolve the issues that web developers now face |
| 16:49 | <hober> | yup |
| 16:53 | <rektide> | i relent to acknowledging there is no way out, that the whole fiasco is a huge grey area. |
| 16:54 | <rektide> | i'd like to thank binary42 for taking me to task on the legal complexities of the issue in another channel |
| 17:25 | <AryehGregor> | Hixie, wiki is working for me . . . I see some errors in /home/whatwikiuser/logs/mw-db-error claiming some tables doesn't exist, lost MySQL connections, broken tables, that kind of thing, but it seems to have stopped.about eleven hours ago. |
| 17:41 | <JonathanNeal> | Hello HTML5 |
| 18:54 | <AryehGregor> | ROFL at most disproportionately common color names for men: http://blog.xkcd.com/2010/05/03/color-survey-results/ |
| 18:59 | <rektide> | where does the track / mediatrack work have origins? |
| 18:59 | <rektide> | i'm thinking of kate / cmml / annotea / aria |
| 18:59 | <rektide> | as other standards for annotation of realtime streams |
| 19:00 | <rektide> | not that they have api's |
| 19:58 | <AryehGregor> | Wait, there's an Erik Möller who works for Opera? That's also the name of the deputy director of Wikimedia. |
| 19:58 | <AryehGregor> | Confusing. :() |
| 19:58 | <AryehGregor> | s/)$// |
| 19:59 | <AryehGregor> | Perhaps people need to adopt GUIDs of some kind. It would make some things so much simpler. |
| 20:01 | <othermaciej> | AryehGregor: we just need to assign everyone a unique URI |
| 20:01 | <AryehGregor> | That's an excellent idea. You could then leverage it for personal websites and provider-independent e-mail addresses, too. |
| 20:02 | <AryehGregor> | Well, the latter only if it's an actual domain name, perhaps, but you could also define some mapping of this URI format to e-mail addresses, perhaps. |
| 20:06 | <Dashiva> | That kind of thinking is so typical |
| 20:06 | <Dashiva> | What about people who go into witness protection? |
| 20:07 | <AryehGregor> | I never said each person needs to have only *one* GUID. No two people can have the same GUID, but no one says you can't have multiples, or change them. |
| 20:10 | <Dashiva> | That leads to a host of problems of its own |
| 20:16 | <Icozzo> | just what everyone wants, to be uniquely identifiable on the internet |
| 20:17 | <AryehGregor> | Precisely! |
| 20:17 | <Icozzo> | but this GUID system is really just email by another name isn't it? |
| 20:18 | <AryehGregor> | . . . maybe? |
| 20:19 | <AryehGregor> | I was indeed able to distinguish the two individuals in this case by @opera.com vs. @wikimedia.org. |
| 20:19 | <Icozzo> | then that means.. im uniquely identifiable on the internet by my.. email address!?! |
| 20:19 | Icozzo | runs |
| 20:19 | <AryehGregor> | I was really thinking more like inventing some memorable suffix to add to your name everywhere so people can tell you apart from other people with the same name. |
| 20:20 | <AryehGregor> | Of course, I'd have no problem, since I'm almost certainly the only person in the world with my name. |
| 20:20 | <Icozzo> | until I have a child, that is |
| 20:20 | <AryehGregor> | What? |
| 20:20 | <Icozzo> | then again, in the long run it's probably just cheaper to get a name change |
| 20:21 | <AryehGregor> | Well, that's one way to fix it. Have a global registry of names, and prohibit anyone from adopting a legal name that's already taken. |
| 20:22 | <AryehGregor> | That would promote so much creativity in naming! |
| 20:22 | <Icozzo> | Nick44651 Smith |
| 20:22 | <AryehGregor> | It must be a great idea! |
| 20:22 | <jwm> | hehe |
| 20:23 | <AryehGregor> | We can decentralize it by requiring toponyms. We could require people to add the (unique-ified) name of their city to the end, like "Aryeh Gregor of New York". Then you would only have to maintain per-city registries. |
| 20:23 | <Icozzo> | I wonder how many days it would take until something like xXxWarrior69xXx is registered as a legal name |
| 20:23 | <AryehGregor> | Yes, well -- if it's good enough for the Internet, it's good enough for real life. |
| 20:23 | <AryehGregor> | That's my motto. |
| 20:23 | <AryehGregor> | Possibly because I don't have a real life. |
| 20:24 | <Icozzo> | That's how it worked before surnames didn't it? |
| 20:24 | <AryehGregor> | Before surnames, people mostly relied on the fact that almost nobody traveled much. |
| 20:24 | <AryehGregor> | Also, in most places you had other disambiguation anyway, like a patronymic or toponym or such. |
| 20:25 | <AryehGregor> | For instance, ancient Israelites were identified by their personal name, father's name, and tribe. Greeks usually used a personal name, plus some combination of patronymic and toponym. |
| 20:26 | <AryehGregor> | Republican Rome had family names, but you also used the name of your father, *and* his father, because the Romans had a very small supply of personal names. |
| 20:26 | <AryehGregor> | So few that they almost all had one- or two-letter abbreviations. |
| 20:26 | <AryehGregor> | So Julius Caesar would formally be known as C·IVLIVS·C·F·C·N·CAESAR – "Gaius Julius, son of Gaius, grandson of Gaius, Caesar". |
| 20:27 | <AryehGregor> | Nobody bothers with the "Gaius" part because like 10% of Roman men were named "Gaius". |
| 20:27 | <Icozzo> | yea that's what I was thinking of, toponymy in Greece |
| 20:27 | <AryehGregor> | Everyone called each other by last names. If two people had the same last name, they got nicknames. |
| 20:27 | <AryehGregor> | Like Pliny the Younger and Pliny the Elder, or Scipio Africanus and Scipio . . . whatever the other one was, Germanicus or whatnot. |
| 20:28 | <AryehGregor> | Women didn't even get first names at all, they got numbered. The daughter of someone in the Julius family would be named Julia. If she had a sister, they'd be Julia Majora and Julia Minora. More, and it would be Julia Prima, Julia Secunda, Julia Tertia, . . . |
| 20:28 | <AryehGregor> | Romans were crazy. |
| 20:28 | <AryehGregor> | They also gave us our calendar, with inexplicable random month lengths. |
| 20:30 | <AryehGregor> | http://en.wikipedia.org/wiki/Roman_naming_conventions |
| 20:31 | <jgraham> | Do what MikeSmith does and trademark your name :) |
| 20:32 | <variable> | I'm in the proccess of writing up the rational for <image> being treated the same as <img> but I can't find any sources that provide informations about sites that use the incorrect element. Does anyone knnow of any |
| 20:32 | <variable> | know of any? |
| 20:34 | <jgraham> | variable: Philip` might know |
| 20:35 | <variable> | Philip`: ping |
| 20:35 | <Philip`> | variable: imdb.com did, a while ago |
| 20:35 | <variable> | #2) Are there any other element or issues in the spec that need some kind of rational written up |
| 20:35 | <Icozzo> | is there any way to specify anti-aliasing in the canvas tag atm? |
| 20:36 | <variable> | Philip`: interesting. Ian mentioned to me that .02% of sites had this problem but didn't give me any sources. Do you know where he may have gotten this number from? |
| 20:37 | <Philip`> | variable: He probably got it from the Google index |
| 20:38 | <Philip`> | variable: http://genforum.com/cgi-bin/latest.cgi?kabberud |
| 20:39 | <variable> | ok - thanks |
| 20:39 | <Philip`> | variable: http://www.bonsmara.org.au/index.php?option=com_content&task=view&id=15&Itemid=29 |
| 20:39 | <Philip`> | variable: http://www.db0anf.de/app/aprs/stations/digiusermap-VE4ALW-9 |
| 20:39 | <variable> | Philip`: JW - how did you find those pages? Google didn't help me much ;) |
| 20:40 | <Philip`> | variable: Grepping the page data from http://www.dotnetdotcom.org/ finds many dozens |
| 20:40 | <variable> | I'll look now ;) |
| 20:40 | <jgraham> | variable: I think pretty much the whole spec lacks a rationale document :) |
| 20:41 | <variable> | jgraham: heh - I plan on working on that - but I can't work on the whole thing at once |
| 20:43 | <jgraham> | variable: Have fun :) I suggest working through the parts that you particularly care about first and seeing how far you get |
| 20:43 | <jgraham> | (you might, of course, care most about the parts that people have complained about the most) |
| 20:43 | Philip` | doesn't have a percentage count of pages with <image>, since he only counted post-parser element names and so there's none called "image" |
| 20:46 | <variable> | jgraham: nice subtle hint. Any particular parts that people have complained the most about. I follow the ML but I don't keep track of statistics of complaints ;) |
| 20:46 | <Icozzo> | That'd be a good question for google :P |
| 20:47 | <variable> | ok |
| 20:47 | variable | googles |
| 20:47 | <Icozzo> | No i mean the percentage count of pages using <image> instead of <img>, sorry. |
| 20:47 | <Icozzo> | They'd know better than anyone. |
| 20:48 | <variable> | lcozzo - true. Just wondering if anyone had sources re that specific number |
| 20:49 | variable | goes to create wiki page |
| 20:49 | <Icozzo> | Yea, that's the first I've ever heard of the 0.02% figure |
| 20:49 | <variable> | ok - no problem |
| 20:50 | <variable> | in the tradition of wikipedia I |
| 20:50 | <variable> | in the tradition of wikipedia I'll just use "citation needed" |
| 20:50 | <variable> | ;) |
| 20:50 | <Icozzo> | :P |
| 20:52 | <jgraham> | variable: Not really. A11y issues tend to be controversial |
| 20:52 | <variable> | ;) |
| 20:53 | <Dashiva> | "The goal of type="username" is to indicate to the UA which form is the login form. This would allow features such as "remember me" and autofill to be done in the UA instead of in the browser." |
| 20:53 | <Dashiva> | Does anyone understand what the UA is supposed to be here? |
| 20:53 | <variable> | Dashiva: that was my email ;) I thing I meant instead of the website :) |
| 20:53 | <Philip`> | What's the UA instead of the browser? |
| 20:53 | <Philip`> | Oh |
| 20:55 | <variable> | Dashiva: part of the reason for type="username" is to make it easier for projects such as Mozilla Accounts Manager (a project that seeks to put the login/logout into the browser) |
| 21:02 | <variable> | Philip`: should I put those specific examples in the wiki page or should I leave it general "some times" |
| 21:04 | <Philip`> | variable: Depends on whether you think reasonable people will doubt an unsubstantiated but easy-to-demonstrate statement that many examples exist |
| 21:05 | <Philip`> | and depends on whether there's reasons to *not* include specific examples |
| 21:06 | <variable> | http://wiki.whatwg.org/wiki/Rationale |
| 21:06 | <variable> | any comments? |
| 21:17 | <Philip`> | variable: (if you read the logs): Why does that page say 0.2%? I thought you said 0.02% earlier |
| 21:18 | <Philip`> | variable: <plaintext> wasn't IE - it was already obsolete before http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt |
| 21:21 | <variable> | http://wiki.whatwg.org/wiki/Rationale -- any comments? |
| 21:21 | <variable> | sorry I pinged out for a moment |
| 21:22 | <variable> | Philip`: jgraham ? |
| 21:27 | <variable> | . |
| 21:31 | <jgraham> | variable: sorry been getting my dose of pre-election political comedy |
| 21:31 | <jgraham> | 15:22 < Philip`> variable: (if you read the logs): Why does that page say 0.2%? I thought you said 0.02% earlier |
| 21:31 | <jgraham> | 15:24 < Philip`> variable: <plaintext> wasn't IE - it was already obsolete before |
| 21:32 | <jgraham> | http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt |
| 21:32 | <jgraham> | Also don't webkit and IE support <image>? |
| 21:32 | <variable> | jgraham: no idea - I can't test them |
| 21:34 | variable | updates page |
| 21:35 | <jgraham> | variable: You are on a machine with no webkit? Impressive... |
| 21:35 | <variable> | jgraham: I have links, opera, and firefox - that is about it |
| 21:36 | <variable> | *oh and I might have dillo ;) |
| 21:36 | <jgraham> | Chromium? |
| 21:36 | <jgraham> | Anyway it works in webkit too |
| 21:36 | <jgraham> | I'm pretty sure it works in IE also |
| 21:36 | <variable> | kk - I'll add it to the page |
| 21:37 | <variable> | the wiki doesn't have <ref> support - :( |
| 21:42 | <variable> | I just rechecked my email: Ian said 0.2 not 0.02 |
| 21:46 | <variable> | . |
| 21:46 | <variable> | jgrahm - pre which elections? Also I just updated the page |
| 21:50 | <jgraham> | variable: UK general election |
| 21:51 | <jgraham> | Not that I am currently living in the UK, but it is nice to laugh at the politicians anyway |
| 21:52 | <variable> | heh - true |
| 21:53 | <Philip`> | It's a nail-biting race between the one offering fairness, the one offering change, and the one offering change and fairness |
| 21:54 | <variable> | Philip`: look at the last politician to offer change (in the US) and decide if you really want it ; |
| 21:55 | variable | says nothing about my opinion on the current US pres. |
| 21:55 | <jgraham> | I guess Philip` will get change and fairness regardless (unless he is registered to vote somewhere other than Cambridge, in which case I have no idea) |
| 21:56 | <Dashiva> | I didn't know the conservatives were offering change |
| 21:57 | <Philip`> | Fairness sounds good and change sounds good, so I should be happy whatever the outcome is |
| 21:57 | <jgraham> | I assume change == conservatives, fairness == Labour and both == Lib Dem |
| 21:57 | <jgraham> | In Philip`'s scheme |
| 21:58 | <Dashiva> | I have equal trouble attributing fairness to conservatives as I have with change |
| 21:58 | <Philip`> | It's not my scheme, it's theirs |
| 21:59 | <jgraham> | Dashiva: Possibly their slogan is "Change that will disappoint" |
| 21:59 | <Dashiva> | Unless they mean "change back to how things were before" |
| 22:00 | <jgraham> | It's not a vote winner but would be at least 50% honest |
| 22:00 | <Dashiva> | Feudalism would be a huge change without accidentally creating fairness |
| 23:32 | <Hixie> | so loading timed tracks needs to delay playback |
| 23:32 | <Hixie> | there are several ways we could do this |
| 23:33 | <Hixie> | we could make timed tracks interact with readyState |
| 23:33 | <Hixie> | this seems like it would be rather complicated though |
| 23:33 | <Hixie> | we could just make potentially playing be false when there's pending tracks |
| 23:33 | <Hixie> | that seems simplest |
| 23:33 | <Hixie> | if we do the latter, we presumably need to fire an event to say that this is what we're waiting for |
| 23:33 | <Hixie> | should we fire 'waiting'? |
| 23:33 | <Hixie> | 'stalled'? |
| 23:34 | <Hixie> | a new event? |
| 23:34 | <Hixie> | doing a new event has the advantage that we don't have to fiddle with the definitions of the existing events |
| 23:34 | <Hixie> | and makes it easier to work out what exactly we're waiting for |
| 23:34 | <Hixie> | but means yet more events to wait for |
| 23:35 | <Dashiva> | Possibly a risk in people writing code not considering timed tracks, which then breaks with tracks? |
| 23:37 | <Hixie> | that's a risk either way |
| 23:40 | <Hixie> | i think i'm leaning towards firing 'waiting' at the media element, as if we were buffering |
| 23:40 | <Hixie> | which will be a pain to specify, but is probably better than having a different event |
| 23:43 | <nessy> | I'm not even sure I would want the video to have to wait for captions to be loaded |
| 23:44 | <nessy> | most of the time the captions will be loaded fast and stalling the video in the middle of playback seems disruptive |
| 23:45 | <nessy> | would it be better to have a sort of state on the track element that explains how far it is along with loading and if somebody really wants their video to wait for it, they can pause playback to wait for the appropriate state change? |
| 23:46 | <nessy> | I can understand waiting with putting video into METADATA_LOADED state until all pre-activated track elements are loaded |
| 23:46 | <nessy> | but during playback, i would really find it disruptive |
| 23:46 | <nessy> | YouTube doesn't wait for captions to be received either |