| 01:02 | <Lachy> | othermaciej, can you update the link for the 4th change proposal on ISSUE-88 on the issue-status page? It looks like the page has been moved in the wiki |
| 01:03 | <othermaciej> | Lachy: I will update ISSUE-88 on the status page sometime this evening (can't right now) |
| 01:03 | <Lachy> | Hixie, do you remember the original reason why Content-Langauge was made conforming? |
| 01:03 | <Hixie> | iirc, i18n asked us to, but i have no evidence to support this claim |
| 01:04 | <Hixie> | that variable's problem now :-) |
| 01:04 | <Hixie> | yay variable |
| 01:04 | <Lachy> | haha |
| 01:06 | <Lachy> | If he's going to document the rationale for everything, then I should get him to make a separate rationale page for each feature and using wiki categories, rather than having one long rationale page |
| 01:07 | <Hixie> | i recommend waiting until the page is too long |
| 01:07 | <Hixie> | prematurely fixing such problems just creates busywork :-) |
| 01:08 | <Lachy> | yeah. |
| 01:08 | <Lachy> | that's why I didn't bother mentioning it before. I wasn't sure how much rationale he planned to write |
| 01:08 | <Hixie> | no idea |
| 01:08 | <Hixie> | hopefully he'll get help |
| 01:09 | <Lachy> | I'm sure he'll get help if he asks for it |
| 01:10 | <Lachy> | but I'm not sure many people will be able to dedicate much time to the project |
| 01:20 | <Lachy> | Hixie, this is why you added it http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html |
| 01:21 | <Hixie> | ah, there we go |
| 01:21 | <Hixie> | good archeological-fu you have there |
| 01:21 | <nessy> | Hixie: why is the WebSRT specification inside the HTML5 spec? It's a separate document format, so should be outside IMHO. |
| 01:21 | <Hixie> | same reason websockets is in the html5 spec |
| 01:22 | <Lachy> | so, given that reason for adding it, since it was being used analogolously to lang="", I think that argues against extending it to multiple langauges and potentially against making it non-conforming |
| 01:22 | <Hixie> | nessy: it's part of the web platform and i think we should have everything in one spec |
| 01:22 | <nessy> | so are we also adding SRT in the traditional form? |
| 01:22 | <Hixie> | nessy: ? |
| 01:23 | <Hixie> | Lachy: i certainly agree that we shouldn't make it support multiple languages |
| 01:23 | <Hixie> | Lachy: i could go either way with respect to whether content-language is conforming or not |
| 01:23 | <nessy> | it has a different mime type text/srt , so is a different file format and we want to support that, too, no? |
| 01:23 | <Hixie> | nessy: text/srt is already registered? |
| 01:23 | <nessy> | no, but it is widely used |
| 01:24 | <Hixie> | oh let's just use that then |
| 01:24 | <Hixie> | i'll update the tspec |
| 01:24 | <Hixie> | s/ts/s/ |
| 01:25 | <nessy> | hmm … you're going to just absorb all existing srt and make it part of websrt? |
| 01:25 | <Hixie> | not the X1: Y1: stuff |
| 01:25 | <Hixie> | and not <u> |
| 01:25 | <Hixie> | and not <font...> |
| 01:25 | <Hixie> | but othewise yes |
| 01:25 | <nessy> | you think that's the right way of dealing with the fansubbers? |
| 01:26 | <Hixie> | how do you mean? |
| 01:26 | <nessy> | well, if I had an authoring tool that created srt files with those formats and I distributed them under text/srt and suddently text/srt would mean something else and my files are wrong, I would be pretty pissed off |
| 01:28 | <Hixie> | text/srt currently means nothing and there's no spec for SRT, so I don't see how adding a spec that can just be ignored would make any difference to someone who's happy with the current situation |
| 01:28 | <nessy> | I increasingly think no matter how we spin this, websrt is a different format to srt, even though it is very related and will be compatible most of the time |
| 01:28 | <Hixie> | it's different in the same way HTML5 is different from HTML4, sure |
| 01:29 | <nessy> | hmmm |
| 01:30 | <nessy> | I thought html5 was fully backwards compatible |
| 01:31 | <nessy> | websrt certainly wouldn't be fully backwards compatible with srt |
| 01:31 | <Hixie> | sure it will |
| 01:31 | <nessy> | not the X1: Y1: stuff |
| 01:31 | <nessy> | and not <u> |
| 01:31 | <nessy> | and not <font...> |
| 01:32 | <nessy> | as you said |
| 01:32 | <Hixie> | nobody implements X1 Y1 anyway from what i understand |
| 01:32 | <Hixie> | the <u> and <font...> stuff will become voices, which you can then style as you wish |
| 01:32 | <nessy> | it's a small difference, true, but it is a difference |
| 01:32 | <Hixie> | it's compatible |
| 01:32 | <Hixie> | you can get the same pixels in the end |
| 01:33 | <nessy> | on a compatibility scale, very close to |
| 01:33 | <Hixie> | it's as compatible as HTML5 is to HTML4 |
| 01:33 | <Hixie> | e.g. HTML5 drops profile="" entirely |
| 01:33 | <nessy> | if it was fully compatible, no existing authoring software would need to be changed - but that's not the case |
| 01:34 | <nessy> | but yeah, small changes |
| 01:34 | <Hixie> | no existing authoring software will need to be changed to output files that work with <video>. |
| 01:34 | <Hixie> | SubRip's X1: Y1: output will be ignored, as it is in all existing players as far as I'm aware. |
| 01:35 | <nessy> | would <u> and <font> be interpreted? |
| 01:35 | <Hixie> | the <u> and <font...> stuff will become voices, which you can then style as you wish |
| 01:36 | <nessy> | but unless the <u> and <font> markup are actually interpreted by a WebSRT supporting player, they don't support all srt features |
| 01:36 | <nessy> | anyway - I'd prefer we call the new format text/websrt and leave what exists alone - that's all I'm saying |
| 01:37 | <doublec> | I doubt that all srt players support <u> and <font> either |
| 01:37 | <Hixie> | oh |
| 01:37 | <doublec> | since there's no spec |
| 01:37 | <Hixie> | nessy: i thought you just argued the opposite |
| 01:37 | <Hixie> | frankly if compatibility with existing authoring tools and players is a serious concern, then we need to do reverse-engineering |
| 01:38 | <Hixie> | so far i've not seen anyone rushing to do that, so i assume it's not a serious concern |
| 01:38 | <annevk> | I'd prefer re-using text/srt as that will make it way easier for people to migrate |
| 01:38 | <nessy> | really? |
| 01:38 | <Hixie> | personally i think it's fine if we're compatible with what's out there on a broad basis, but i don't have any reason to believe it's critical that we be compatible with the edge-case features like <font> or <u> or X1: |
| 01:38 | <Hixie> | that we support <font> at all is just a bonus, imho |
| 01:39 | <Hixie> | i originally wasn't going to make it work at all |
| 01:39 | <Hixie> | so that there's a way to do fake it is just a bonus |
| 01:39 | <nessy> | if you created a srt file in an existing authoring tool and published it as text/srt and it didn't include <u> or <font>, then you could immediately also publish it as text/websrt |
| 01:39 | <Hixie> | (we might not want to be able to fake it, as it inteferes a bit with forwards-compat) |
| 01:39 | <Hixie> | let's be honest about this: nobody in reality cares about MIME types |
| 01:39 | <nessy> | are you suggesting we actually interpret <font> and <u> ? |
| 01:40 | <Hixie> | we'll be lucky if we see text/srt, let alone a new type |
| 01:40 | <Hixie> | most of it is gonna be text/plain or text/html |
| 01:40 | <Hixie> | so i really see no benefit to making up a new type |
| 01:40 | <Hixie> | nessy: i'm suggesting we interpret <font...> and <u> as voice declarations |
| 01:40 | <Hixie> | nessy: like <narrator> or <1> |
| 01:40 | <Hixie> | nessy: see the bnf |
| 01:40 | <nessy> | in the browsers or as part of the spec? |
| 01:41 | <Hixie> | what's the difference? |
| 01:41 | <Hixie> | i'm suggesting we change this: |
| 01:41 | <Hixie> | voice := "<" [ number | "sound" | "comment" | "credit" ] ">" |
| 01:41 | <nessy> | well, one is supporting compatibility on the spec level and the other is expecting browsers to just take care of it |
| 01:41 | <Hixie> | to just match "<" [ anything but i | b | ruby | time | lt | amp | text ] ">" |
| 01:42 | <Hixie> | the browsers do what the spec says |
| 01:42 | <Hixie> | so i don't see the difference |
| 01:43 | <nessy> | ah, so the bnf supports parsing <font> and <u> to a voice? |
| 01:44 | <Hixie> | not currently, but i'm arguing we should consider doing that |
| 01:44 | <nessy> | ah ok, yes, I think that would be good |
| 01:44 | <Hixie> | the question is, do we care enough about existing authoring tools, interpreters, and content |
| 01:44 | <Hixie> | if we do, we should actually look at them |
| 01:45 | <Hixie> | nobody seems to be rushing to do that |
| 01:45 | <nessy> | wasn't the whole idea of using srt as the baseline for websrt to care about existing tools? |
| 01:45 | <Hixie> | well, there's caring enough that things will work well, and caring enough that things will work perfecetly |
| 01:45 | <nessy> | everyone is right now watching what is happing in the spec and evaluating it - nobody is rushing to do anything before the spec is somewhat stable |
| 01:45 | <Hixie> | the former doesn't require much research |
| 01:46 | <Hixie> | once the spec is stable i ain't gonna want to change it again :-) |
| 01:46 | <Hixie> | so waiting until after the spec is done is an especially bad thing to do if the direction the spec is in is wrong :-) |
| 01:46 | <nessy> | what I meant was that the first draft is ready - I assume you will be open to input after that still |
| 01:47 | <Hixie> | yes, but input along the lines of "actually i think we used the wrong design principles" is not especially fun |
| 01:47 | <Hixie> | that's why i like to figure out the requirements first :-) |
| 01:47 | <Lachy> | wow, I really like it when bad change proposals include useful, self-refuting evidence that can be used against them. :-) It really makes the process a lot easier. |
| 01:47 | <Hixie> | Lachy: hah |
| 01:47 | Hixie | hopes that wasn't his :-P |
| 01:48 | <Lachy> | no, the two proposals arguing for multiple languages in Content-Language |
| 01:48 | <Hixie> | good good |
| 01:48 | <nessy> | well, there are a few things I disagree with but they are not fundamentally wrong design principles |
| 01:48 | <Lachy> | I haven't read yours in detail yet. Doing that next. So we will see... |
| 01:49 | <nessy> | I was waiting with feedback until the first draft is complete (no sections missing) so I could see the full picture and evaluate feedback then |
| 01:49 | <Hixie> | nessy: how far we should go in terms of being compatible with legacy software and content is something we should decide now |
| 01:49 | <nessy> | no use in giving feedback on things that are still inconsistent because incomplete |
| 01:50 | <nessy> | ok, well my feedback is: as much as possible |
| 01:50 | <Hixie> | ok |
| 01:50 | <Hixie> | then let's start doign the research |
| 01:50 | <Hixie> | we need a list of authoring tools, a list of interpreters, and a list of sample files on the web |
| 01:51 | <nessy> | the alternative is to wait till somebody screams and then fix it |
| 01:51 | <Hixie> | no, the alternative is to not worry about it and to reject feedback saying we should worry about it :-) |
| 01:51 | <nessy> | but yeah - I'll see if I can dig out some stats about authoring tools :) |
| 01:52 | <nessy> | and ignore the outcry of the community? |
| 01:52 | <nessy> | (if it happens) |
| 01:52 | <Hixie> | http://wiki.whatwg.org/wiki/SRT_research |
| 01:52 | <Hixie> | "the community" is busy complaining that we're not using substation alpha |
| 01:53 | <Hixie> | i honestly don't think they'll care that much about whether we natively honour <font color> or not |
| 01:54 | <Hixie> | but if all their software honours it, maybe i'm wrong |
| 01:54 | <Hixie> | so let's find out |
| 01:54 | <nessy> | yeah, at least sw |
| 01:54 | <nessy> | analysing srt files is a lot more difficult |
| 01:55 | <Hixie> | nobody said writing web specs was easy :-) |
| 01:55 | <nessy> | hehe, you said it was once the requirements were together ;) |
| 01:55 | <Hixie> | this is requirements work |
| 01:56 | <Hixie> | we need a video with a coordinate grid and a timer, ideally |
| 01:57 | <nessy> | also, while we're in the process of giving feedback on design decisions - I think the <track> element should not have an empty content model |
| 01:57 | <Hixie> | so that we can record what implementations do as videos to compare |
| 01:57 | <Hixie> | oh? |
| 01:57 | <Hixie> | why? |
| 01:57 | <nessy> | I think that <track> should be open to be used for media resources, too |
| 01:58 | <nessy> | an audio description or a sign language video |
| 01:58 | <nessy> | they are as tightly linked to the main video as the external text tracks |
| 01:58 | <Hixie> | i don't see how that would work with text timed tracks |
| 01:58 | <nessy> | and they are as much "virtual tracks" as the text tracks - compared to actual tracks inside a multiplexed file |
| 01:58 | <Hixie> | it seems like a completely different problem |
| 01:58 | <nessy> | what doesn't work? |
| 01:59 | <Hixie> | you'd want an actual second <video> element to do e.g. sign language video |
| 01:59 | <Hixie> | doing it via <track> seems like a massive level of extra complexiy |
| 01:59 | <Lachy> | Hixie, nice. Your change proposal made note of one of the self-refuting arguments. Namely that allowing multiple language tags has no purpose since it would be defined to be ignored. |
| 01:59 | <Hixie> | i don't really see how you would do it, to be honest |
| 01:59 | <AryehGregor> | Lachy, I can make people exempt from captchas for adding external links under any criteria we like. We could just allow all logged-in users to skip the URL captchas. |
| 01:59 | <Hixie> | Lachy: heh |
| 01:59 | <AryehGregor> | I'll do that right now. |
| 01:59 | <nessy> | you could reference a dependent audio or video resource through track |
| 01:59 | <Lachy> | AryehGregor, that would defeat the purpose |
| 02:00 | <AryehGregor> | Lachy, no, because you still need to do a captcha to create an account. |
| 02:00 | <AryehGregor> | If you can beat that one, you can probably beat the others too. |
| 02:00 | <Lachy> | yeah, but even if a spammer creates an account, they can then use bots to post links using those accounts |
| 02:00 | <Hixie> | nessy: but the processing model would be completely different |
| 02:00 | <Lachy> | I'd rather have some way of adding users to some kind of trusted group |
| 02:01 | <AryehGregor> | Lachy, that can be done too. Or they can automatically be exempt after a certain time period and/or number of edits. |
| 02:01 | <AryehGregor> | Or we can add other measures, like SpamBlacklist to just prohibit a list of domain names from being linked to at all. So if someone spams, add the domain to the list and they can't spam the same site again. |
| 02:01 | <AryehGregor> | Or any combination of the above. |
| 02:02 | <Lachy> | it depends how pro-active we are with removing spam. I haven't checked the spam rate for a while, and I don't know if spammers have been getting deleted |
| 02:02 | <AryehGregor> | Well, tell me what you'd like. |
| 02:03 | <Lachy> | hmm, trying to think of something that isn't too complex... |
| 02:03 | <nessy> | Hixie: something like |
| 02:03 | <nessy> | <video src="video.ogv"> |
| 02:03 | <nessy> | <track src="video_cc.srt" type="text/srt" srclang="en" kind="caption"></track> |
| 02:03 | <nessy> | <track src="video_ad.oga" type="audio/ogg" srclang="en" kind="audiodescription"></track> |
| 02:03 | <nessy> | </video> |
| 02:04 | <nessy> | there wouldn't be cues on that track |
| 02:04 | <nessy> | but otherwise it would be identical to a external text track |
| 02:04 | <AryehGregor> | Lachy, I installed Cite. |
| 02:04 | <Lachy> | cool |
| 02:04 | <nessy> | and it would be temporally dependent on the main video - which is not the case for an independent <video> element |
| 02:05 | <annevk> | seems like overloading the <track> element way too much |
| 02:05 | <annevk> | linking two <video> elements somehow seems saner |
| 02:05 | <Lachy> | what time period would you recommend before whitelisting users? |
| 02:05 | <AryehGregor> | BTW, yes, making people bots will mess things up, like their changes won't appear on Recent Changes by default. |
| 02:05 | <Lachy> | 1 month? |
| 02:05 | <nessy> | annevk: how? |
| 02:06 | <nessy> | annevk: there would need to be a means to describe the dependency between the media resources |
| 02:06 | <AryehGregor> | Well, if we're worried about spammers gaming the system, they could always just leave the accounts alone for whatever the period is. But in practice, spammers usually have inflexible scripts that will create an account, immediately make some edits, and then not bother remembering the login info. At least in my experience. |
| 02:07 | <AryehGregor> | Which is why I think we may as well just disable the check for logged-in users and see how it goes. |
| 02:07 | <nessy> | annevk: also, this just replicates what comes out of a media resource anyway |
| 02:07 | <AryehGregor> | Also, are we using FancyCaptcha or SimpleCaptcha here? |
| 02:07 | AryehGregor | checks |
| 02:07 | <Lachy> | ConfirmEdit |
| 02:07 | <AryehGregor> | SimpleCaptcha, that's trivial for bots to break. |
| 02:07 | <AryehGregor> | Yeah, but it has multiple mode.s |
| 02:07 | <Hixie> | nessy: i'm all for supporting videos for captions, but we need a <video> element to do that, not <track> |
| 02:07 | <AryehGregor> | modes. |
| 02:07 | <AryehGregor> | The default is text-based, IIRC, pretty easy for bots to crack. |
| 02:08 | <nessy> | Hixie: captions? they are text, they are not the problem ... |
| 02:08 | <AryehGregor> | Actually I just had a spammer create ~1500 accounts on my own wiki, circumventing the weak captcha in place. |
| 02:08 | <Lachy> | AryehGregor, can you check if we've had many spam accounts created recently/ |
| 02:08 | <AryehGregor> | We could move to using FancyCaptcha instead. |
| 02:08 | <AryehGregor> | Well, I can't tell if an account is a spam account by looking at it . . . |
| 02:08 | <Lachy> | what advantages does FancyCaptcha have over ConfirmEdit? |
| 02:08 | <nessy> | Hixie: how do you deal with an audio description track inside a media resource then? |
| 02:08 | <AryehGregor> | But all recentish edits look legit. |
| 02:09 | <AryehGregor> | FancyCaptcha is part of ConfirmEdit. Basically, I'd have to generate a bunch of images to use, that's all. |
| 02:09 | <AryehGregor> | http://wiki.whatwg.org/index.php?title=Special:RecentChanges&days=30&limit=500 |
| 02:10 | <Hixie> | nessy: you have a separate <audio> file and you link it to the <video> element using some as-yet-undefined API or markup |
| 02:10 | <AryehGregor> | So spam doesn't actually seem like a big problem right now. |
| 02:10 | <Hixie> | nessy: but you keep it far away from the <track> mechanism (possibly with the exception of letting the UA know that it's a description track for the purposes of UI) |
| 02:10 | <Hixie> | nessy: sign-language captions |
| 02:11 | <Hixie> | nessy: is what i meant by video captions |
| 02:11 | <AryehGregor> | The current captcha is some basic arithmetic written out in ASCII, any specially-designed bot could trivially beat it. FancyCaptcha uses images. |
| 02:11 | <nessy> | Hixie: the problem with separate <audio> or <video> files is that they are resources in their own way |
| 02:12 | <nessy> | Hixie: the thing about audio descriptions or sign language is that they are dependent resources on the main resource |
| 02:12 | <nessy> | also, we would want the same api to apply to the main <video> element no matter whether it refers to a media resource that has these tracks multiplexed inside it or whether they are referenced |
| 02:13 | <Lachy> | I would prefer to not use images for this captcha, if the current text based one seems effective |
| 02:13 | <nessy> | so, we need a similar mechanism to the <track> mechanism |
| 02:13 | <Lachy> | we have at least a couple of blind users in the HTMLWG, and I have no idea how many ever edit the wiki |
| 02:13 | <AryehGregor> | Fair enough. |
| 02:14 | <Lachy> | ok, so let's go with disabling it for logged in users |
| 02:14 | <Hixie> | nessy: the problem with audio descriptions or sign language videos is that they are resources in their own right, that's why they need their own <video>/<audio> |
| 02:14 | <Lachy> | and I don't think we have anonymous edits enabled. |
| 02:14 | <Lachy> | So then the captcha is just a one off sign up |
| 02:14 | <AryehGregor> | No, you don't. Very anti-wiki of you. |
| 02:14 | <AryehGregor> | It's also used for failed logins. |
| 02:14 | <Lachy> | ok |
| 02:14 | <AryehGregor> | If you mistype your password, so as to discourage brute-force attacks. |
| 02:14 | <nessy> | Hixie: an audio description inside a media resource is not a media resource in its own right |
| 02:15 | <Lachy> | fair enough |
| 02:15 | <Hixie> | nessy: from the point of view of the implementation it is |
| 02:15 | <nessy> | Hixie: yes, you can mark it up in its own right - that already works - but that's not the problem I'm referring to |
| 02:15 | <AryehGregor> | Also, by the way, we can whitelist URLs so that they don't trigger captchas. |
| 02:15 | <Hixie> | nessy: playing a video or audio -- whether it's a dependent resource or not -- has a massive amount of baggage -- buffering, seeking, networking, all kinds of crap that <video> currently handles |
| 02:16 | <Hixie> | nessy: not leveraging that to play back multiple videos at once, whether they're supposed to be related videos or not, is not going to fly |
| 02:16 | <Lachy> | We did have anonymous edits enabled initally, but given that we don't have a highly active community like wikipedia does, constantly monitoring it for spam, it's more practical to disallow anonymous edits |
| 02:16 | <nessy> | Hixie: all I am saying is that we need it inside the <video> element, not separate - overloading <track> was just one approach that was discussed before and seemed feasible |
| 02:17 | <nessy> | Hixie: there are additional requirements on a dependent audio or video resource |
| 02:17 | <AryehGregor> | Lachy, on my wiki I use an extension that uses Project Honeypot to deny edits from anonymous users who seem to have spammers' IP addresses. It works pretty well, we get almost no vandalism. |
| 02:18 | <nessy> | Hixie: e.g. anything beyond the timeline of the main resource doesn't exist |
| 02:19 | <Lachy> | doesn't that catch legitimate users out too, if they happen to have the same IP address that a spammer had before them? |
| 02:19 | <Hixie> | nessy: sure, the related <video> or <audio> would be inside the outer <video> |
| 02:19 | <Lachy> | that can happen on ISPs that use DHCP and reassign IP addresses to different people |
| 02:19 | <nessy> | Hixie: maybe it's not a good idea to overload <track> - so my initial point is void - but we need to come up with a workable solution |
| 02:20 | <AryehGregor> | Lachy, well, they're not any worse off than if anonymous edits were totally disabled, now, are they? |
| 02:21 | <Lachy> | that's true :-) |
| 02:21 | <Lachy> | alright, I'm happy to give that a trial |
| 02:22 | <Lachy> | so logged in users will never get accidentally blocked by the IP blacklist? |
| 02:23 | <Hixie> | nessy: i agree we should support it; i don't think agree that it's even remotely close to a high priority the way text timed tracks are |
| 02:24 | <nessy> | Hixie: only if we design something now that stops us from solving this later in a good fashion |
| 02:24 | <AryehGregor> | Lachy, no, this will only hit editing by anons, it won't even hit account registration. |
| 02:24 | AryehGregor | likes how Gmail offers to translate, from Hebrew to English, the message *that he just sent from Gmail* |
| 02:24 | <Hixie> | nessy: i don't think timed tracks would have anything to do with the way to solve the bound media resources problem |
| 02:24 | <nessy> | Hixie: I was concerned that the content model of <track> should be open to allow to add this functionality later through <source> elements inside <track> - that's why I asked |
| 02:25 | <Lachy> | I didn't know you could write Hebrew |
| 02:26 | <AryehGregor> | Anyone with a yeshiva education knows a decent amount of Hebrew. |
| 02:26 | <AryehGregor> | Of course, if that's your only knowledge of Hebrew, you'll sound like someone from 2000 years ago, but hey, it works. |
| 02:26 | <nessy> | Hixie: if we only use <track> for text, then we should indeed consider renaming it |
| 02:27 | <AryehGregor> | It seems like Project Honeypot is currently down, so maybe I'll leave CommentSpammer for another day. |
| 02:27 | <AryehGregor> | You really do get a lot more edits if you allow anonymous editing, and a considerable majority are good. |
| 02:27 | <AryehGregor> | (but it does require some more review, it's true) |
| 02:28 | <Lachy> | have you made the changes to the captcha settings yet? |
| 02:29 | <AryehGregor> | Yeah, I set it so all registered users skip captchas. |
| 02:29 | <Lachy> | ok. |
| 02:31 | <AryehGregor> | (except for failed-login captchas, it seems from the source code that nobody gets to skip those) |
| 02:32 | <Hixie> | nessy: i'm open to better names if there are any |
| 02:34 | AryehGregor | thinks this post is an excellent explanation for the need to support invalid markup: <http://blogs.msdn.com/ie/archive/2010/05/05/html5-and-same-markup-second-ie9-platform-preview-available-for-developers.aspx#10008061>; |
| 02:36 | <Hixie> | ok i made a video so we can test SRT |
| 02:36 | <Hixie> | http://hixie.ch/resources/videos/test-640x360.m4v |
| 02:38 | <Hixie> | some test cases are here: http://www.hixie.ch/tests/adhoc/srt/ |
| 02:39 | <Lachy> | Hixie, can you make an Ogg Theora version too? |
| 02:39 | <Hixie> | iMovie doesn't seem to export to Ogg Theora |
| 02:39 | <Lachy> | ok, I'll convert that one for you |
| 02:42 | <nessy> | Hixie: install XiphQT and iMovie will export to Ogg Theora |
| 02:42 | <nessy> | you could also just upload it to tinyvid.tv ;) |
| 02:42 | <Hixie> | please feel free to do whatever with that video file, it took all of 10 seconds to make :-) |
| 02:43 | <nessy> | could you add a ticking time to that video maybe? |
| 02:44 | <Hixie> | not easily, but if someone else can that'd be great |
| 02:44 | <Hixie> | the 10 second beats was enough of a pain as it is |
| 02:46 | <Lachy> | Hixie, I have this, if you want a count down style video http://lachy.id.au/dev/markup/tests/html5/support/video/pass-countdown.mp4 |
| 02:47 | <Hixie> | nice |
| 02:47 | <nessy> | the count-up could be used from http://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html |
| 02:47 | <Lachy> | I can probably make up something similar if you like |
| 02:47 | <Hixie> | wow that's awesome, takes me back to my 16mm days |
| 02:47 | <Hixie> | it's a truly accurate leader |
| 02:47 | <nessy> | hehe |
| 02:49 | <Hixie> | actually i think that's a 35mm leader |
| 02:49 | <Lachy> | that leader came from the Adobe Premier content. I just inserted it before my green PASS video |
| 02:49 | <Hixie> | but same idea |
| 02:49 | <Hixie> | ah |
| 02:49 | <Hixie> | well the video i made is good enough for my purposes |
| 02:50 | <Hixie> | but if this is as important as is suggested, i'm sure i won't be the only one writing test cases |
| 02:50 | <nessy> | are your squares of a particular size? |
| 02:50 | <Hixie> | and whoever writes other test cases will surely have different needs |
| 02:50 | <Hixie> | nessy: it's http://junkyard.damowmow.com/432 |
| 02:51 | <nessy> | I see |
| 02:51 | <Hixie> | generated from the script you get by clicking download on http://software.hixie.ch/utilities/js/canvas/ |
| 02:51 | <Hixie> | (at least until someone hits upload and overwrites it) |
| 02:56 | <Lachy> | ffmpeg2theora seems to be having some bugs. When I play the converted Ogg Theora file in VLC, it can't seek properly |
| 02:57 | <Lachy> | although, no surprising. My past experience with getting ffmpeg to work on Mac has not been entirely successful. |
| 02:57 | <Lachy> | I will try again tomorrow. Bed time now. |
| 03:01 | <annevk> | nessy, at least the way <track> is designed now it is not some kind of generic container |
| 03:01 | <annevk> | nessy, and from experience with other generic mechanisms it seems better the way it is now |
| 03:01 | <annevk> | nessy, but maybe we ought to call it <texttrack> instead |
| 03:01 | <nessy> | annevk, yup, <track> is coming along nicely |
| 03:02 | <nessy> | the SMIL guys would certainly appreciate it if we called it <textstream> |
| 03:02 | <Hixie> | annevk: <texttrack> would be misleading for audio descriptions, chapters, and metadata tracks |
| 03:02 | <annevk> | (I was trying to answer your question as to why I don't think it should be used for embedding video.) |
| 03:02 | <annevk> | By the way, how is streaming text handled? |
| 03:03 | <othermaciej> | are we expecting that audio descriptions shipped as text would use <track>, but not ones shipped as audio? |
| 03:03 | <annevk> | isn't that all some kind of text? |
| 03:03 | <Hixie> | othermaciej: right |
| 03:04 | <Hixie> | annevk: streaming text tracks aren't supported as designed, though you could easily stream text in (using XHR, EventSource, WebSocket, or whatnot) and manually shove it into the track API which would work equally well |
| 03:05 | <Hixie> | annevk: actually the only thing that prevents streaming text tracks from working right now is the that if they were enabled when the video was started, they'd pause the video until the streaming ended |
| 03:05 | <annevk> | it seems the track API requires some in-out time |
| 03:05 | <Hixie> | annevk: other than that i guess they'd work |
| 03:05 | <Hixie> | per-cue, right |
| 03:05 | <Hixie> | what kind of streaming did you have in mind if that doesn't make sense? |
| 03:05 | <annevk> | when subtitles come in as soon as they are ready |
| 03:06 | <annevk> | e.g. international broadcast of some sports event |
| 03:06 | <Hixie> | sure |
| 03:06 | <Hixie> | why wouldn't that work with the api? |
| 03:06 | <annevk> | I suppose you could do some currentTime trickery |
| 03:06 | <annevk> | but I'm not sure that makes sense |
| 03:07 | <Hixie> | why currentTime? |
| 03:07 | <Hixie> | you know what time it is relative to the broadcast start |
| 03:07 | <Hixie> | just use that |
| 03:07 | <annevk> | then it might not show up at all, if there's a two-second delay |
| 03:07 | <Hixie> | ? |
| 03:08 | <Hixie> | the same people sending the text are sending the video |
| 03:08 | <annevk> | and what would you use as endtime? |
| 03:08 | <Hixie> | they can easily make sure that their text and their video are using the same time |
| 03:08 | <annevk> | I should probably study the API some more first though and in particular when cues are activated and how, etc. |
| 03:08 | <Hixie> | end time would be whenever you think the title has been long enough, maybe 4 seconds or whatever the default delay is |
| 03:09 | <Hixie> | ok i gotta go briefly, but i've written a bunch of test cases and linked to them from the wiki |
| 03:09 | <annevk> | I think the text streaming and video broadcasting could easily end up being separate |
| 03:09 | <annevk> | with text being slightly delayed, but I guess it can be made to work |
| 03:10 | <annevk> | and if not we can always change things then... |
| 03:10 | <Hixie> | nessy: if you think this SRT compatibility is important, now is the time to update http://wiki.whatwg.org/wiki/SRT_research with links to UAs and files, so that it can all be tested |
| 03:10 | <Hixie> | nessy: I'm not convinced that it's important, so if nobody else does the research I'm just going to default back to what I was doing before |
| 03:10 | <nessy> | working on it… also trying to make a video with that time ticker :) |
| 03:10 | <Hixie> | k :-) |
| 03:10 | <Hixie> | update the wiki regularly, so we don't stomp over each other's changes |
| 03:11 | <Hixie> | bbiab |
| 03:13 | <nessy> | not touching the wiki yet |
| 03:13 | <nessy> | also have a day job to actually attend to … in a minute ... |
| 03:18 | <annevk> | "Some of the patterns, like SMIL animations, are inconsistent with other parts of HTML5, like CSS3 animations, and need to be reconciled." -- Microsoft joins the party of calling CSS HTML5 |
| 03:18 | <annevk> | In fact, that sentence seems to imply SMIL is HTML5 |
| 03:19 | <annevk> | SMIL guys would love that :) |
| 03:20 | <nessy> | bah, iMovie just died on me |
| 03:21 | <othermaciej> | annevk: I hope they come to the conclusion soon that canvas is part of HTML5 |
| 03:21 | <annevk> | heh, yeah |
| 03:24 | <nessy> | clear sign that I should work for money now for a bit... |
| 05:00 | <karlcow> | http://www.la-grange.net/2010/05/05/html4-html5 |
| 05:01 | <Hixie> | so does anyone have any lists of SRT implementations we can add to the wiki? |
| 05:01 | <Hixie> | right now the list is a little bare |
| 05:02 | <annevk> | karlcow, I don't get it |
| 05:02 | <annevk> | karlcow, I feel like some kind of more specific context than just HTML5 is missing |
| 05:02 | <karlcow> | It just made me smile when I saw it. |
| 05:03 | <annevk> | oh, it's not your graphic? |
| 05:03 | <karlcow> | a photo |
| 05:03 | <karlcow> | in the streets of tokyo |
| 05:03 | <karlcow> | rainy day |
| 05:03 | <annevk> | aaah |
| 05:04 | <annevk> | my screen is not too good |
| 05:04 | <annevk> | thought it was some kind of graphic |
| 05:04 | <annevk> | also, I'm spying on MikeSmith |
| 05:05 | <karlcow> | it was numbers on a parking lot |
| 05:05 | <karlcow> | hehe |
| 05:06 | <annevk> | Hixie, VLC? |
| 05:06 | <annevk> | Hixie, "Movie Player" on Ubuntu |
| 05:07 | Hixie | tries VLC |
| 05:45 | <annevk> | Hixie, I can prolly do a test run for Movie Player |
| 05:45 | <annevk> | trying to catch up with email still at the moment :/ |
| 05:51 | <Hixie> | cool |
| 05:59 | <annevk> | aah, it does not support this format |
| 05:59 | <annevk> | and the application/x-subrip plugin cannot be found |
| 06:00 | <Hixie> | well that solves that problem |
| 06:01 | <Hixie> | so far I just tested VLC and it's actually even more flexible in its parsing than I expected |
| 06:03 | <annevk> | though when I change the 1 to a 0 I do not get that message but nothing is shown either |
| 06:03 | <nessy> | mplayer does srt |
| 06:03 | <annevk> | nessy, I thought so too, but it does not seem to work? |
| 06:04 | <nessy> | oh!? |
| 06:04 | <nessy> | will get to the wiki later today, Hixie - sorry, but I have a deadline to work against for work now :( |
| 06:06 | <annevk> | it works with a srt file from Castle in the Sky |
| 06:06 | <annevk> | meh |
| 06:06 | <Hixie> | upload the file somewhere? |
| 06:06 | <Hixie> | i wonder what's different about it |
| 06:06 | <Hixie> | given the results I've had with VLC, I'm going to continue editing the spec pretty much as I was before, I think |
| 06:07 | <Hixie> | but if new data comes to light I'll take it into account, naturally |
| 06:09 | <annevk> | I can't see much difference between the files apart from the Castle in the Sky starting from 0 |
| 06:09 | <annevk> | but changing your file to match that doesn't help |
| 06:10 | <annevk> | even copying the first line of that file into your file doesn't work |
| 06:12 | <annevk> | and if I remove everything from that file apart from the first cue it doesn't work either |
| 06:12 | <annevk> | maybe it requires some kind of minimal size to work |
| 06:12 | <annevk> | o_O |
| 06:15 | <Hixie> | CRLF issues maybe? |
| 06:16 | <annevk> | oh, maybe my editor normalizes things |
| 06:16 | <annevk> | hmm |
| 06:18 | <annevk> | no, doesn't seem to be it |
| 06:18 | <Hixie> | maybe the last cue is lost? |
| 06:22 | <annevk> | I think it needs at least 3 cues |
| 06:22 | <annevk> | nothing is lost |
| 06:22 | <annevk> | when I have 3 cues it works, whenever it's less it doesn't work |
| 06:22 | <Hixie> | weird |
| 06:22 | <Hixie> | well most of the important tests have more than 3 cues |
| 06:23 | <annevk> | this is not MPlayer by the way but the Totem Movie Player |
| 06:23 | <annevk> | anyway, gotta go for some time, will check the other files later and update some stuff |
| 06:24 | <annevk> | (Totem Movie Player is what Ubuntu ships by default and calls Movie Player in its Applications menu) |
| 07:30 | <foolip> | what's the X1: Y1: stuff in SRT? |
| 07:33 | <zcorpan> | foolip: pixel-based positioning? |
| 07:34 | <zcorpan> | "Second line is the start and stop time, it can optionally include subtitle coordinates in pixels as a bounding box (X1:left X2:right Y1:top Y2:bottom)." - http://www.visualsubsync.org/help/srt |
| 07:34 | <zcorpan> | "Note that VisualSubsync doesn't support subtitle coordinates." |
| 07:35 | <Hixie> | i don't know of anyone who does |
| 07:36 | <Hixie> | SubRip supposedly outputs it |
| 07:39 | <zcorpan> | Hixie: you should allow a BOM |
| 07:44 | <zcorpan> | Hixie: isn't the cue identifier required in srt impls? |
| 07:44 | <Hixie> | not the only one i tested |
| 07:48 | <zcorpan> | Hixie: it's confusing that ...AsHTML returns a DocumentFragment and not an HTML string |
| 07:49 | <zcorpan> | although maybe that has sailed with xhr responseXML |
| 07:50 | <Hixie> | happy to have better names |
| 07:50 | <zcorpan> | which apis are there that return a document or document fragment? |
| 07:51 | <Hixie> | other than createDocument and createDocumentFragment? |
| 07:51 | <zcorpan> | yeah |
| 07:52 | <Hixie> | don't know of any |
| 07:53 | zcorpan | knows of responseXML |
| 08:01 | <annevk> | Hixie, for 009 you wrote non-chronological titles strangely skipped |
| 08:02 | <Hixie> | ok? |
| 08:02 | <annevk> | hmm I guess it makes sense after all |
| 08:02 | <annevk> | Totem does the same |
| 08:02 | <Hixie> | really? |
| 08:03 | <Hixie> | vlc only skips the 1--- and -2-- but shows --3- and ---4 |
| 08:04 | <annevk> | Totem only shows 4 |
| 08:04 | <annevk> | and the initial ---- |
| 08:08 | <annevk> | with the default font bold doesn't work |
| 08:08 | <annevk> | seems that SRT interop is not too great |
| 08:11 | <zcorpan> | it would be good to be as compatible as possible, so that valid websrt files are playable in most or all srt impls |
| 08:12 | <annevk> | would be nice to migrate away from useless IDs though |
| 08:13 | <foolip> | annevk: how did you get totem working? mine complains that it doesn't have a decoder to application/x-subrip |
| 08:13 | <zcorpan> | annevk: sure, but authors won't be happy if it comes at the cost of not being playable in half the impls |
| 08:14 | <annevk> | foolip, you need an SRT file with at least 3 cues |
| 08:14 | <foolip> | annevk: right, I've had that problem before :) |
| 08:15 | <annevk> | zcorpan, I think that part should be non-normative or maybe just in authoring guidelines as in 10 years it won't be relevant |
| 08:15 | <Hixie> | zcorpan: my plan is to make the syntax allow files that are backwards-compatible, and to make the parser handle files that work reliably today. |
| 08:15 | <Hixie> | zcorpan: beyond that, i am not convinced we need to worry |
| 08:15 | <Hixie> | especially given the results of this research |
| 08:15 | annevk | agrees with that |
| 08:16 | <zcorpan> | annevk: we could update the spec when it's not relevant |
| 08:16 | <zcorpan> | but ok |
| 08:19 | <foolip> | http://senduit.com/057437 <- test-640x360.ogv with extra time stamps |
| 08:20 | <foolip> | Hixie: feel free to copy it to http://www.hixie.ch/tests/adhoc/srt/ |
| 08:23 | <Lachy> | foolip, which software do you use to convert to Ogg Theora? |
| 08:24 | <foolip> | Lachy: gst-lauch :) |
| 08:25 | <foolip> | gst-launch filesrc location=test-640x360.m4v ! decodebin2 ! timeoverlay ! theoraenc quality=24 ! oggmux ! filesink location=test-640x360.ogv |
| 08:25 | <foolip> | odd, subtitles break in MPlayer when using the Theora file but not MPEG-4 |
| 08:26 | <zcorpan> | theora has eated the subtitles |
| 08:27 | <annevk> | foolip, just wondering, you think this WebSRT thing is a good idea too, right? |
| 08:27 | <annevk> | more curious than wondering, I guess :) |
| 08:27 | <annevk> | the wiki is slow |
| 08:28 | <foolip> | annevk: well, I would maybe like inline styling, but not by importing lots of HTML syntax into SRT |
| 08:29 | <annevk> | what kind of styling? |
| 08:29 | <foolip> | stuff to annoy Hixie, like marking a single word red or in an unreadable font |
| 08:30 | <zcorpan> | <font>! |
| 08:30 | <annevk> | you can do it via the ::cue stuff |
| 08:30 | <annevk> | but it wouldn't be portable |
| 08:30 | <annevk> | zcorpan, appears no player supports that so far |
| 08:31 | <zcorpan> | annevk: you tried VisualSubsync? |
| 08:31 | <foolip> | annevk: would that be for all text in that cue, or down to any level? |
| 08:31 | <zcorpan> | http://www.visualsubsync.org/help/srt seems to say <font> is supported |
| 08:31 | <zcorpan> | or at least <font color> |
| 08:31 | <foolip> | haven't looked at the CSS stuff much yet |
| 08:32 | <zcorpan> | or maybe that's just an editor |
| 08:32 | <foolip> | anyway, I think the generl direction is good, something which is mostly backwards compatible with SRT but forces UTF-8 |
| 08:32 | <annevk> | Hixie tried VLC, I tried the media player Ubuntu ships by default |
| 08:32 | <annevk> | seems foolip is trying MPlayer |
| 08:32 | <annevk> | zcorpan, see http://wiki.whatwg.org/wiki/SRT_research |
| 08:33 | <foolip> | annevk: I was going to test my darling (GStreamer, i.e. Totem), but you stole it |
| 08:35 | <annevk> | heh |
| 08:35 | <annevk> | maybe that section should mention GStreamer |
| 08:36 | <zcorpan> | should we introduce <body oncontentloaded> for DOMContentLoaded? |
| 08:37 | <annevk> | if anything it should read ondomcontentloaded prolly |
| 08:37 | <annevk> | but why? |
| 08:38 | <zcorpan> | it's simpler than addEventListener |
| 08:38 | <annevk> | has anyone complained? |
| 08:39 | <zcorpan> | i am now :) |
| 08:39 | <annevk> | browser QA ought to be excluded from such questions :) |
| 08:39 | <zcorpan> | :( |
| 08:40 | <zcorpan> | hey that includes you too |
| 08:43 | hsivonen | mumbles about DOMContentLoaded having upper-case letters |
| 08:43 | zcorpan | notes that <svg onload> listens for 'SVGLoad' |
| 08:44 | <annevk> | zcorpan, I meant answering, not asking :p |
| 08:45 | <zcorpan> | ah |
| 08:45 | <annevk> | would be great for everyone if we just nuked SVGLoad |
| 08:45 | <hsivonen> | zcorpan: does anyone actually fire an "SVGLoad" event? (as opposed to "load") |
| 08:45 | <annevk> | imo |
| 08:45 | <zcorpan> | hsivonen: dunno |
| 08:46 | <annevk> | MPlayer doesn't even support basic formatting? wild |
| 08:47 | <hsivonen> | hmm. In Gecko, that event has different identity compared to the usual load event |
| 08:47 | <zcorpan> | data:text/xml,<svg xmlns='http://www.w3.org/2000/svg'; onload='alert(event.type)'/> |
| 08:47 | <zcorpan> | opera says SVGLoad |
| 08:48 | <hsivonen> | Gecko doesn't alert |
| 08:48 | <zcorpan> | indeed |
| 08:48 | <zcorpan> | it alerts for data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'; onload='alert(1)'>x</svg> |
| 08:49 | <annevk> | o_O |
| 08:49 | <foolip> | mplayer testing done, better than expected |
| 08:49 | <annevk> | that media types are significant in Gecko is silly |
| 08:49 | <annevk> | foolip, yeah, seems really quite sane |
| 08:50 | <zcorpan> | data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><script>document.documentElement.addEventListener('SVGLoad',function(){alert(1)},false)</script></svg>; |
| 08:50 | <zcorpan> | gecko fires SVGLoad |
| 08:50 | <foolip> | so it looks like appending stuff to the timing line isn't that bad |
| 08:50 | <zcorpan> | webkit fires 'load' instead |
| 08:51 | <annevk> | foolip, so MPlayer does not display <1> or <00:00> ? |
| 08:51 | <zcorpan> | annevk: image/svg+xml didn't make a difference in this case |
| 08:51 | <zcorpan> | annevk: the problem was that 'event' wasn't defined in onload='' |
| 08:51 | <annevk> | just evt or something? |
| 08:52 | <annevk> | I remember something weird about that |
| 08:52 | <zcorpan> | hmm, yeah evt is defined |
| 08:52 | <zcorpan> | weird |
| 08:52 | <hsivonen> | interop FTW |
| 08:53 | <zcorpan> | opera also has evt |
| 08:53 | <zcorpan> | and webkit |
| 08:53 | <zcorpan> | does svg define it? |
| 08:53 | <annevk> | I think so |
| 08:53 | <annevk> | strangely incompatible with HTML |
| 08:53 | <foolip> | annevk: nope, it strips <1> and <00:00> |
| 08:53 | <hsivonen> | not really surprising given the history of SVG |
| 08:54 | <foolip> | annevk: but it does keep surrounding whitespace it seems |
| 08:54 | <annevk> | foolip, other than that I guess parsing of <b <i> is somewhat interesting to know |
| 08:54 | <foolip> | annevk: upload test cases :) |
| 08:54 | <annevk> | foolip, that is part of testcase 13 |
| 08:54 | <annevk> | whitespace preservation prolly deserves a separate test |
| 08:57 | <foolip> | annevk: both lines render as "b with lt-i attribute..." |
| 08:58 | <annevk> | interesting |
| 08:58 | <annevk> | that's how we parse HTML too :) |
| 09:03 | <zcorpan> | not <b<i> |
| 09:04 | <annevk> | but there's a space in the source |
| 09:05 | <annevk> | though Totem and VLC handle it differently |
| 09:05 | <annevk> | but then you shouldn't rely on such things anyway |
| 09:10 | <zcorpan> | we didn't have interop in browsers for that case before anyway |
| 09:38 | <jgraham> | What's with all the bugspam? |
| 09:39 | <othermaciej> | apparently the set of components was just changed |
| 09:40 | <Hixie> | there's going to be a lot more bugspam |
| 09:40 | <Hixie> | we disabled the two main accounts |
| 09:41 | <Hixie> | so it should only spam you on bugs you're cc'ed on |
| 09:41 | <othermaciej> | which is apparently quite a lot in my case |
| 09:42 | <Lachy> | wtf? My settings should have been to not CC me on bugs I filed |
| 09:42 | <Hixie> | it's about 1700 in my case, so... :-P |
| 09:42 | <jgraham> | Well on the plus side I don't seem to be CC'd on many bugs |
| 09:42 | <annevk> | dinner time, see you guys tomorrow/later |
| 09:42 | <jgraham> | On the downside I am still dying od spam |
| 09:42 | <annevk> | no spam here btw |
| 09:42 | <jgraham> | *of |
| 09:43 | <Hixie> | later anne |
| 09:43 | <Hixie> | thanks for the srt help |
| 09:43 | <annevk> | aah, it was fun |
| 09:43 | <annevk> | haven't debugged something broken in a while |
| 09:44 | <othermaciej> | I have apparently commented on a lot of bugs |
| 09:45 | <othermaciej> | I seem to be getting 4 copies of each message :-/ |
| 09:47 | <Hixie> | i'm starting to get the feeling that i'm getting timeout errors but that the backend is still actually doing it |
| 09:48 | <Hixie> | so that my sending the request again with the next "batch" of bugs is just causing there to be two processes at once |
| 09:49 | <othermaciej> | I think that happened to me before |
| 09:49 | <othermaciej> | the time I spammed public-html with hundreds of bugmails |
| 10:25 | <zcorpan> | could we change this? http://www.w3.org/mid/3b09f922ce41a5a55a71ebe12592b5da441fa1dd@localhost |
| 10:27 | <annevk> | everything can be changed |
| 10:27 | <annevk> | though people might complain |
| 10:30 | <othermaciej> | is redispatching an event a good thing? |
| 10:41 | <zcorpan> | othermaciej: I think it seems like a neat thing to be able to do, for making table rows or <canvas> clickable |
| 10:41 | <othermaciej> | you can always clone the event |
| 10:41 | <zcorpan> | is there a cloneEvent? |
| 10:41 | <othermaciej> | re-dispatching it is weird, since the even tracks its target, so you mess up the rest of the dispatch |
| 10:41 | <othermaciej> | I meant by hand |
| 10:42 | <zcorpan> | yeah |
| 10:42 | <zcorpan> | webkit allows redispatching though |
| 10:43 | <othermaciej> | probably not on purpose |
| 10:43 | <zcorpan> | maybe what i want is a cloneEvent |
| 10:55 | <Hixie> | ok there's been a component reorg for the specs i work on |
| 10:55 | <Hixie> | everything should be working again |
| 10:55 | <Hixie> | the reviewer tool tries to guess the right component |
| 10:55 | <Hixie> | and now actually uses complete.html in the URL it logs in the bug if it thinkgs the HTML5 spec itself doesn't contain that section |
| 10:59 | <hsivonen> | would be nice to turn off bugmail when doing a reorg |
| 10:59 | <Hixie> | we did |
| 10:59 | <Hixie> | for the two main accounts, anyway |
| 11:00 | <Hixie> | not much we can do for individual accounts as i understand it |
| 11:00 | <hsivonen> | I see |
| 11:01 | hsivonen | still has 103 bugs to evaluate for HTML5-fixedness in the b.m.o HTML: Parser component |
| 11:09 | <Rik`> | is there a reason to have a kind attribute on <track> instead of a type attribute (as in <input>) |
| 11:10 | <annevk> | I think the idea was that type on <track> would mean media type, but maybe that plan sailed |
| 11:17 | <annevk> | I saw some complaints about it too |
| 11:17 | <annevk> | but type= is heavily overloaded already, would that really be better? |
| 11:18 | <Rik`> | it's similar in behaviour to input and button in my mind |
| 11:18 | <annevk> | yeah, but not similar to <object>, <link>, <style>, <script>, etc. |
| 11:18 | <MikeSmithX> | hsivonen: I couldn't figure out any way to easily turn off bugmail for all users temporarily |
| 11:19 | <MikeSmithX> | but hopefully this is a one-time thing |
| 12:39 | <variable> | any comments on section variable 1.1 of variable http://wiki.whatwg.org/wiki/Rationale |
| 12:39 | <variable> | * of http://wiki.whatwg.org/wiki/Rationale |
| 12:51 | <hsivonen> | whoa. I just came across a bug report where Hixie-hosted test cases were gone |
| 12:52 | <hsivonen> | usually Hixie's test cases stay in place for years and years |
| 12:52 | <hsivonen> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=475606 |
| 13:35 | <jgraham> | zcorpan: I assume it was not the number of bits being objected to |
| 14:00 | zcorpan | wonders if anne's blog posts have moved to concatenating his last N tweets |
| 14:04 | <jgraham> | zcorpan: I assumed he was reading too much Dive into Mark |
| 14:45 | <annevk> | just wanted to try something new |
| 14:45 | <annevk> | I kind of like writing |
| 14:45 | <annevk> | and spec writing doesn't give a lot of freedom :) |
| 14:47 | <annevk> | assuming you're referring to Map and Endlessly, because everything else is just business as usual |
| 14:52 | <annevk> | feedback appreciated, btw |
| 15:05 | <jgraham> | Do videos stop playing if you remove them from the tree?</lazyirc> |
| 15:09 | <zcorpan> | jgraham: "When a media element is removed from a Document, if the media element's networkState attribute has a value other than NETWORK_EMPTY then the user agent must act as if the pause() method had been invoked." |
| 15:09 | <jgraham> | so you can unpause it? |
| 15:09 | <zcorpan> | yeah |
| 15:10 | <jgraham> | And it will keep playing sound? |
| 15:10 | <zcorpan> | yes |
| 15:10 | <jgraham> | So you have to be careful not to GC it |
| 15:10 | <zcorpan> | yes |
| 15:10 | <jgraham> | Nice |
| 15:10 | <annevk> | and drawImage() should presumably also still work |
| 15:11 | <zcorpan> | i think this is an area that needs more testing |
| 15:11 | <jgraham> | Yeah :) |
| 15:17 | <foolip> | I'm pretty sure it'll work in Opera, I was very careful not to GC it |
| 15:18 | <zcorpan> | foolip: does drawImage() work? |
| 15:19 | <foolip> | I would strongly suspect so, since we've made no optimizations whatsoever based on visibility, etc |
| 15:19 | <jgraham> | foolip: Even with 0 remaining references to the video except the event handlers? |
| 15:20 | <foolip> | jgraham: you can only draw it if you have a reference |
| 15:21 | <jgraham> | foolip: I can get a reference from withing an event handler attached to the video, no? |
| 15:21 | <jgraham> | *within |
| 15:21 | <foolip> | jgraham: the event handler itself is a reference |
| 15:21 | <foolip> | in some way |
| 15:22 | <jgraham> | foolip: OK. It's not obvious that is true :) |
| 15:22 | <jgraham> | (we seem to have at least one bug related to this kind of thing) |
| 15:23 | <foolip> | yes, it's quite edge-casey isn't it |
| 15:23 | <zcorpan> | source.onerror = function(e) { setTimeout(function() { ctx.drawImage(e.target.parentNode) }, 1000) }; source = null; video = null; |
| 15:24 | <jgraham> | Indeed. If you made it work correctly for video I'm quite impressed :) |
| 15:24 | <zcorpan> | consider that to be a video with two <source>s where the first one fails but the second one loads |
| 15:24 | <zcorpan> | does that work? |
| 15:25 | <foolip> | zcorpan: I haven't tried, but I strongly suspect it works |
| 15:26 | <foolip> | mainly because I once tried very hard for event handlers to *not* be a reference, but couldn't find a way, including setting the variables to null |
| 15:26 | <zcorpan> | foolip: in my case the <video> itself has no event handlers |
| 15:26 | <foolip> | oh right |
| 15:27 | <foolip> | I don't know if parentNode counts as a reference |
| 15:27 | <foolip> | guess you don't need video to test that though |
| 15:28 | <zcorpan> | i think parentNode counts as a reference, but would be nice to have a test that does the above anyway |
| 15:28 | <foolip> | zcorpan: please write it next time you're assigned to to <video> QA :) |
| 15:29 | <annevk> | nn |
| 15:30 | <foolip> | p |
| 16:22 | <variable> | http://pastebin.com/FK246fPT -- anything I could say to expand upon this announcement (for the whatwg blog) |
| 16:22 | <variable> | and any comments on section 1.1 http://wiki.whatwg.org/wiki/index.php?title=Rationale |
| 17:23 | <theMadness> | Is there a nice implementation of ruby with fallbacks for other browsers around? |
| 17:27 | <theMadness> | Also, if I have both kana an romaji annotations, what is the traditional way to arrange them (what goes on top, what on bottom) |
| 17:58 | <TabAtkins> | Urgh, suddenly Gmail's giving me a tiny white flash whenever I load up a new message. Very annoying when the page is mostly black in a dark room. |
| 18:35 | <KaOSoFt> | Hello. |
| 19:52 | <variable> | any comments on http://wiki.whatwg.org/wiki/Rationale section 1.1 ? |
| 20:21 | <AryehGregor> | Well, I have comments, but you're not here anymore, so too bad. |
| 21:35 | <jgraham> | I see Tim Bray still doesn't like us |
| 21:45 | <TabAtkins> | jgraham: Link? |
| 21:47 | <jgraham> | http://www.tbray.org/ongoing/When/201x/2010/05/05/HTML5-and-the-Web |
| 21:48 | <TabAtkins> | What's the egregrious grammar botch in "Perceptions of the web are changing."? |
| 21:49 | <hober> | it was "is changing" |
| 21:49 | <TabAtkins> | Ah, k. Easy conjugation mistake to make. |
| 21:50 | <hober> | http://twitter.com/BenWard/status/13468989267 |
| 21:57 | <othermaciej> | what ocean is HTML5 trying to boil? |
| 21:58 | <jgraham> | No idea. |
| 21:58 | <jgraham> | Parsing maybe? |
| 22:02 | <jgraham> | It would fit with his earlier article suggesting there is something magical in the transition between undefined parsing and defined parsing that means we are suddenly trying to create a "Networked-Object-Model" |
| 22:03 | <jgraham> | (or something, I think we concluded at the time that that bit of the earlier article made no sense) |
| 22:04 | <othermaciej> | I'm not sure what the bottom line of his new article is |
| 22:04 | <othermaciej> | interesting ideas, I'm not sure I can fully agree with a native app being a Web app |
| 22:04 | <othermaciej> | I think to be considered a Web app, you have to not just use URIs but be URI addressable |
| 22:05 | <hober> | which was ben's point |
| 22:05 | <jgraham> | Indeed. |
| 22:07 | <jgraham> | I suppose the cynical interpretation is "I'm supposed to be promoting android now so I have to say that native apps are good and not anti-web". But I have no real reason to believe that the cynical reason is the corect one |
| 22:07 | <othermaciej> | Ben's point was stronger - not only does your app need to be URI-addressable, but at least some places inside it should be URI-addressable |
| 22:07 | <othermaciej> | which would exclude most Flash on the Web |
| 22:08 | <workmad3> | a web app should be in the web, not merely on the web? |
| 22:08 | <othermaciej> | that was Ben Ward's argument |
| 22:08 | <workmad3> | it's also the classic argument for RDF :) |
| 22:08 | <othermaciej> | Tim's position seems to be that a web app doesn't even have to be on the Web, it just needs to link to the web |
| 22:09 | <jgraham> | Arguably he is allow allowing for the possibility of creating or modifying resources |
| 22:10 | <jgraham> | But yeah, I wouldn't consider something that can read or modify the web to necessarily be a part of the web |
| 22:10 | <othermaciej> | "A large proportion of the native applications on iPhone, and on Android, and on Windows, and on Mac, and on Linux, are Web applications. They depend in a fundamental way on being able to recognize and make intelligent use of hyperlinks and traverse the great big wonderful Web." |
| 22:10 | <roc> | I think Tim's reasoning would make a Web browser a Web app |
| 22:10 | <othermaciej> | a web browser certainly does a lot of that stuff |
| 22:10 | <TabAtkins> | There's no "thinking" about it. His argument is 100% a webapp by his argument. |
| 22:11 | <TabAtkins> | err... |
| 22:11 | <TabAtkins> | s/His argument is/Browsers are/ |
| 22:11 | <jgraham> | TabAtkins: Too much recusion |
| 22:11 | <jgraham> | *recursion |
| 22:11 | <TabAtkins> | Out of stack space? |
| 22:11 | <roc> | which means he is clearly using "Web app" in a different way to most people |
| 22:11 | <jgraham> | TabAtkins: Nah, I have tail call optimisation |
| 22:12 | <TabAtkins> | I don't think tc0 helps you when you omit your base case. |
| 22:18 | <dglazkov> | if you put "Web" in front of it, it's a Web app. Duh. |
| 22:18 | <dglazkov> | Web Toaster |
| 22:18 | <dglazkov> | bam |
| 22:18 | <TabAtkins> | Hey, if it can toast arbitrary uris, it's a web app. |
| 22:19 | <dglazkov> | despite having a "What's the point" section, the blog post is still a bit hard to ... find a point in. |
| 22:23 | <othermaciej> | mmm, caption formats |
| 22:58 | <othermaciej> | annevk: use case for GuestXHR: http://www.cnet.com/8301-31361_1-20004265-254.html?tag=newsLeadStoriesArea.1 |
| 22:59 | <othermaciej> | TabAtkins: were you planning to write counter-proposals for issues 89 or 92? You commented on 92 but I don't recall anything on 89 |
| 23:01 | <theoros> | does <nav> require a <h1-6>? |
| 23:01 | <theoros> | http://gsnedders.html5.org/outliner/ suggests yes |
| 23:01 | <jgraham> | theoros: No. But if it has one then it will be used as the title of that section |
| 23:02 | <jgraham> | A sensible UA would infer a title like, say, "Navigation" in the absence of an explicit title |
| 23:02 | <theoros> | but erring on the side of ~Nice Semantics~, it would be "good" to include a heading (and then perhaps hide it with css)? |
| 23:03 | <Philip`> | Has anyone looked into how well TTML is supported in e.g. Flash? |
| 23:03 | Philip` | is thinking of the iPlayer one where it doesn't even render the different speaker colours specified in the TTML files |
| 23:05 | <Philip`> | (but I don't know if that's using native Flash support) |
| 23:12 | <jgraham> | theoros: Sure |