| 00:00 | <zcorpan_> | gmail html basic has plain links |
| 00:00 | <zcorpan_> | <a href="..." target="_blank"> |
| 00:08 | <Hixie> | zcorpan_: so i guess at least for gmail it's not an issue |
| 00:08 | <zcorpan_> | yeah |
| 00:12 | <zcorpan_> | <input title="name"type="text"> that fails wcag 2.0 because of lack of whitespace between the attributes |
| 00:13 | <Hixie> | o_O |
| 00:13 | <zcorpan_> | see 4.1.1 in http://www.w3.org/TR/WCAG20-TECHS/ |
| 00:21 | <zcorpan_> | search for "SCR24: Using script to open a new window" to find the accessible version of target="_blank" |
| 00:24 | <zcorpan_> | font-size must also be specified with %, apparently |
| 00:25 | <zcorpan_> | or am i misreading the document? the next technique contradicts that |
| 00:26 | <othermaciej> | zcorpan_: wait, why is that an accessibility issue? |
| 00:27 | <zcorpan_> | othermaciej: because ie6 can't change the text size if you specify "absolute" units |
| 00:27 | <othermaciej> | not the % thing, the lack of whitespace between attributes |
| 00:27 | <zcorpan_> | oh |
| 00:28 | <zcorpan_> | yeah, dunno |
| 00:28 | <zcorpan_> | the document also says that <p>foo<p>bar</p> in XHTML is a fail, because it is "unclear" whether the second paragraph is a child or a sibling to the first |
| 00:38 | <othermaciej> | so they're assuming XHTML will be processed with an error-correcting html parser? |
| 00:38 | <zcorpan_> | i have no clue |
| 00:39 | <zcorpan_> | in html, it is not unclear at all. in xml, it's not unclear at all either |
| 00:39 | <othermaciej> | it's unclear if you don't know what parser will be used |
| 00:39 | <othermaciej> | but then they could just say that |
| 00:39 | <zcorpan_> | indeed |
| 00:41 | <zcorpan_> | if that's what they meant, then it's equally unclear how <noscript> will be parsed |
| 00:56 | <bewest> | is there a list of elements categorized by block/inline level? |
| 00:58 | <zcorpan_> | don't think so |
| 01:04 | <webben> | How does the HTML5 table algorithm prevent a <th scope="rowgroup"> from being part of a <th scope=col">? |
| 01:11 | <zcorpan_> | webben: i don't understand the question |
| 01:13 | <webben> | zcorpan_: here's an example from something I'm working on. First a simple table with rows and cols: http://uk.biz.yahoo.com/16/index.html |
| 01:13 | <webben> | 2nd the same thing, but organized into rowgroups http://uk.biz.yahoo.com/16/sector.html |
| 01:13 | <webben> | now in the first instance, scope="col" for the top headers works for all the row headers |
| 01:14 | <webben> | but this can't work in the second instance since the sectors are in that column as per HTML4 spec |
| 01:16 | <zcorpan_> | i still don't understand the problem |
| 01:18 | <zcorpan_> | i wonder if it's possible to implement the html5 table algorithm with JS, so that when you hover a data cell, its header cells are highlighted, and when you hover a table cell, its data cells are highlighted |
| 01:18 | <zcorpan_> | that would be really useful |
| 01:19 | <zcorpan_> | s/table cell/header cell/ |
| 01:19 | <webben> | Hmm. Well if I understand the HTML4 spec correctly, the sector th's are in the first column. Therefore if you have a th with scope="col" it would technically imply itself to be a header for the sector th's. |
| 01:19 | <webben> | zcorpan_: well, we've got that for headers/ids but not for scope yet |
| 01:19 | <webben> | (Firefox Accessibility Extension) |
| 01:20 | <webben> | it is rather useful :) |
| 01:20 | <zcorpan_> | oh, didn't know about it |
| 01:20 | <webben> | http://firefox.cita.uiuc.edu/ ... that one, get the beta version. Navigation menu, Data tables. |
| 01:20 | <webben> | dunno why scope doesn't work with it though |
| 01:21 | <webben> | maybe firefox ignores it |
| 01:21 | <webben> | not sure |
| 01:21 | <webben> | or maybe it's because it's primarily a testing tool and only secondarily a user tool |
| 01:22 | <zcorpan_> | maybe firefox ignores both of headers and scope, but headers is easier to implement with the extension |
| 01:24 | <webben> | Actually I guess since it will be using the DOM, what FF does with headers and scope is irrelevant. |
| 01:24 | <zcorpan_> | yeah |
| 01:27 | <othermaciej> | webben: does the HTML5 table algorithm allow headers to have headers? |
| 01:28 | <webben> | othermaciej: If it doesn't, then that's even more problematic. Seeing as in real tables, headers often have headers. |
| 01:28 | <webben> | othermaciej: i agree the draft seems unclear on that point ... i was wondering it myself |
| 01:28 | <webben> | if HTML5 doesn't allow th to have headers than the attrib should be non-conforming for th |
| 01:28 | <zcorpan_> | what attribute? |
| 01:29 | <webben> | HTML4 clearly does allow th to have headers |
| 01:29 | <zcorpan_> | "clearly"? |
| 01:29 | <webben> | oh wait... yeah good point it can't do it by disallowing headers since it doesn't have headers |
| 01:29 | <webben> | zcorpan_: well yeah ... both th and td have headers attribute |
| 01:30 | <webben> | they could easily have made the headers attrib non-conforming for th |
| 01:30 | <zcorpan_> | webben: right. it was more convenient to write the DTD in that way... :P |
| 01:30 | zcorpan_ | doesn't think html4 is clear about this at all |
| 01:30 | <zcorpan_> | or anything for that matter |
| 01:31 | <webben> | Hmm. I can't really believe that including headers attribute for th was for shortening the length of DTD. |
| 01:31 | <zcorpan_> | i don't know the rationale |
| 01:32 | <webben> | interesting the example in 11.4.1 shows use of the scope attrib with td |
| 01:32 | <webben> | the spec explains: "Although the first cell in each row contains data, not header information, the scope attribute makes the data cell behave like a row header cell. This allows speech synthesizers to provide the relevant course name upon request or to state it immediately before each cell's content." |
| 01:33 | <zcorpan_> | yeah, not sure if having cells act as both data cells and header cells is a good thing or not |
| 01:33 | <webben> | I guess the important thing is to devise ways of clearly expressing relationships between data. |
| 01:34 | <webben> | and not let the header/non-header thing devolve into an even more presentational distinction |
| 04:02 | <Hixie> | hm |
| 04:02 | <Hixie> | someone should post a blog entry about our progress with w3c |
| 04:02 | <Hixie> | any volunteers? :-) |
| 04:07 | <jcgregorio> | working on it right now :) |
| 04:08 | <Hixie> | sweet |
| 04:08 | <jcgregorio> | don't know which title to use, |
| 04:08 | <jcgregorio> | "jaw drop", or "OMG WTF?!?!" |
| 04:09 | <Hixie> | i recommend staying away from too much sarcasm ;-) |
| 04:10 | <jcgregorio> | heh, agreed. |
| 04:18 | <jcgregorio> | http://bitworking.org/news/178/The-W3C-s-next-generation-HTML-specification |
| 04:19 | <Hixie> | oh i meant on the whatwg blog :-) |
| 04:20 | <Hixie> | i love the first comment on http://bitworking.org/news/3270_Redux |
| 04:23 | <jcgregorio> | yeah, Dare, ever the optimist |
| 04:24 | <jcgregorio> | last comment is good too, I forgot that this was around the time that the w3c was angling for some Atom love... |
| 04:43 | <jruderman> | h3h! |
| 04:43 | <h3h> | hey |
| 04:44 | <h3h> | how goes it? |
| 04:49 | <jruderman> | it's intern season here at mozilla |
| 04:49 | <jruderman> | fun times |
| 06:11 | <Hixie> | i'm very good at writing long run-on sentences in specs |
| 06:11 | <Hixie> | that's sad, since that's a bad thing. |
| 06:11 | <othermaciej> | you are indeed |
| 06:12 | <othermaciej> | I'll do my best to complain when I get the chance |
| 06:35 | <zcorpan_> | anyone know what "malformed" would be in swedish? |
| 10:13 | <annevk> | hasather, something goes wrong with partition making |
| 10:13 | <annevk> | hasather, it also didn't get the resolution right, but that was fixable |
| 10:16 | <annevk> | Documents such as "<!DOCTYPE html [ <!ENTITY name '&name;x'> ]><html>&name;</html>" are now parsed... |
| 10:16 | <annevk> | You end up with <html>xxxxxxxxxxxxxxxx</html> |
| 10:16 | <annevk> | (The loop limit is 16.) |
| 10:17 | <Dashiva> | So no billions then |
| 10:17 | <annevk> | I thought it would be better to prevent that right from the start :-) |
| 10:20 | <Lachy> | why allow it to loop at all? Why not prevent any recursion, so it would only output 1 x |
| 10:20 | <hasather> | annevk: ok. Have a look at this and see if it's any help: http://thinkwiki.org/wiki/Installing_Ubuntu_6.10_(Edgy_Eft)_on_a_ThinkPad_T60 (that site is great for ThinkPad users btw) |
| 10:21 | <annevk> | Lachy, because there's tons of ways to do looping and this way it catches all of them |
| 10:21 | <annevk> | Lachy, it also prevents the billion laughs attack etc. |
| 10:24 | <Lachy> | what's the billion laughs attack? |
| 10:24 | <Dashiva> | Uses looping entities to generate a document with a billion 'laugh' |
| 10:25 | <Dashiva> | One entity generates two, which each generate two, etc |
| 10:25 | <Dashiva> | *non-looping |
| 10:51 | <gsnedders> | bleh. rss-public is trying to work out Dave Winer's intent of a statement in RSS 2.0, for the purposes of clarifying the spec |
| 10:51 | <annevk> | lol |
| 10:52 | <annevk> | looking at specs is so the wrong way to solve actual problems (most of the time) |
| 10:52 | <gsnedders> | "A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace." — are you allowed namespaced attributes on core elements? |
| 10:52 | <Dashiva> | And the RSS "specs" make HTML 4.01 look well-defined |
| 10:53 | <annevk> | Something with my entities stuff is messed up |
| 10:53 | <annevk> | bah |
| 10:53 | <gsnedders> | Rogers Cadenhead has cited several other things that Dave Winer said on the subject matter, which say yes in answer to that question. |
| 11:10 | <mpt> | ooh, that's like constitutional interpretation |
| 11:10 | <mpt> | Going just by the spec = strict constructionist |
| 11:10 | <mpt> | Researching Dave's other writings = original intent |
| 11:13 | <mpt> | But one thing I learnt in legal history class is that for interpretive purposes, you shouldn't rely on the writings of any legal authority until they've died |
| 11:13 | <mpt> | because if they're still alive, they might change their mind |
| 11:13 | <mikeday> | hmm, I hope you're not suggesting killing Hixie after HTML5 goes Rec :) |
| 11:14 | <mpt> | No, I'm suggesting that we go by what the spec says rather than by what he posts elsewhere |
| 11:15 | <mpt> | though of course he's free to update the spec :-) |
| 11:15 | <mikeday> | you must admit, it would make a good crime thriller episode if spec authors mysteriously started disappearing :) |
| 11:15 | <mpt> | This principle is also known as "I would also like to thank Ian Hickson for reminding the world that the things I write in this weblog are not spec text." |
| 11:15 | <gsnedders> | mpt: even if the writings both predate and postdate (is that a word?) the spec? |
| 11:15 | <mpt> | http://diveintomark.org/archives/2004/01/08/postels-law |
| 11:16 | <gsnedders> | mpt: and it is explicitly stated that that was the intent of the spec? |
| 11:16 | <mpt> | gsnedders, yes, even so. |
| 11:17 | <mpt> | If the spec needs updating, update it. |
| 11:17 | <mpt> | Or produce errata, and say "we comply with spec X with errata Y". |
| 11:18 | <gsnedders> | mpt: that's the issue — are they just updating the spec in such a way it is merely a clarification? |
| 11:19 | <mpt> | I don't really care about this particular example |
| 11:19 | <mpt> | RSS 2.0 is such a disaster zone I want to avoid thinking about it |
| 11:20 | <gsnedders> | it's used in the real world. as implementors, we need to implement it |
| 11:20 | <gsnedders> | (and fix the spec) |
| 11:20 | <mikeday> | whatwg needs to fix RSS? |
| 11:21 | <gsnedders> | mikeday: no, the rss-board are already doing so |
| 11:21 | <gsnedders> | http://www.rssboard.org/rss-draft-1 |
| 11:21 | <mpt> | Be careful throwing around words like "we" :-) |
| 11:22 | <mikeday> | hmm, not really a problem then, eh? |
| 11:22 | <gsnedders> | mikeday: oh, there are problems. see the mailing list. see real world feeds, etc. |
| 11:22 | <mikeday> | not really a problem for #whatwg then, I meant :) |
| 11:23 | <gsnedders> | true, but there are others here who implement RSS :P |
| 11:24 | <mikeday> | maybe it would have been easier if RSS has used HTML based markup instead of trying to corrupt XML |
| 11:25 | <gsnedders> | that's not the issue with RSS, the issue is how vague the spec is |
| 11:25 | <Dashiva> | I wouldn't mind burying RSS in favor of Atom |
| 11:26 | <gsnedders> | like people who implement real XHTML, to be relevant in the real world they need to implement HTML too |
| 11:27 | <mikeday> | hrmph, if only that weren't so. |
| 11:27 | <mikeday> | it's certainly the way we're going |
| 14:05 | <Dashiva> | Grar |
| 14:05 | <Dashiva> | My inner calm is upset by html60 |
| 14:08 | <Philip`> | I'm not positive that I like the idea of eleding sag seributes in a form |
| 14:10 | <Philip`> | I think the names need more X in them before they'll catch on |
| 14:13 | <zcorpan_> | XSeribute |
| 14:16 | <annevk> | Dashiva, I are agree |
| 14:18 | <zcorpan_> | is it can be foods tiem now? |
| 14:18 | annevk | plays with Ubuntu |
| 14:21 | <zcorpan_> | http://www.nnseek.com/e/microsoft.public.windowsmedia/new_updated_wmp11_plug_in_for_other_third_party_br_77036744t.html |
| 14:23 | Philip` | wonders what was in the "relies on the stuff" phrase before presumably being stripped out as disallowed HTML |
| 14:24 | <zcorpan_> | <script for="" event="'> |
| 14:24 | <zcorpan_> | http://forums.techarena.in/showthread.php?p=2551897 |
| 14:25 | <Philip`> | Aha |
| 14:38 | <annevk> | argh |
| 14:40 | <annevk> | time to port some projects... |
| 15:01 | <hasather> | hsivonen: in case you haven't seen: http://www.oreillynet.com/xml/blog/2007/05/fake_realtime_blog_from_xtech.html |
| 16:45 | <zcorpan_> | am i right in saying that html5lib can emit sax parse events? |
| 16:45 | <annevk-t60> | yeah, sort of |
| 16:45 | annevk-t60 | doesn't recall the details |
| 16:46 | <zcorpan_> | streaming? |
| 16:47 | <annevk-t60> | you can't stream html5 |
| 16:47 | <annevk-t60> | well, not in the XML way |
| 16:49 | <zcorpan_> | you can if you're drocanian about the agency thing :) |
| 16:50 | <zcorpan_> | http://simon.html5.org/temp/html5-geekmeet.en.html |
| 16:51 | <zcorpan_> | translated it |
| 16:54 | <annevk-t60> | "definierad" |
| 16:54 | <zcorpan_> | oops |
| 16:55 | <zcorpan_> | fixed |
| 16:56 | <Philip`> | The boilerplate example could drop the / in <meta charset="utf-8" /> |
| 16:56 | <zcorpan_> | yeah |
| 16:57 | <zcorpan_> | though there's no benefit in dropping it, other than saving 2 bytes |
| 17:10 | <zcorpan_> | other comments? :) |
| 18:48 | <Philip`> | Optimising <canvas> code seems a bit of a pain - different implementations have very different performance characteristics :-( |
| 18:50 | <Philip`> | drawImage(img, <some scaling>) is twice as fast as drawImage(canvas, ...) in Firefox 3, and ~20% faster in FF2, but the latter is ~50% faster than the former in Opera |
| 18:51 | <Philip`> | and drawImage(img, <no scaling>) is about sixty times faster in FF3 than it was in FF2 |
| 18:52 | <Philip`> | and all these numbers are probably totally different in Safari, and on other platforms |
| 18:52 | <Philip`> | and I can't think of any way to handle the differences, without resorting to browser-sniffing and a table of preferences :-( |
| 18:54 | <zcorpan_> | ah, browser sniffing |
| 20:55 | <jgraham> | zcorpan_: html5lib has a dom2sax converter. Basically you use the dom treebuilder and then call treebuilders.dom.dom2sax on the resulting tree. So it's not true streaming (because the algorithm as specced doesn't allow for that). hsivonen has some interesting thoughts on a fast-as-possible streaming implementation |
| 20:55 | <jgraham> | n.b. that function call is from memory... |
| 20:56 | <zcorpan_> | jgraham: ok |
| 20:59 | zcorpan_ | updated his slides |
| 21:19 | <Hixie> | Philip`: the best way to handle it is not optimising at all, and just rely on browser vendors to make things faster |
| 21:26 | <zcorpan_> | Hixie: you have any comments for my slides for my presentation tomorrow? http://simon.html5.org/presentations/html5-geekmeet.en |
| 21:34 | Hixie | loojs |
| 21:36 | <othermaciej> | what does it mean "to looj"? |
| 21:36 | <Jero> | zcorpan_: minor detail, but the charset attribute in the second "text/html: boilerplate" slide has the wrong color |
| 21:37 | <Hixie> | zcorpan_: the audio interface changed quite a bit since opera implemented it |
| 21:39 | <Hixie> | the google suggest example needs to have the value URI escaped |
| 21:39 | <Hixie> | also the following parts of the boilerplate are optional: |
| 21:39 | <Hixie> | <html> |
| 21:39 | <Hixie> | <head> |
| 21:39 | <Hixie> | <meta charset="utf-8" /> |
| 21:40 | <Hixie> | looks fine |
| 21:40 | <Hixie> | what's your audience? |
| 21:41 | <zcorpan_> | mostly people who work with creating web sites |
| 21:41 | <Hixie> | k |
| 21:43 | <zcorpan_> | Jero: it's the same as the first, just in the process of becoming shorter... ;) |
| 21:46 | <Jero> | yeah, but i thought that because of it being shorter, it became an attribute, so you might wanted to also show that in that slide |
| 21:46 | <Jero> | but i guess it depends on how you look at it, and it's not that big of a deal either :p |
| 21:56 | <jgraham> | zcorpan: "De facto standards i HTML5" s/i/in/ I assume |
| 21:56 | <zcorpan> | jgraham: yep, thanks |
| 22:00 | <jgraham> | zcorpan: <meta charset="utf-8" /> - no need for the trailing slash. Also p = html5lib.HTMLParser(tree=etree.TreeBuilder) - this has changed a bit in svn to support more elementtree implementations. Probably not worth worrying about though. |
| 22:01 | <zcorpan> | jgraham: how should the python line look like? |
| 22:02 | <jgraham> | I think it should be import treebuilders; from xml.etree import ElementTree; html5lib.HTMLParser(tree=treebuilders.getTreebuilder("etree", ElementTree)) |
| 22:02 | jgraham | goes to check |
| 22:04 | <jgraham> | OK the full thing is |
| 22:04 | <jgraham> | import html5lib |
| 22:04 | <jgraham> | from html5lib import treebuilders |
| 22:05 | <jgraham> | import xml.etree.ElementTree as ElementTree #assuming python >= 2.5 |
| 22:06 | <jgraham> | p = html5lib.HTMLParser(tree=treebuilders.getTreeBuilder("etree", ElementTree)) |
| 22:06 | <jgraham> | elementtree = p.parse(f) |
| 22:06 | <zcorpan> | cheers |
| 22:08 | <zcorpan> | no f = open("test.html") ? |
| 22:12 | <zcorpan> | is it possible to linewrap between "treebuilders" and ".getTreeBuilder" ? |
| 22:14 | <jgraham> | Ah, yes, even copying and pasting I forgot the f = open("test.html") |
| 22:14 | <jgraham> | And there shouldn't be a linewrap but I think python syntax would allow one there |
| 22:15 | <hasather> | yea, it's allowed as it's inside a paranthesis |
| 22:15 | <zcorpan> | ok |
| 22:15 | <jgraham> | but I think it has to be after the dot |
| 22:16 | <jgraham> | No it doesn't |
| 22:16 | <jgraham> | Either side of the dot is fine |
| 22:16 | jgraham | should know this sort of thing by now |
| 22:18 | <zcorpan> | there. i presume a minidom equivalent would be no shorter? :) |
| 22:19 | <jgraham> | minidom is a little shorter atm because we only support one DOM implementation |
| 22:20 | <zcorpan> | ok |
| 22:20 | <zcorpan> | i'll leave it as is |
| 22:20 | <jgraham> | so you can just do html5lib.HTMLParser(tree=treebuilders.getTreeBuilder("dom")) |
| 22:20 | <jgraham> | but that may change again |
| 22:20 | <jgraham> | if there is another python DOM imp[lementation we can trivially support |
| 22:21 | <jgraham> | If you have space a little more indentation on the .getTreeBuilder line would be nice |
| 22:23 | karlUshi | wonders where the getTreeBuilder is coming from |
| 22:24 | <zcorpan> | jgraham: happy? :) |
| 22:25 | <jgraham> | karlUshi: It's a new (svn) feature - instead of having to know the internals of each TreeBuilder module you just call getTreeBuilder(treetype) which returns the appropriate class |
| 22:26 | <karlUshi> | which version? |
| 22:26 | <karlUshi> | ah not yet packaged |
| 22:26 | <jgraham> | for elementtree it also supports passing in an object which implements the elementtree interface so, in theory, we support all elementtree types |
| 22:26 | <jgraham> | s/types/implementations/ |
| 22:27 | <jgraham> | I dunno if it's the *best* way to do what's needed but I think it's *better* |
| 22:28 | <zcorpan> | are things outside the root element included in the elementtree? or did you settle for two elementtree versions? |
| 22:30 | <jgraham> | There's a third (not talked about) parameter for getTreeBuilder fullTree which defaults to false. If fullTree is false trees which don't support stuff outside the root element (i.e. elementtree, beautiful soup (work in progress)) will just return the subtree rooted at <html> |
| 22:31 | <jgraham> | fullTree = True is needed for testing |
| 22:31 | <zcorpan> | ok |
| 22:31 | <jgraham> | but I'm not sure how much sense it makes to try and expose stuff that a tree just doesn't support |
| 22:32 | <jgraham> | So e.g. elementtree has no support for doctypes |
| 22:32 | <jgraham> | and although we can hack in support it might break other tools |
| 22:32 | <jgraham> | which ruins the whole html5lib -> your existing tools workflow |
| 22:33 | <zcorpan> | perhaps the spec should allow things outside the root to be dropped |
| 22:33 | <zcorpan> | safari and opera already drop the doctype iirc |
| 22:34 | <Hixie> | the spec doesn't put any requirements on anything outside the root other than for scripted DOM implementations (which html5lib isn't) |
| 22:43 | <zcorpan> | there are 130 names in the Acks |
| 22:53 | <Dashiva> | Hey Hixie, I understand acid3 is not available, not finished and all, but how about at least removing that incomplete line that triggers a parse error and makes it not work at all :) |
| 22:54 | <Hixie> | why? |
| 22:54 | <Dashiva> | So the tests that do work can be run |
| 22:55 | <Hixie> | why? browser vendors won't want the big test, and who else is there who would care? |
| 22:56 | <Dashiva> | Those of us who hunt unreported bugs |
| 22:56 | <Hixie> | copy the file and edit it :-P |
| 22:57 | <Dashiva> | Darn, I was hoping you wouldn't think of that |
| 22:57 | <Hixie> | i'm in the middle of writing that test, it's not done yet, i'm not going to go out of my way to make it usable when all that would do is make my work harder |
| 22:58 | <Hixie> | the tests in it are all based on other tests on hixie.ch anyway as far as i recall |
| 22:58 | <Hixie> | and are trivially extractable |
| 23:04 | <Philip`> | Hixie: Waiting for browsers to make my code faster doesn't seem like it'd work too well in practice, since the bottlenecks that affect my code might not affect anyone else so the browsers wouldn't care enough to spend the effort optimising it; and even if they did fix it, it'd take a year or two for the next release to get out there, whereas I would want it to work as well as possible for people today |
| 23:05 | <Hixie> | fair enough. but then you'll have the same problem that any optimising compiler has -- different platforms and architectures have different characteristics and so will need optimising in different ways. :-) |
| 23:06 | <Philip`> | although in practice I see 50% of people using Firefox 2 on Windows so I could just optimise for that and forget about everyone else, but I prefer to be nice to everyone else :-) |
| 23:07 | <jruderman> | Hixie: what does "the animation while the test was running has to be smooth" mean? no pauses in the percentages? the color changes should be gradual? |
| 23:09 | <Philip`> | I think the main problem is just working out what the characteristics are - I suppose I could have some one-off calibration process that measures some things, and store the results in globalStorage so it can skip that step next time, and then it'll be better at adapting to unexpected/unknown platforms |
| 23:10 | <Hixie> | jruderman: it means you should be getting 20fps or better |
| 23:10 | <Philip`> | (maybe kind of like an optimising compiler that emits two versions of a function, one with plain x86 code and one with SSE3, with run-time detection of which version it should use, although not really like that since that can just ask the CPU for its capabilities instead of guessing...) |
| 23:10 | <Hixie> | Philip`: until a user upgrades to another browser and the browser imports those globalStorage settings :-) |
| 23:11 | <jruderman> | Hixie: hmm. i get a slight pause at 44% or 45% in firefox trunk |
| 23:11 | <Philip`> | It'd associate the results with the UA string to avoid that problem :-) |
| 23:11 | <jruderman> | Hixie: old computers need not apply? :P |
| 23:12 | <Philip`> | although if they upgrade their hardware and copy their old browser settings... |
| 23:12 | <Dashiva> | Odd, the tests around 44-45 are all empty |
| 23:12 | <Hixie> | jruderman: you shouldn't see jerks in any browser on any platform |
| 23:13 | <jruderman> | maybe that's when the browser decides to do javascript+xpcom garbage collection |
| 23:14 | <Hixie> | then it sucks |
| 23:18 | <othermaciej> | Philip`: what code do you have in mind? |
| 23:27 | <Philip`> | I don't have anything specific in mind that I'm intending to work on - I'm mostly remembering Canvex and thinking about how I could have done that better |
| 23:29 | <Philip`> | (That's basically lots of scaled drawImages, so I didn't care about the performance of drawing lines and polygons and gradients and things) |
| 23:32 | <zcorpan> | Philip`: you know about elastomania? |
| 23:35 | <Philip`> | zcorpan: No, except for having looked at screenshots of something with that name on Wikipedia about fifteen seconds ago |
| 23:36 | <zcorpan> | Philip`: heh, ok. i was thinking about whether it would be possible to port that to canvas with the exact same physics |
| 23:37 | <zcorpan> | http://video.google.com/videoplay?docid=-669731391958349456&q=elastomania |
| 23:44 | <Philip`> | zcorpan: From what I can see, the 3D bits (rotating rider and (I think) apples) wouldn't really be possible, but I don't see any reason why the rest of it couldn't be reproduced |
| 23:45 | <zcorpan> | oh, nothing is 3d |
| 23:45 | <zcorpan> | and i don't care about the animations |
| 23:46 | <zcorpan> | i was more curious about whether the physics could be reproduced exactly |
| 23:48 | <Philip`> | Oh, they look rather 3Dish |
| 23:48 | <Philip`> | How exactly is "exactly"? |
| 23:49 | <Philip`> | I expect you'd get minor differences just between JS doubles and C floats |
| 23:49 | <zcorpan> | probably |
| 23:51 | <Philip`> | (It'd presumably also be impossible to reproduce fairly accurately without having access to the source code to copy) |
| 23:51 | <zcorpan> | yeah, makes sense. it's not open source |
| 23:52 | <Philip`> | Trying to deduce floating point algorithms from disassembly is usually a bit of a pain :-( |
| 23:55 | <Philip`> | It might not be impossible to work out something that acts similarly, though - it looks kind of like the bikes are just three masses with some damped springs, with collisions between the wheels and some straight lines, and presumably some forces from user input and gravity and friction and air resistance |
| 23:56 | <zcorpan> | no air resistance, but otherwise yeah, something like that |
| 23:57 | <Philip`> | It should just be some maths, and some tweaking of values, and not much else :-) |
| 23:58 | <zcorpan> | but it wouldn't be worth attempting if it would only be possible to get something that acts similarly... |
| 23:59 | <zcorpan> | well, for new players it might be |