| 01:35 | <faffers> | Do any mobile browser implementations support playback of cached audio? |
| 01:35 | <faffers> | (offline) |
| 01:35 | <faffers> | or on |
| 01:35 | <faffers> | actually |
| 01:35 | <faffers> | just cached |
| 01:43 | <MikeSmith> | faffers: Opera Mobile does |
| 01:43 | <MikeSmith> | or I should say, I think it does |
| 01:45 | <MikeSmith> | you'd have to ask somebody from Opera to confirm |
| 01:45 | <faffers> | sure |
| 01:45 | <faffers> | I'm trying on mobile safari atm |
| 01:46 | <faffers> | bit of a bastard, it's not interested in cached mp3s, whether they're the original file or I convert them to data uris |
| 01:46 | <MikeSmith> | as far as other Webkit-based browser engines, I think that's handled in the platform code, so it'd depend on which port/OS/platform version of Webkit (e.g., Qt, GTK+, whatever) |
| 01:46 | <faffers> | sure |
| 02:04 | <jacobolus> | is there someplace to report typos in the SVG spec? |
| 02:04 | <jacobolus> | oh, there's a w3 bugzilla. that'll work |
| 02:11 | <MikeSmith> | jacobolus: yeah, bugzilla is probably the best place |
| 02:11 | <MikeSmith> | so I'm just discovering ejacs - http://code.google.com/p/ejacs/ |
| 02:12 | <MikeSmith> | "an Ecma-262 compliant JavaScript interpreter written entirely in Emacs Lisp" |
| 02:12 | <MikeSmith> | I wonder how well it actually works |
| 02:13 | MikeSmith | wonders if Steve Yegge is on twitter |
| 03:29 | <roc> | faffers: Fennec supports <audio> + the HTML5 offline cache |
| 03:30 | <roc> | faffers: also data: urls in <audio> |
| 06:46 | <faffers> | Have Apple disabled the ability to use uri data for HTML5 audio on iOS or is it just not done yet? |
| 06:58 | <zcorpan_> | TabAtkins: hey we're born the same month! which day? |
| 09:23 | <jgraham> | Anyone have any idea if the "reset the form owner" algorithm has been compatibility tested? |
| 09:23 | <jgraham> | Specifically the case where you have a form-associated element that is not a child of its form |
| 09:24 | <jgraham> | I think we have at least one bug on file that would regress if we implemented that behaviour |
| 09:26 | <volkmar> | jgraham: which is? |
| 09:27 | <jgraham> | volkmar: Which what? |
| 09:28 | <volkmar> | jgraham: what bug? |
| 09:28 | <jgraham> | Oh, bbc.co.uk relied on retaining the form element pointer after reparenting |
| 09:29 | <volkmar> | jgraham: gecko is implementing that in nightlies and everything seems fine |
| 09:29 | <jgraham> | I think we also got OTW on them |
| 09:29 | <jgraham> | But it's at least unclear that other sites won't break in the same way |
| 09:29 | <volkmar> | jgraham: but they don't use @form? |
| 09:30 | <jgraham> | No, they had markup like <table><form><td><input> |
| 09:30 | <volkmar> | jgraham: that should still work afaik |
| 09:30 | <hsivonen> | jgraham: so they didn't re-re-parent using a script? |
| 09:30 | <jgraham> | Then they removed and reinserted the table into the document |
| 09:30 | <jgraham> | Using a script |
| 09:30 | <hsivonen> | jgraham: and did that work in Gecko? |
| 09:31 | <jgraham> | hsivonen: I assume it did at the time |
| 09:31 | <hsivonen> | I'm surprised |
| 09:31 | <jgraham> | This was 1.5 years ago |
| 09:32 | <jgraham> | It is possible that the old gecko parser did something different in this case? |
| 09:32 | <gsnedders> | jgraham: Are we sure we got the same markup as Gecko? |
| 09:32 | gsnedders | has some vague memory that we got different markup causing that bug |
| 09:33 | <jgraham> | gsnedders: No |
| 09:33 | <jgraham> | I'm not *sure* about anything |
| 09:34 | <jgraham> | Anyway, if gecko implements what is in the spec and doesn't see significant breakage that is fine |
| 09:34 | <hsivonen> | jgraham: I *think* the old parser had a subtle difference from the new parser in some form behavior |
| 09:36 | <hsivonen> | probably discoverable by searching my bugzilla comments from 2009 on bugs numbered < 400000 |
| 09:36 | <hsivonen> | and not having [fixed by the html5 parser] in the whiteboard |
| 09:36 | <hsivonen> | and having status FIXED |
| 09:41 | <jgraham> | hsivonen: If the algorithm per spec is working for you, I think that is probably good enough. The comment I got from our developer was something like "I actually quite like the algorithm there, it seems fairly sane. But in HTML that isn't always a good sign" |
| 09:41 | <hsivonen> | jgraham: no site breakage bugs arising from this have reached me |
| 09:42 | <hsivonen> | the only bug I've seen about this area was filed by volkmar based on logic instead of site compat ;-) |
| 09:46 | <volkmar> | hsivonen: you mean the <form><form><input> bug? |
| 09:46 | <hsivonen> | volkmar: yes |
| 09:47 | <volkmar> | i still don't understand why the first form is used during parsing considering the second will be set as the form owner after, iirc |
| 09:52 | <hsivonen> | volkmar: there is no second form element |
| 09:52 | <hsivonen> | volkmar: the second tag is thrown away |
| 09:52 | <hsivonen> | due to compat reasons |
| 09:54 | <volkmar> | hsivonen: the parser is full of black magic :) |
| 09:54 | <hsivonen> | volkmar: not as magic as the old one, though :-) |
| 09:56 | <volkmar> | hsivonen: you mean Gandalf the White is not as magic as Gandalf the Grey? ;) |
| 09:57 | <hsivonen> | volkmar: this time it's actually possible to read the spec or source to see how stuff happens |
| 10:00 | <annevk> | hehe -- http://twitter.com/joedrew/status/24973615911 |
| 10:10 | <MikeSmith> | Peter-: has there been some announcement from Mozilla about shipping FF4 with the initial Gecko API? |
| 10:11 | <MikeSmith> | and if so, they're essentially including it as still-experimental, right? |
| 10:12 | <Peter`> | It's prefixed, yes |
| 10:12 | <MikeSmith> | OK |
| 10:12 | <Peter`> | it's being announced as a feature here: http://www.mozilla.com/en-US/firefox/beta/features/ |
| 10:13 | <MikeSmith> | is that any different from Chrome releasing beta that include their own still-experimental audio API? |
| 10:13 | MikeSmith | reads feature page |
| 10:13 | <Peter`> | Chrome's API is the one from the incubator group |
| 10:13 | <Peter`> | it doesn't ship yet, though, isn't even close to being enabled in WebKit |
| 10:14 | <MikeSmith> | there's been no decision in the incubator group about that spec |
| 10:14 | <MikeSmith> | in fact, we really need to convert that incubator group into a real WG |
| 10:14 | <Peter`> | The spec, as it is right now, is way too complicated |
| 10:14 | <MikeSmith> | because the incubator group can't publish andy spec anyway |
| 10:14 | <Peter`> | I agree that it's nowhere close to being finished, but Chris Rogers realizes that himself as well |
| 10:14 | <Peter`> | (the editor) |
| 10:15 | <Peter`> | Shipping an alternative API with Firefox 4 isn't going to make things better, prefixed or not |
| 10:15 | <Peter`> | when enabled by default, that is, before a consensus has been reached |
| 10:16 | <annevk> | do you think it will get lots of adoption soon then? |
| 10:16 | <MikeSmith> | Peter-: looking at http://www.mozilla.com/en-US/firefox/beta/features/ I do notice nothing indicating it's experimental or not fully baked -- so yeah, I agree that is not good. Developers should not be led to assume that is stable enough for them to implement production apps around |
| 10:17 | <Peter`> | annevk, even though it's proprietary, it's working. People will start experimenting and might expect it to show up in other browsers |
| 10:17 | <MikeSmith> | it otherwise might be interpreted as Mozilla trying to preemptively put some facts on the ground so that they won't have to change the API later |
| 10:18 | <Peter`> | I concur |
| 10:18 | <MikeSmith> | boaz: ↑ |
| 10:19 | <jgraham> | MikeSmith: It's not clear to mw why this is a big problem for anyone other than the Mozilla people |
| 10:20 | <jgraham> | In that they might have some pressure to keep supporting their audio API in the future when some standard exists |
| 10:20 | <annevk> | really? |
| 10:20 | <annevk> | it's prefixed |
| 10:20 | <MikeSmith> | jgraham: you don't think it's a problem to be aware that a particular API is not stable? |
| 10:20 | <annevk> | prefixed is great |
| 10:20 | <jgraham> | MikeSmith: Prefixed === unstable |
| 10:20 | <Peter`> | It's not being advertised as such |
| 10:20 | <annevk> | you want people to do some amount of experimentation otherwise you never get a feel of what is wrong |
| 10:21 | <Peter`> | "Firefox is changing the way media is integrated on the web" sounds like something which is here to stay, prefixed or not |
| 10:21 | <jgraham> | It is no different to people shipping prefixed CSS or whatever |
| 10:21 | <jgraham> | It seems to me that, fundamentally, they are doing the right thing |
| 10:22 | <jgraham> | Possibly their PR people have gone overboard |
| 10:22 | <jgraham> | But seriously, who expects a mozFoo API to be the last word in Foo APIS? |
| 10:22 | <abarth> | i've been going through the WebKit bug database. It's crazy how many bugs are fixed by the HTML5 parser |
| 10:23 | <jgraham> | It is clear that it can be replaced with some other API in the future and you can get the right one via feature detection |
| 10:26 | <hsivonen> | it could be, though, that -ms- and -webkit- are setting wrong expectations about future support for -moz- and -o- features |
| 10:26 | <Peter`> | jgraham, I agree that the PR part around it makes it seem worse than it is. Still I think it'd be best to keep it disabled by default, so that people who want to use it can experiment with it, while also waiting for the Incubator Group to reach a consensus. If Chrome is going to do the same there'll be two implementations of an "Audio API" which aren't similar at all |
| 10:28 | <hsivonen> | if you disable something by default, you can't really demo it as easily |
| 10:30 | <hsivonen> | (Apple and Google are demoing -webkit-* stuff as "HTML5" all the time, and Firefox looks bad, because the newest demos don't run) |
| 10:33 | <hsivonen> | how many people actually read http://slides.html5rocks.com/disclaimer.html ? |
| 11:57 | <Rik`> | Peter`: then WebKit should not activate css gradients by default |
| 11:57 | <Rik`> | or CSS reflections |
| 12:01 | <Rik`> | Peter`: and https://developer.mozilla.org/en/Manipulating_audio_using_the_enhanced_audio_API |
| 12:01 | <Rik`> | there is a big "non standard" on top of the doc |
| 12:01 | <Rik`> | the chart will point to this page |
| 12:03 | <Rik`> | hi MikeSmith or MikeSmith_ |
| 12:03 | <MikeSmith_> | Rik`: hej |
| 12:03 | <Rik`> | as I said before the chart will link to https://developer.mozilla.org/en/Manipulating_audio_using_the_enhanced_audio_API |
| 12:03 | <Rik`> | which clearly claims this is non standard |
| 12:04 | <MikeSmith_> | I see |
| 12:04 | MikeSmith_ | reads page |
| 12:09 | <annevk> | pretty cool |
| 12:10 | <MikeSmith> | yeah |
| 12:11 | <MikeSmith> | I think once people get their hands on this stuff, we are going to see all kinds of cool stuff |
| 12:12 | <MikeSmith> | just hope there won't be too much pain involved for everybody in migrating to whatever the standard API ends up being |
| 12:14 | <jgraham> | The Chrome thing looks scary-complex |
| 12:23 | <hsivonen> | someone should do an objective analysis of the level of complexity of proposals coming from each browser vendor |
| 12:24 | <hsivonen> | (I mean more generally--not just for audio) |
| 12:24 | <hsivonen> | (Yes, I know you can't really objectively quantify spec proposal complexity) |
| 12:26 | <jcranmer> | 75.0896 |
| 12:26 | <jcranmer> | hsivonen: count the number of external/internal section dependencies it adds |
| 12:27 | <hsivonen> | isn't http://www.w3.org/Bugs/Public/show_bug.cgi?id=10657 violating ARIA design principles? |
| 12:30 | <Ms2ger> | Doesn't matter, it was filed by an expert |
| 12:31 | <annevk> | hsivonen, though so too |
| 12:32 | <annevk> | hsivonen, but maybe the principles have changed |
| 12:32 | <hsivonen> | annevk: I commented. |
| 12:32 | <annevk> | hsivonen, there's also this weird notion in the WAI-ARIA spec that AT may change the markup and that web authors have to ensure they check mutation events |
| 12:32 | <hsivonen> | annevk: I expect the principles haven't changed. But if they had, it would be a pretty bad bait and switch. |
| 12:33 | <hsivonen> | annevk: yeah, that's truly bizarre |
| 12:33 | <annevk> | hsivonen, I objected to that (too late for the deadline) but maybe I should again now that there's another Last Call without someone responding to my comments |
| 12:33 | <annevk> | that the W3C rechartered it as a Member-only group is also truly bizarre |
| 12:34 | <annevk> | T.V. Raman has complained quite loudly about that |
| 12:34 | <annevk> | and he's in the TAG -- quite the expert |
| 12:34 | <hsivonen> | annevk: I hope Opera sent charter review comments requesting the group to be public |
| 12:34 | <annevk> | I haven't checked to be honest |
| 12:34 | <hsivonen> | annevk: I also hope Raman sent in charter review comments to that effect |
| 12:35 | <annevk> | I should really kill this "to be honest" habit, it makes no sense |
| 12:35 | <jcranmer> | to be honest, I disagree with you |
| 12:36 | <Dashiva> | To be honest, I'm not |
| 12:36 | <annevk> | heh |
| 12:37 | <annevk> | AryehGregor, textArea should just work actually; SVG is matched case-sensitively |
| 12:38 | <hsivonen> | annevk: SVG textArea should not be implemented |
| 12:40 | <annevk> | ah yeah, forgot about that |
| 12:45 | <annevk> | ooh |
| 12:45 | <annevk> | @volantis.com |
| 12:45 | <annevk> | I thought I recognized that |
| 12:45 | <MikeSmith> | ? |
| 12:45 | <MikeSmith> | what about volantis? |
| 12:45 | <annevk> | Dave Raggett worked for them iirc |
| 12:46 | <annevk> | the convert this XHTML2 markup to device-specific-markup people |
| 12:46 | <MikeSmith> | I can't remember if Dave did or not, but Rhys Lewis did |
| 12:46 | <MikeSmith> | Rhys is now at Qualcomm |
| 12:46 | <hsivonen> | annevk: ah. that's what I suspected, but their product page is broken, so I couldn't check |
| 12:47 | <MikeSmith> | Rhys was a major force behind the Device Independence Activity stuff |
| 12:47 | <annevk> | Paul Duffin's latest email makes this perfectly clear |
| 12:47 | <MikeSmith> | which eventually morphed into the Ubiquitous Web Applications work |
| 12:48 | <hsivonen> | and Opera Mini and WebKit ate their lunch |
| 12:49 | <MikeSmith> | I'm trying to remember the name of that proposed vocab |
| 12:51 | <MikeSmith> | DIAL |
| 12:51 | <MikeSmith> | it was called |
| 12:52 | <MikeSmith> | wow |
| 12:52 | <MikeSmith> | http://www.w3.org/TR/dial/ |
| 12:52 | <MikeSmith> | they are still working on that, it seems |
| 12:52 | <MikeSmith> | oh |
| 12:52 | <MikeSmith> | "This document has been discontinued as part of the closure the Ubiquitous Web Applications Working Group." |
| 12:53 | <hsivonen> | I hadn't noticed the group had been closed. what happened? |
| 12:54 | <annevk> | Opera Mini ;p |
| 12:55 | <MikeSmith> | hsivonen: er, I guess I should know the answer to that question… but to be honest, I don't |
| 12:55 | <MikeSmith> | maybe no longer enough member interest |
| 12:55 | <MikeSmith> | Rhy was for quite a long time the major force in sorta singlehandedly keeping some of that work going |
| 12:56 | <MikeSmith> | architect of sorts |
| 12:56 | <MikeSmith> | behind a lot of it |
| 12:56 | <annevk> | geolocation is in a different activity? whoa |
| 12:56 | <MikeSmith> | and when Rhys moved on, not sure anybody else was prepared to step in and pick up the work |
| 12:56 | <hsivonen> | MikeSmith: I see |
| 12:58 | <MikeSmith> | annevk: W3C activity classifications are somewhat artificial constructs that don't necessarily affect much |
| 12:58 | <MikeSmith> | given that patent policy is all per-spec |
| 12:58 | <MikeSmith> | or per-WG |
| 12:58 | <annevk> | yeah, could just move to a flat structure |
| 12:59 | <MikeSmith> | yeah, there are a lot people who think that might work better |
| 13:55 | <boaz> | MikeSmith: woah. |
| 13:57 | <boaz> | Hm, I agree, that "feature" is misleading given that the API is likely to change. |
| 13:58 | <MikeSmith> | boaz: Rik` has pointed out that the page which actually provides the details about the API makes it more clear |
| 13:58 | <boaz> | that's good |
| 13:58 | <boaz> | Also, this is a case where the API was implemented long before an incubator group was even formed... |
| 13:59 | <boaz> | like six months before. |
| 13:59 | <boaz> | Due to my limited experience, I'm not sure how often that happens. |
| 13:59 | <boaz> | And in either case, It doesn't really matter. We should be telling developers that the API will totally change. |
| 13:59 | <boaz> | ... or at least that it might. |
| 14:32 | <mokush> | hey, is there a <controls> element defined anywhere? |
| 14:33 | <annevk> | nope |
| 14:34 | <zcorpan_> | my google-fu gives http://msdn.microsoft.com/en-us/library/ms164640.aspx |
| 14:35 | <mokush> | yeah, but this results in some other html being generated by asp, right? |
| 14:35 | <mokush> | not the actual <controls> markup |
| 14:35 | <zcorpan_> | no idea what it does, but it's not html |
| 14:36 | <mokush> | but the validator validates <controls> |
| 14:36 | <mokush> | as well as <bar> and <extended> |
| 14:37 | <zcorpan_> | which validator? |
| 14:38 | <mokush> | validator.w3 as well as html5.validator.nu |
| 14:38 | <mokush> | as html5 |
| 14:38 | <zcorpan_> | doesn't for me |
| 14:39 | <karlushi> | mokush, is there a page online which validates with these elements |
| 14:39 | <karlushi> | with a public URI? |
| 14:40 | <miketaylr> | http://html5.validator.nu/?doc=http%3A%2F%2Fjsbin.com%2Fepevi3%2F |
| 14:40 | <zcorpan_> | Error: Element controls not allowed as child of element body in this context. (Suppressing further errors from this subtree.) |
| 14:41 | <mokush> | http://pastebin.com/raw.php?i=FrqRLwCx try this code |
| 14:41 | <mokush> | .nu spits the error about controls, but w3 doesn't say anything about these |
| 14:42 | <zcorpan_> | i get " Line 27, Column 13: Element controls not allowed as child of element div in this context. (Suppressing further errors from this subtree.)" in validator.w3.org |
| 14:42 | <karlushi> | mokush, http://validator.w3.org/ says Errors found while checking this document as HTML5! |
| 14:42 | <karlushi> | Result: 4 Errors, 2 warning(s) |
| 14:43 | <karlushi> | Line 27, Column 13: Element controls not allowed as child of element div in this context. (Suppressing further errors from this subtree.) |
| 14:43 | <karlushi> | <controls> |
| 14:44 | karlushi | has the feeling that mokush is trying to validate this http://validator.w3.org/check?uri=http%3A%2F%2Fpastebin.com%2Fraw.php%3Fi%3DFrqRLwCx+&charset=%28detect+automatically%29&doctype=Inline&group=0 more than the markup itself |
| 14:45 | <mokush> | I missed a line, my bad. " (Suppressing further errors from this subtree.)" |
| 14:45 | <karlushi> | mokush, view source http://pastebin.com/raw.php?i=FrqRLwCx |
| 14:46 | <mokush> | I don't get what you're trying to say by 'more than the markup..'? |
| 14:46 | <karlushi> | to validate the code on pastebin, you have to select all and cut and paste it in Direct Input Form. |
| 14:46 | <mokush> | and no, I wasn't trying to validate the link.. |
| 14:46 | <karlushi> | ok |
| 14:46 | <karlushi> | :) |
| 14:47 | <mokush> | I just tought the validator was supposed to post some errors about the <bar> and <extended> attrs |
| 14:48 | <mokush> | but I was wrong |
| 14:49 | <miketaylr> | that why it says "Suppressing further errors from this subtree" |
| 14:49 | <mokush> | yeah, I didn't see that 5 mins ago. |
| 14:50 | <miketaylr> | ;) |
| 16:26 | <annevk> | is there any other WebSocket demo besides the one from Hixie? |
| 16:26 | <annevk> | I wonder what is enabled in Minefield |
| 16:27 | <annevk> | someone made claims on hybi, but I'm sceptical |
| 16:31 | <jgraham> | I think -76 is currently enabled in Minefield |
| 16:32 | <jgraham> | The claim was that this would be disabled or prefixed |
| 16:35 | <annevk> | right |
| 16:35 | <annevk> | I'm not buying that at all |
| 16:35 | <annevk> | which means we might be stuck with -76 forever at the current rate the IETF is doing things |
| 16:36 | <jgraham> | Well yeah I said that back in July |
| 16:37 | <jgraham> | And they eventually agreed in mid August to finish stuff on a four week timescale |
| 16:37 | <jgraham> | That has not happened |
| 16:37 | <jgraham> | Obviously |
| 16:37 | <annevk> | yeah |
| 16:37 | <annevk> | fail |
| 16:38 | <annevk> | they don't even have an open bug as far as I can tell related to the claims of that guy |
| 16:40 | <annevk> | not much traffic either on hybi recently |
| 16:40 | <AryehGregor> | annevk, SVG in text/html has case-insensitive element and attribute names . . . but you're saying that by the time they get to the DOM they're canonical case, so CSS should be case-sensitive? But HTML elements and attributes are lowercased before getting to the DOM in text/html, so how is that different? |
| 16:40 | <jgraham> | It is of course not impossible it will happen |
| 16:40 | <jgraham> | But I agree there is not a great deal of evidence for it |
| 16:40 | <AryehGregor> | (Does HTML define whether CSS should be case-sensitive for text/html?) |
| 16:41 | <Rik`> | annevk: I did this demo and it still works in Minefield |
| 16:41 | <Rik`> | http://ssh.alwaysdata.com:11801/ |
| 16:41 | <annevk> | AryehGregor, it is different because SVG uses camel case element names and to keep performance happy you want pointer comparison |
| 16:42 | <AryehGregor> | annevk, okay, so is this difference specced anywhere? I don't see it immediately. |
| 16:42 | <annevk> | XHR is consistently faster in Firefox, Rik`? :) |
| 16:42 | <Rik`> | annevk: normally, it shouldn't :) |
| 16:42 | <annevk> | AryehGregor, not sure, it's part of Web DOM Core |
| 16:42 | <AryehGregor> | It seems fairly magical. unknownElement { ... } matches <unknownelement>, right? |
| 16:42 | AryehGregor | doesn't really care much, won't bother investigating :) |
| 16:42 | <hsivonen> | AryehGregor: selectors need to have two interned strings: one that's compared against HTML-namespace elements and another that's compard for everything else |
| 16:43 | <annevk> | (the DOM part, not the Selectors part) |
| 16:43 | <annevk> | when is Firefox 4 shipping again? |
| 16:43 | <Rik`> | sometimes before the end of 2010 |
| 16:44 | <hsivonen> | AryehGregor: when the sheet belongs to an HTML doc, the CSS parser needs to ascii-lowercase the interned string that's used for HTML comparisons |
| 16:44 | <annevk> | oh god http://dev.w3.org/2009/dap/features/ |
| 16:44 | <hsivonen> | AryehGregor: https://bugzilla.mozilla.org/show_bug.cgi?id=499655 |
| 16:44 | <AryehGregor> | But then it does the non-HTML comparisons case-sensitively. |
| 16:44 | <hsivonen> | AryehGregor: exactly |
| 16:44 | <AryehGregor> | Fun. |
| 16:46 | <annevk> | I wonder if I should bother hybi with this information |
| 16:48 | <jgraham> | annevk: What information? |
| 16:50 | <Philip`> | Seems good to post and remind people what's important to focus on, since the worst that'll happen is they'll ignore it |
| 16:51 | <annevk> | jgraham, that nothing happened and that Firefox is on track to ship, but I'm not sure I want to deal with the endless emails that'll undoubtedly follow |
| 16:52 | <jgraham> | Well no, the worst that will happen is that they will send you long emails about why you are wrong, and you will be drawn into a pointless discussion that ultimatley has no effect, and you will have wasted hours of your life |
| 16:52 | <jgraham> | And you will turn out to have been right |
| 16:52 | <Philip`> | You can just ignore any responses that aren't clearly driving the discussion forwards |
| 16:52 | <jgraham> | And people will keep bemoaning the fact that browsers didn't do what they wanted |
| 16:52 | <Rik`> | is there any public email about what will ship in Firefox 4 regarding websockets ? |
| 16:53 | <Philip`> | Maybe the browser developers should split off into their own group to focus on what they consider important |
| 16:53 | <jgraham> | And next time the same thing happens people will mysteriously still ignore you when the same thing happens again |
| 16:54 | <jgraham> | Erm, too many happens there |
| 16:54 | <annevk> | Rik`, there is one, yes |
| 16:54 | <Philip`> | Call it the WhyBiWG or something |
| 16:54 | <annevk> | Rik`, I guess I could try to find it |
| 16:55 | <annevk> | that was easier than anticipated |
| 16:55 | <annevk> | http://www.ietf.org/mail-archive/web/hybi/current/msg04029.html |
| 16:57 | <Rik`> | that was more than 2 weeks ago, I think plans have changed again |
| 16:58 | <jgraham> | Philip`: If we call it the WhyBiWG, people will get the wrong idea. And we will probably get the Pope on our backs as well as the IETF. So, I think you are off the naming committee |
| 16:58 | <annevk> | Rik`, interesting, are "plans" public? |
| 16:58 | <Rik`> | I don't know |
| 16:58 | <annevk> | you just happen to know them? :) |
| 16:58 | <Rik`> | I don't remember the timeline but there was a lot of changes |
| 16:59 | <jgraham> | Seems liek a weird thing to keep secret relative to the other stuff that Mozilla makes public |
| 16:59 | <Rik`> | I've heard it was not being shipped, shipped with a prefix, shipped behind a pref, shipped by default |
| 17:00 | <jgraham> | But not necessarily in that order? |
| 17:00 | <Rik`> | yes |
| 18:20 | <mokush> | what would be the best way to provide description for html5 videos? |
| 18:20 | <mokush> | this is mainly aimed at screenreaders, so they read the video's description before they reach the controls |
| 18:22 | <Philip`> | Does https://perf.wiki.kernel.org/ give errors in Opera ("Secure connection: fatal error (112) from server") or is it just me? |
| 18:23 | <gavin> | Philip`: I get that too |
| 18:24 | <Philip`> | Works for me in Firefox |
| 18:24 | <gavin> | the opera updater seems to be broken |
| 18:25 | <gavin> | downloads the 10.62 update but fails to install it |
| 18:25 | <annevk> | bah, Microsoft obstructing automating the CSS test suite |
| 18:26 | <gavin> | where? |
| 18:26 | <annevk> | http://lists.w3.org/Archives/Public/public-css-testsuite/2010Sep/0117.html |
| 18:27 | <TabAtkins> | annevk: No, they're expressing the exact same concern I did. We just need to get 2.1 through REC with the testsuite it has, *then* spend the effort making the testsuite actually useful. |
| 18:28 | <gavin> | I would prefer "John Jansen obstructing" |
| 18:28 | <annevk> | I don't want to waste Opera QA time for "REC" purposes |
| 18:28 | <gavin> | kind of annoys me when people refer to "Mozilla" as a whole based on what one person says, so probably shouldn't do it for microsoft either :) |
| 18:28 | <annevk> | CSS 2 has not been a "REC" for over a decade, it can wait a little longer |
| 18:28 | <annevk> | gavin, fair enough |
| 18:29 | <TabAtkins> | Go tell that to glazou, who I'm pretty sure would agree with what Jansen is saying. |
| 18:29 | <annevk> | I'll tell him when he asks us to make those hours |
| 18:30 | <annevk> | oh, apparently gsnedders knows more than I do |
| 18:38 | <MikeSmith> | w3c bugzilla down at the moment |
| 18:39 | <MikeSmith> | systems team has been alerted |
| 19:04 | <hober> | the elisp tokenizer is basically done |
| 19:05 | <hober> | though without a parser on top of it I can't get at any of the states that get triggered by the parser (RAWTEXT stuff, etc.) |
| 19:06 | <hober> | my "pile of rubbish markup" file for exercising tokenizer states all of the other ones though |
| 19:06 | <TabAtkins> | That sentence not parse. |
| 19:13 | <hober> | yeah, indeed. s/all/hits all/ |
| 19:35 | <annevk> | is someone still keeping track of http://groups.google.com/group/html5lib-discuss/ ? |
| 19:35 | <annevk> | there's a number of unanswered questions there |
| 19:36 | <annevk> | I think my role is approving messages at this point, as my latest commit to the project was a long time ago :/ |
| 19:50 | <jgraham> | I am very poor at responding to messages there :( |
| 19:51 | <jgraham> | hober: You are using the html5lib tests, right? |
| 19:51 | <annevk> | the entity one found its way here |
| 19:51 | <annevk> | I believe |
| 19:51 | <annevk> | not sure about the rest |
| 19:51 | <jgraham> | Yeah I need to check out the spec on the entity thing |
| 19:53 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html |
| 19:53 | <annevk> | sweet |
| 20:11 | <annevk> | Peter`, I doubt writing-mode is supported; the change seems to suggest that parsing and serializing of the property is supported, but not its actual effects |
| 20:13 | <Peter-> | annevk, I've changed it to "interpreted" for now, although the layout test suggests otherwise |
| 20:13 | <Peter-> | going to test it |
| 20:13 | <annevk> | https://bugs.webkit.org/show_bug.cgi?id=45020 also says only parser support |
| 20:14 | <karlushi> | annevk, Web Dom Core algorithms are normative or not? |
| 20:14 | <annevk> | Peter-, the layout tests are for serializing (getComputedStyle) |
| 20:14 | <annevk> | karlcow, normative |
| 20:15 | <jgraham> | annevk: presumably black-box normative |
| 20:15 | <Peter-> | You're right. Well spotted |
| 20:15 | <annevk> | Peter-, if they had added vertical text in a week with no feedback and me not noticing I'd have been very surprised :) |
| 20:16 | <karlushi> | ah I see. the Conformance requirements section confused me. I read it again carefully. |
| 20:16 | <karlushi> | thanks |
| 20:18 | <Peter-> | annevk, updated it :) Was a bit of a quick job, didn't have a lot of spare time |
| 20:20 | <annevk> | Peter-, no worries; posts are nice; short and to the point |
| 20:21 | <karlushi> | oh a "goto" |
| 20:22 | <jgraham> | annevk: Please no gotos :) They are the worst thing about Hixie's specs |
| 20:22 | <annevk> | goto? |
| 20:23 | <hsivonen> | specs should only allow break and continue (by label) |
| 20:23 | <annevk> | if there's a goto it's not my fault |
| 20:24 | <annevk> | but let me know and I'll remove it |
| 20:24 | annevk | can't find it |
| 20:24 | <annevk> | going to watch Studio 60; supposedly it's awesome |
| 20:25 | karlushi | search Studio 60 on the Web :) |
| 20:25 | <karlushi> | http://en.wikipedia.org/wiki/Studio_60_on_the_Sunset_Strip ? |
| 20:25 | jgraham | can't see the goto either |
| 20:27 | <jgraham> | Oh it's in common microsyntaxes |
| 20:27 | <jgraham> | Which I assume is just taken from HTML5 |
| 20:31 | <hober> | jgraham: I will be |
| 20:31 | <karlushi> | yep in common microsyntaxes |
| 20:31 | <karlushi> | # |
| 20:31 | <karlushi> | Loop: If position is beyond the end of input, terminate these steps. |
| 20:31 | <karlushi> | # |
| 20:31 | <karlushi> | Return to the step labeled loop. |
| 20:39 | <jgraham> | hober: I assume you know there are seperate tests for the tokenizer alone |
| 20:40 | <hsivonen> | karlushi: that can be dressed as a continue, so it's ok |
| 20:41 | <jgraham> | hsivonen: It would still be better phrased as such |
| 20:42 | <jgraham> | (don't get me wrong, I think Hixie's style is orders of magnitude better than the prevaling style at W3C prior to HTML5. But it is not as clear as it could be in some cases) |
| 20:44 | <hober> | jgraham: yes |
| 20:46 | <annevk> | karlushi, yeah, that's the one, it's pretty good so far |
| 20:46 | <annevk> | oh, common microsyntaxes |
| 20:46 | <annevk> | haven't really studied those yet |
| 20:48 | <karlushi> | I'm always careful, but would it be better if you indent 6. as a 1. because the "terminate these steps." seems to be a bit awkward |
| 21:29 | <tonyg-cr> | Hi, I heard a rumor there might be Opera folks hanging out it here. I've been playing around with the "Delayed script execution" feature for a bit and am surprised that I haven't been able to write a test case that breaks it. I'm curious how it works and if there are known bugs. |
| 21:31 | <jgraham> | tonyg-cr: Yes there are Opera folks here. DSE works by "magic" (I would say more but I would probably get it wrong). I believe there are some outstanding issues that prevent it being enabled by default |
| 21:32 | <jgraham> | If you find a case that breaks we would be interested to hear about it |
| 21:32 | <jgraham> | File a bug |
| 21:33 | <jgraham> | Basically it is rather like the speculative parsing of other browsers |
| 21:33 | <tonyg-cr> | jgraham: It is quite magical :) |
| 21:34 | <tonyg-cr> | I was expecting it to easily break, but it appears quite resilient |
| 21:34 | <tonyg-cr> | Does it snapshot the DOM at each point? |
| 21:34 | <tonyg-cr> | Or somehow mark versions/generations on the tree? |
| 21:34 | <jgraham> | I'm not sure about the implementation details |
| 21:36 | <tonyg-cr> | The closest thing I could find to a bug is flash of unstyled content (e.g. aol.com), but everything always seems to end up correct even in some pathological test cases |
| 21:36 | <TabAtkins> | jgraham: Who's a better person to ask? zcorpan? Someone else? |
| 21:37 | <jgraham> | TabAtkins: Umm, I guess jl or bratell or one of the other developers. But they don't really hang out here :) |
| 21:37 | <TabAtkins> | Could you /msg tonyg with some email addresses or something? |
| 21:38 | <jgraham> | TabAtkins: I should be able to remember more about it than I can. Also, I am not sure how much is considered secret sauce |
| 21:40 | <tonyg-cr> | jgraham: yeah, proprietary implementation makes sense (it is awesome work), i guess i'm more wondering what sort of things tend to break — if it is really compatible with the web should that behavior be specced? |
| 21:42 | <AryehGregor> | What does Opera's "delayed script execution" do? If it's really the same as other browsers' speculative parsers or whatever, then it causes no semantic changes, so it should break nothing. |
| 21:42 | <AryehGregor> | (nor does it make sense to spec it in that case) |
| 21:43 | <jgraham> | tonyg-cr: It doesn't really make sense to spec it |
| 21:43 | <AryehGregor> | http://www.stevesouders.com/blog/2008/09/11/delayed-script-execution-in-opera/ makes it sound like it's something totally different, though. |
| 21:43 | <jgraham> | It is ideally black-box indistinguishable from not-having the feature (except from performance) |
| 21:45 | <AryehGregor> | So it not only reads ahead to fetch resources when blocked on script, it also adds stuff to the DOM and lays things out, then just rewrites it once the script loads? |
| 21:45 | <jgraham> | AryehGregor: "like" was not supposed to be exact |
| 21:45 | <AryehGregor> | That sounds pretty cool, but also sounds hard to get right. :) |
| 21:49 | <tonyg-cr> | jgraham: thanks for the info, it is really interesting work :) |
| 21:57 | <hsivonen> | tonyg-cr: afaict, document.write in both Opera and IE works very differently from the stream insertion Gecko, WebKit and HTML5 have |
| 21:58 | <tonyg-cr> | I'm familiar w/ the stream insertion model, what does opera do differently? |
| 21:59 | <hsivonen> | tonyg-cr: I think I wrote a test case where poking to DOM suggested that document.written stuff went on the side somehow instead of going into the stream |
| 21:59 | <hsivonen> | let's see if I'm remembering correctly |
| 22:00 | <hsivonen> | oh yes |
| 22:01 | <hsivonen> | tonyg-cr: if you take a look at the number of script elements found in the DOM in http://hsivonen.iki.fi/test/moz/sheet-blocking-script.html |
| 22:02 | <hsivonen> | or was it http://hsivonen.iki.fi/test/moz/sheet-blocking-script2.html |
| 22:03 | <tonyg-cr> | well the # in the first test does vary w/ DSE is toggled in Opera |
| 22:03 | <hsivonen> | huh. now I see the same numbers in Minefield and Opera at home |
| 22:03 | <hsivonen> | I wonder if I had a different configuration at work |
| 22:04 | <tonyg-cr> | toggle this: opera:config#Delayed%20Script%20Execution |
| 22:05 | <hsivonen> | yeah, the number changes |
| 22:06 | <hsivonen> | tonyg-cr: now I remember what the weird thing is |
| 22:07 | <hsivonen> | so if the number is 2, you'd expect the parser to have blocked |
| 22:07 | <hsivonen> | but elapsed and the color suggest it didn't block |
| 22:09 | <tonyg-cr> | hsivonen: that is odd, still wrapping my head around it |
| 22:09 | <hsivonen> | um. maybe I'm just confused now |
| 22:11 | <hsivonen> | now, that's the oddity. some clues suggest it blocked while others suggest it didn't |
| 22:11 | <hsivonen> | the other day I concluded that Opera and WebKit never block scripts on style sheets |
| 22:13 | <hsivonen> | I wouldn't be surprised if Opera had some DOM snapshotting mechanism |
| 22:14 | <hsivonen> | I can imagine such a mechanism would be useful for Mini going back to the server to run a script off an event handler |
| 22:15 | <hsivonen> | well, maybe that doesn't require snapshotting per se |
| 22:15 | <hsivonen> | but requires a way to hibernate a DOM in an inexpensive way |
| 22:16 | <hsivonen> | (I'm assuming Mini doesn't keep as many active browser instances alive as there have been recent Mini page loads) |
| 22:16 | <annevk> | I don't think we go back to the server |
| 22:17 | <hsivonen> | annevk: I can highlight lines in krijn's logs on Mini |
| 22:17 | <hsivonen> | if it's been a couple of minutes since the page load, it works |
| 22:18 | <hsivonen> | annevk: but after some timeout, it stops working |
| 22:19 | <annevk> | oh, maybe for some things we do |