| 00:03 | <Philip`> | Hmm, is html5.org dead? |
| 00:06 | <Philip`> | http://canvex.lazyilluminati.com/misc/insertion_modes.svg (red = error transition; blue = non-error reprocess-as-if transition; black = non-error permanent transition) |
| 00:06 | <Philip`> | with only a small number of known bugs in there |
| 00:06 | <Hixie> | i love anne's comment on <canvas>: |
| 00:07 | <Hixie> | "The section should be more clear what it means by image. ..." |
| 00:07 | <Hixie> | which section? |
| 00:07 | <Hixie> | that's how the e-mail starts. which fricking section??? |
| 00:07 | <Philip`> | The canvas section? :-) |
| 00:08 | <Hixie> | that doesn't help much :-P |
| 00:08 | <Hixie> | maybe he means 3.14.11.3. Security with canvas elements |
| 00:08 | <Hixie> | i think i must have fixed this comment already |
| 00:10 | <Hixie> | maybe he means the origin section itself? |
| 00:11 | <Philip`> | (Aha, html5.org is back, hence http://philip.html5.org/misc/insertion-modes.svg ) |
| 00:12 | <Hixie> | safari fails at that image. |
| 00:12 | <Hixie> | hat's red? |
| 00:12 | <Hixie> | parse error? |
| 00:12 | <Hixie> | how abotu blue? |
| 00:12 | <Philip`> | red = error transition; blue = non-error reprocess-as-if transition; black = non-error permanent transition |
| 00:13 | <Hixie> | brb, intermission shift. |
| 00:32 | <Hixie> | Philip`: cool |
| 00:33 | <Hixie> | Philip`: looks like you have some missing. e.g. EOF in a number of the main phase cases |
| 00:33 | <Hixie> | in fact _BeforeHead has only one exiting arrow |
| 00:33 | <Hixie> | which seems unlikely |
| 00:34 | <Philip`> | EOF doesn't explicitly transition to any insertion mode, which is why it isn't shown |
| 00:34 | <Hixie> | ah ok |
| 00:35 | <Philip`> | It might do transitions while generating implied end tags, but those will be a subset of the transitions that are already shown |
| 00:35 | <Hixie> | the transitions for a single character "X" seem wrong |
| 00:35 | <Hixie> | initial phase -> root element -> _beforehead -> ? |
| 00:36 | <Philip`> | ...and it might do transitions when acting as if there were new start/end tags |
| 00:36 | <Hixie> | aaah |
| 00:36 | <Hixie> | you should show those too :-) |
| 00:37 | <Philip`> | In BeforeHead it does some internal magic (like pretending there's a <head>) and then performs the only possible transition to InHead |
| 00:38 | <Hixie> | makes sense |
| 00:38 | <Philip`> | Duplicate the "Start tag [head]" arrow and call it "Character not [...]" etc for each act-as-if-a-start-tag-named-head bit? |
| 00:40 | <Hixie> | or just put an asterisk next to the transitions that happen due to other cases |
| 00:40 | <Hixie> | labelled "* Also happens due to other tokens" or something |
| 00:40 | <Hixie> | or "* May be implied" |
| 00:44 | <Philip`> | http://philip.html5.org/misc/insertion-modes-2.svg handles act-as-if-start-tag |
| 00:46 | <Philip`> | Hmm, stack overflow if I try it with end tags |
| 00:49 | <Philip`> | ...because </p> can create a <p>, and <p> can create a </p> |
| 00:49 | <Philip`> | (in body) |
| 00:51 | <Hixie> | heh |
| 00:59 | <Philip`> | http://philip.html5.org/misc/insertion-modes-3.svg handles act-as-if-(start|end)-tag |
| 00:59 | <Philip`> | and is getting a little ugly :-( |
| 01:00 | <Philip`> | (It's intentional that <noscript> isn't handled, because I haven't translated that bit yet) |
| 01:01 | <Hixie> | i think my asterisk idea wins :-P |
| 01:02 | <Hixie> | found any errors in the spec yet? :-D |
| 01:02 | <othermaciej> | so the "please don't dereference these http URIs" post from the w3c made it to reddit |
| 01:02 | <Philip`> | If I added asterisks, I'd have to add some way to delete duplicates, and that would require lines of code :-( |
| 01:02 | <othermaciej> | I am amazed how many people support the concept of using http URIs as opaque identifiers not meant to be dereferenced |
| 01:02 | <Hixie> | i think we clearly should learn from this that using URIs for things that are opaque identifiers not meant to be dereferenced is dumb |
| 01:02 | <othermaciej> | barely a moment's thought given to whether that might be a dumb idea in the first place |
| 01:03 | <Hixie> | Philip`: heh |
| 01:04 | <Philip`> | You can just look at http://philip.html5.org/misc/insertion-modes.svg and imagine a "..., or may be implied" beside each transition |
| 01:07 | <Philip`> | Hixie: There's a few things that don't entirely seem sensible in there (so I've sent mail to public-html), but I haven't tried looking hard for errors yet :-) |
| 01:08 | Philip` | wants to create hundreds of thousands of test cases to see if all the parsers interoperate |
| 01:09 | <Hixie> | k |
| 01:17 | <tantek> | FWIW I'm quite firmly on the other side re: http URIs, in strong support of dereferenceable URLs (not a typo), e.g. for XMDP profiles. |
| 01:18 | <othermaciej> | a dereferencable URL for something meant to be dereferenced is fine |
| 01:18 | <othermaciej> | but an allegedly opaque identifier starting with "http:" and having the format of a URL is just dumb |
| 01:19 | <tantek> | IMHO a URI using the "http" protocol implies dereferencability. |
| 01:21 | <othermaciej> | that's certainly how it seems to most people |
| 01:22 | <Dashiva> | Any transfer protocol would be an odd choice for non-transfer, really |
| 01:24 | <Philip`> | <html xmlns="data:,w3.org XHTML"> - still a URI, still uses DNS for 'guaranteed' uniqueness and allows many distinct values for the same domain |
| 01:24 | <tantek> | agreed Dashiva. Any URI using a transfer protocol implies dereferenceability, and specs SHOULD NOT discourage dereferenceability of such URIs. |
| 01:25 | <tantek> | in fact, one might even say that specs which use URIs MUST NOT place additional such restrictions on the URIs, as that would be a layer violation. |
| 03:58 | <jruderman> | will <video> work well for streaming formats? |
| 03:58 | <jruderman> | such as real-time porn cams |
| 09:09 | <hsivonen> | the idea of using URIs as identifiers rather than locators ignores the main affordance of URIs |
| 09:10 | <hsivonen> | in that sense, we should have stayed with URLs and the URI thing was a mistake |
| 12:36 | <annevk> | Philip`, is your parser faster than the Java parser? |
| 12:37 | <Philip`> | annevk: My C++ tokeniser was faster than the Java tokeniser (at least in the particular case that I was testing) |
| 12:38 | <annevk> | you haven't converted the OCaml parser to C++ yet? |
| 12:40 | <Philip`> | No, and the tree constructor part doesn't quite work in OCaml yet either |
| 12:43 | <annevk> | k |
| 13:52 | <zcorpan_> | http://www.sitepoint.com/forums/showthread.php?t=531009 |
| 15:01 | met_ | just testing postMessage http://ejohn.org/apps/message/ |
| 15:01 | <gsnedders> | the spec gen truly is bizarre. |
| 15:01 | <met_> | anyone knows why it doesn't work in opera? |
| 15:01 | met_ | thougt Opera implemented postMessage already |
| 15:04 | <annevk> | Opera implemented it on document instead of window |
| 15:04 | <met_> | oh |
| 15:04 | <annevk> | (this is changing) |
| 15:04 | <met_> | ok, I have missed thaht |
| 15:16 | <gsnedders> | Hixie: playing around with various concepts I have for implementing the spec-gen clone, it's gonna be quick. really quick. |
| 15:16 | <gsnedders> | (and by playing around I mean playing around with a DOM tree of the HTML 5 spec, so a really large doc) |
| 15:58 | <annevk> | Hixie, in http://lists.w3.org/Archives/Public/www-archive/2008Jan/0078.html you said you changed test 43 but it seems that you did not do that |
| 19:23 | <Hixie> | annevk: as far as i can tell i did; what's not fixed? |
| 19:27 | <Philip`> | Hmm... Opera has a feature to import bookmarks from Firefox |
| 19:28 | <Philip`> | Firefox 3 stores bookmarks in an SQLite database |
| 19:28 | <Philip`> | Hence, Opera will have to include SQLite so that it can continue to import from Firefox |
| 19:28 | D2xSadEagle | can't say he blames FF people for using something like SQLite. |
| 19:28 | <D2xSadEagle> | though don't they always run only one process? Cheaters :p |
| 19:29 | <Philip`> | Since it already has to pay the code-size and integration cost of SQLite, it will cost approximately nothing extra to support client-side database storage in a way that's compatible with Firefox |
| 19:29 | <Philip`> | And so the world will be happy and interoperable, which is good |
| 19:30 | <Hixie> | it frightens me that Julian is arguing that servers don't assume that a missing Referer means that the request should be allowed |
| 19:30 | <Philip`> | (And any other browser that wants to attract Firefox users will have to offer a similar import feature, and so will have to have SQLite too) |
| 19:31 | <Dashiva> | Philip`: Well, that all assumes FF3 will be released before DNF :) |
| 19:32 | Hixie | wonders how to respond to someone who has such a feeble grasp of the realities of deployed content |
| 19:33 | <Philip`> | Hixie: If they do assume that, it should be easy to give some examples of open source code with that assumption |
| 19:34 | <Philip`> | It seems the much more common situation (mainly to avoid image hot-linking) is for servers to assume a non-missing different-origin Referer means the request should be denied |
| 19:34 | <Philip`> | (which isn't the same as assuming a missing Referer means the request should be trusted) |
| 19:35 | <Hixie> | right |
| 19:35 | <Philip`> | (because nothing particularly bad happens when someone hot-links an image and 1% of users don't send Referer and therefore don't get redirected to a rude message) |
| 19:36 | <Hixie> | feel free to point him to code doing this if you know of any |
| 19:36 | <Philip`> | I don't know of any |
| 19:36 | <Hixie> | yeah me either |
| 19:36 | <Hixie> | i just know it's very common :-) |
| 19:36 | <Philip`> | You're the one arguing that servers do make assumptions :-p |
| 19:37 | <hsivonen> | b.m.o at least used to block slashdot referers but allows no referer |
| 19:37 | <Philip`> | and arguing without evidence is not very convincing :-) |
| 19:37 | <webben> | What does Apache do by default? |
| 19:37 | <hsivonen> | webben: just logs the referer |
| 19:38 | <webben> | IIS? |
| 19:38 | <Hixie> | Philip`: indeed |
| 19:38 | <Dashiva> | Philip`: My image leech prevention script assumes a missing referer is local |
| 19:38 | <Hixie> | guess i'll have to do more research |
| 19:38 | <Dashiva> | It's not open source, though |
| 19:39 | <Hixie> | time to go to the rehearsal though |
| 19:39 | <Hixie> | bbl |
| 19:39 | <Philip`> | hsivonen: b.m.o isn't blocking certain referrers in order to avoid CSRF, so it's not really relevant to the argument about no-referrer pings being bad for security |
| 19:39 | <Philip`> | and the same for all the image leech prevention scripts |
| 19:40 | <hsivonen> | Philip`: using Referer for security purposes seems like a very brittle and RFC 2616-incompliant idea to me |
| 19:41 | <Philip`> | hsivonen: If we assumed people were sensible, then that would mean people wouldn't use Referer for security purposes, and so there's no danger in sending pings with no Referer |
| 19:42 | <hsivonen> | which one of Julian's messages are we talking about? |
| 19:42 | <Philip`> | I think the first paragraph of http://lists.w3.org/Archives/Public/public-html/2008Feb/0164.html |
| 19:49 | <Philip`> | http://google.com/codesearch?q=show:J2QBLfV3jjo:NRV5Vj3R4SI:1curwdNzfbk&cs_p=ftp://t3domains.de/pub/TYPO3-complete-package/current-version/yamlt3-V4.5.0.zip&cs_f=yamlt3/typo3/sysext/cms/tslib/class.tslib_fe.php#l2106 |
| 19:49 | <hsivonen> | hmm. using Referer as an anti-CSRF mechanism still seems like a very bad idea unless it is merely used as an optimization in a mechanism that actuallly works |
| 19:49 | <Philip`> | That's something that prevents email form submission if the Referer is wrong or missing |
| 19:53 | <tndH> | Philip`: lucky for them, fx3 exports its bookmarks to an html file on shutdown ;) |
| 19:55 | <Philip`> | http://google.com/codesearch?q=show:H3ulLINfCo0:QkWYPi2-xVM:o8NYFfBdVkY&cs_p=http://freshmeat.net/redir/punbb/46741/url_tgz/punbb-1.2.15.tar.gz&cs_f=punbb-1.2.15/upload/include/functions.php#l671 |
| 19:55 | <Philip`> | That also prevents things if Referer is wrong or missing |
| 20:00 | <Philip`> | http://google.com/codesearch?q=show:BILmTBaOV7w:J2LE5gqHQ64:eBTzqE7cT8s&cs_p=http://wphooks.flatearth.org&cs_f=hooks/check_admin_referer/-001#first |
| 20:00 | <Philip`> | There's another one |
| 20:00 | <Philip`> | So I still haven't seen one that thinks missing referer means the request can be trusted... |
| 20:03 | <Philip`> | tndH: Oh :-( |
| 20:04 | <Philip`> | http://google.com/codesearch?q=show:cFRMv4O2bGI:eriQ8VkTUd4:dQQ6OTNA-Bs&cs_p=https://svn.radicaldesigns.org/amp/trunk&cs_f=punbb/admin_options.php#l41 |
| 20:04 | <Philip`> | That also rejects missing referer |
| 20:06 | <Philip`> | http://google.com/codesearch?q=show:2v0x4p249hg:NM4BWguMEFY:lqNJFi-SHlc&cs_p=http://scoop.kuro5hin.org/dist/releases/scoop_1.1.7.tar.gz&cs_f=scoop-1.1.7/lib/Scoop/Admin.pm#l8 |
| 20:12 | <Philip`> | http://google.com/codesearch?q=show:aVoQhiwqoGk:-V6ZnWGm9lc:vBMeJnZMb1M&cs_p=http://www.dcscripts.com/localFTP/gdcf625.tar.gz&cs_f=./dcf625/cgi-bin/dcforum/dcboard.cgi#l344 |
| 20:13 | Philip` | gives up looking |
| 20:13 | <Philip`> | So, I still don't have any evidence that sending requests with a missing Referer is going to introduce security issues in existing software |
| 20:14 | <Philip`> | (though obviously I also don't have any evidence that it isn't) |
| 20:17 | <Philip`> | hsivonen: Do you know of some specific anti-CSRF mechanisms that do work? |
| 20:18 | Philip` | is currently unable to think of any |
| 20:21 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3Evar%20xhr%3Dnew%20XMLHttpRequest()%3Bxhr.open(%27GET%27%2C%20%27https%3A%2F%2Fmail.google.com%2Fmail%2F%3Flogout%26hl%3Den-GB%27)%3Bxhr.send(null)%3C%2Fscript%3E |
| 20:21 | <Philip`> | In Firefox 3, that doesn't work very happily |
| 20:22 | <Philip`> | presumably because of the Access-Control stuff introducing new CSRF vulnerabilities |
| 20:23 | <Philip`> | annevk: Is that a known problem or a bug in Firefox or something? |
| 20:25 | <Philip`> | Oh, maybe not |
| 20:25 | <Philip`> | It's not anything new, because <script src="https://mail.google.com/mail/?logout&hl=en-GB"></script>; has the same effect |
| 20:25 | <Philip`> | Is it a bug in Gmail, or is the web just fundamentally broken? |
| 20:25 | <zcorpan_> | hsivonen: apparently some people use transitional because the software they use emit stuff that only validates as transitional |
| 20:27 | <zcorpan_> | hsivonen: and so it might be worth to look into the default templates of popular CMSs and blogs and which errors they get when validating as html5 |
| 20:27 | <zcorpan_> | (but i guess the results would be pretty much the same as what you've already got) |
| 20:27 | <hsivonen> | zcorpan_: good idea |
| 20:28 | <hsivonen> | zcorpan_: altough the generated stuff in CMSs is harder to change than the templates, so it would be even more interesting to isolate the template parts somehow |
| 20:29 | <zcorpan_> | yeah |
| 20:34 | <hsivonen> | I see <a name> and target=_blank in what I think is the Blogger default |
| 20:35 | <hsivonen> | additionally, the blogger navbar has every presentational iframe attribute |
| 20:35 | <zcorpan_> | "SMF and WordPress both output target="_blank"." -- http://www.sitepoint.com/forums/showthread.php?p=3718885 |
| 20:36 | <hsivonen> | what's SMF? |
| 20:36 | <zcorpan_> | probably http://www.simplemachines.org/ |
| 20:36 | <hsivonen> | never heard |
| 20:37 | <zcorpan_> | i hadn't, either |
| 20:37 | <Philip`> | SMF seems to be fairly popular |
| 20:37 | <Philip`> | https://labs.mozilla.com/forum/ uses it |
| 20:40 | <hsivonen> | Can't validate that one with Validator.nu |
| 20:40 | <hsivonen> | the SSL cert is not supported by Sun JDK |
| 20:42 | <Philip`> | http://html5.validator.nu/?doc=http%3A%2F%2Fwww.simplemachines.org%2Fcommunity%2Findex.php looks unhappy |
| 20:42 | <hsivonen> | zcorpan_: WordPress default has profile at least: http://html5.validator.nu/?doc=http%3A%2F%2Fthemes.wordpress.net%2Ftestrun%2F |
| 20:43 | <Philip`> | and http://html5.validator.nu/?doc=http://www.cyberscoreforums.com/ (SMF 1.x, whereas the other one was 2.x) looks similar |
| 20:43 | <hsivonen> | ah. language="JavaScript" all over the place |
| 20:50 | <hsivonen> | Sun's certificate management docs aren't as obvious as I'd like :-( |
| 20:53 | <hsivonen> | I wonder if there's a way to ask HttpClient to accept any cert and only use TLS for encryption--not for verifying the idintity of the other party |
| 20:53 | <zcorpan_> | <link rel="help" href="http://www.cyberscoreforums.com/index.php?action=help"; target="_blank" /> (from cyberscoreforums.com) |
| 21:32 | <zcorpan_> | wonder if we should allow <img with=0 height=0> |
| 21:32 | <zcorpan_> | er |
| 21:32 | <zcorpan_> | width |
| 21:37 | <annevk> | Philip`, Google doing actions on the user's behalf based on a GET request seems to be broken |
| 21:40 | <gsnedders> | annevk: seeming you said you'd explain to me anything I didn't get from the DOM specs, what does compareDocumentPosition() return? |
| 21:40 | <Philip`> | I suppose doing actions on a POST request would be broken too, because anyone could set up a form and submit it via JS |
| 21:41 | <Philip`> | so it's basically impossible to safely allow actions |
| 21:41 | <SadEagle> | gsnedders: it's an untranslatable string of curses in the direction of whoever thought up of this function |
| 21:41 | <gsnedders> | :D |
| 21:41 | <SadEagle> | Philip`: check out some stuff in http rfc about pipelining and idempotency, for extra fun. |
| 21:41 | <gsnedders> | at a really basic level, how can I tell if something occurs before something else? |
| 21:42 | <annevk> | yes |
| 21:42 | <annevk> | though not all browsers might support it |
| 21:43 | <annevk> | also, iirc it returns an integer that maps to some constant |
| 21:43 | <gsnedders> | oh yuk. |
| 21:43 | <SadEagle> | hmm, it's actually not so expensive to implement as I first thought. |
| 21:43 | <kig> | the usual solution to ajax api is to trust the browser to not leak cookies outside SOP and use the cookie secret for authenticating requests by adding the secret as a var to the post req |
| 21:43 | <SadEagle> | gsnedders: this seems to explain it: http://www.quirksmode.org/blog/archives/2006/01/contains_for_mo.html |
| 21:44 | <gsnedders> | SadEagle: thx |
| 21:44 | <kig> | s/usual/what i've been using/ |
| 21:45 | <SadEagle> | np |
| 21:45 | <SadEagle> | there is a separate section in DOM3 core explaining it too, just search for DocumentPosition... For some reason the method specs don't refer to it.. |
| 21:46 | <gsnedders> | that'll be why I didn't find it. |
| 21:46 | SadEagle | loves DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC |
| 21:46 | <gsnedders> | yeah, I just noticed that |
| 21:46 | <Philip`> | kig: Hmm, that sounds quite reasonable |
| 21:46 | <gsnedders> | SadEagle: sadly, too often order isn't defined in DOM |
| 21:48 | <SadEagle> | they have a disconnected flag, though |
| 21:48 | <annevk> | wow, someone should clean that up and remove that constant |
| 21:49 | <gsnedders> | DOM5! |
| 21:49 | <gsnedders> | next year of school will suck. No longer in Secondary 5 :( |
| 21:51 | <zcorpan_> | dom5 core is on my list of things to do... |
| 21:51 | <annevk> | Hixie, "input2.setAttribute("checked", "checked"); // sets defaultChecked, doesn't change actual state" does change the state in deployed browsers |
| 21:51 | <gsnedders> | zcorpan_: you can use me a test subject as someone who doesn't know much about DOM :P |
| 21:52 | <zcorpan_> | gsnedders: i don't follow |
| 21:53 | <gsnedders> | zcorpan_: To make sure DOM5 Core actually makes sense to those who don't know much about DOM |
| 21:53 | <zcorpan_> | gsnedders: ah |
| 21:53 | <zcorpan_> | gsnedders: not sure that should be a goal though |
| 21:53 | <SadEagle> | gsnedders: coincidentally, DOM* Core is probably the best-specified part of DOM. |
| 21:54 | <gsnedders> | SadEagle: I'm aware. |
| 21:54 | <Hixie> | annevk: oh, in the radio button tests. i thought you were talking about the checkbox tests. |
| 21:55 | SadEagle | wonders whether someone will be tackling saneification of DOM2 HTML... I guess some parts of WF2 overlap, though. |
| 21:55 | <gsnedders> | SadEagle: HTML 5 is, AFAIK |
| 21:55 | <zcorpan_> | yeah |
| 21:55 | <SadEagle> | poor Hixie :-) |
| 21:57 | <Hixie> | annevk: wow, that's a big bug in the spec. i'd better make sure i fix that in html5. |
| 21:58 | <annevk> | i doubt that's possible |
| 21:59 | <annevk> | HTML5 fixed most of DOM2 HTML |
| 21:59 | <Hixie> | i mean a big bug in the dom2 html spec |
| 22:00 | <annevk> | ok |
| 22:00 | <Hixie> | i haven't checked wf2 |
| 22:00 | Hixie | mails himself |
| 22:07 | <Hixie> | annevk: k, fixed the test |
| 22:09 | <annevk> | how can input1 still be checked? |
| 22:10 | <annevk> | .defaultChecked is exactly equivalent to setAttribute("checked", "checked") ... |
| 22:10 | <annevk> | or did you change other things, too? |
| 22:11 | <Hixie> | wait i thought you said that setting setAttribute("checked", "checked") was specifically _not_ equivalent to setting defaultChecked? |
| 22:11 | <Hixie> | so you're saying that setting defaultChecked also changes checked??? |
| 22:12 | <annevk> | yes |
| 22:12 | <annevk> | sorry for not being more specific initially |
| 22:13 | <annevk> | maybe I'm wrong |
| 22:16 | <Dashiva> | Wouldn't it be nice if there was a website that would screenshot a given page in IE6+7, FF2+3, Safari2+3 and Opera9.2+9.5 and display the results? |
| 22:16 | Hixie | puts it back to what it used to be |
| 22:16 | <Hixie> | Dashiva: there is |
| 22:16 | <Dashiva> | really? |
| 22:16 | <Dashiva> | And not a paid service? |
| 22:16 | <Hixie> | yes |
| 22:16 | <Hixie> | i forget the url |
| 22:16 | <Hixie> | but there are some |
| 22:16 | <Dashiva> | Hmm... guess it's google time |
| 22:17 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3Ex%3Cinput%20name%3Dradio%20type%3Dradio%3E%3Cinput%20name%3Dradio%20type%3Dradio%3E%3Cscript%3Evar%20i%20%3D%20document.getElementsByTagName(%22input%22)%3B%20i[0].defaultChecked%20%3D%20true%3B%20i[1].defaultChecked%20%3D%20true%20%3C%2Fscript%3E |
| 22:17 | <annevk> | Firefox seems inconsistent |
| 22:18 | <Hixie> | well i've put it back to what the spec says |
| 22:18 | <annevk> | but given how inconsistent Firefox is I'm not sure we can fix it |
| 22:22 | <Philip`> | Dashiva: http://browsershots.org/ ? |
| 22:22 | <Dashiva> | Yeah, looking at that now |
| 22:43 | <annevk> | Hixie, because of "iframe { float: left; height: 0; width: 0; }" some of the media query tests are invalid |
| 22:43 | <annevk> | specifically, y1, y2, y3, and y4 will not function as expected |
| 22:43 | <annevk> | (if I uncomment that CSS line the media query tests pass in Opera as expected) |
| 22:46 | <Hixie> | oh the media queries depend on the iframe dimensions? |
| 22:47 | <annevk> | y1, y2, y3, y4 test the width and height media features |
| 22:47 | <Hixie> | yes |
| 22:47 | <Hixie> | i didn't realise that those heights and widths were the viewport dimensions |
| 22:47 | <Hixie> | of the inner viewport |
| 22:48 | <annevk> | they are |
| 22:48 | <Hixie> | but indeed it is |
| 22:48 | <annevk> | you could change them to min-device-width etc. I suppose |
| 22:48 | <Hixie> | fixed |
| 22:50 | <Hixie> | there, let me know if that works |
| 22:50 | <annevk> | that works, but you should update the comment to say that the tests assume a 0x0 window |
| 22:50 | <annevk> | "// the next four assume that the window is bigger than 1em by 1em at the time the test is run" |
| 22:51 | <Hixie> | fixed |
| 22:51 | <annevk> | great |
| 22:52 | <Hixie> | that broke safari |
| 22:52 | <annevk> | bonus points |
| 22:52 | <annevk> | ;) |
| 22:54 | <salty-horse> | this may be old news. graphviz over canvas: http://www.ryandesign.com/canviz/ |
| 22:56 | Philip` | hadn't seen that before |
| 22:56 | <Philip`> | Looks like it works well :-) |
| 22:57 | <Philip`> | Is it possible for someone to enter their own dot files? |
| 22:58 | <salty-horse> | I just saw this link on graphviz.org :) |
| 23:03 | Philip` | fails to find any information about it other than https://mailman.research.att.com/pipermail/graphviz-interest/2007q3/004709.html |
| 23:05 | <Hixie> | Philip`: you've tested <canvas> the most, do you know if it's the case today that all <canvas> implementations create backing stores the same dimensions as the coordinate space? |
| 23:07 | <salty-horse> | Philip`, since the graphviz xdot output parsing is on the client-side, you already have all of the source code :) |
| 23:08 | <Philip`> | Hixie: I think WebKit might use a different scale if you some secret hidden OS X feature to change the UI scaling factor or something like that, but I've never tried that myself |
| 23:08 | <Philip`> | s/ / use / |
| 23:08 | <Hixie> | but other than that, they all just use the coordinate space? |
| 23:09 | <Hixie> | so if i have <canvas height=1 width=1> and canvas { height: 100%; width: 100%; } they all screw it up? |
| 23:09 | <annevk> | Firefox and Opera "do" |
| 23:10 | <Philip`> | The internal buffer is always independent of the size rendered on the screen |
| 23:10 | <annevk> | although in that case it's debatable what should happen as CSS stuff is just resizing after all the <canvas> stuff happened |
| 23:10 | <Philip`> | It wouldn't really make sense otherwise, given that you can change the rendered size easily |
| 23:10 | <Hixie> | i'm not saying the css stuff should control the buffer size |
| 23:10 | <Philip`> | (like by resizing the window if it's width:100%) |
| 23:10 | <Hixie> | i'm just asking if that would always make a 1x1 buffer |
| 23:11 | <Philip`> | I think in WebKit it would be (1*UI scaling factor)x(1*UI scaling factor), where UI scaling factor = 1 unless you're using developer tools to change it |
| 23:12 | <Hixie> | k |
| 23:12 | <Philip`> | (but I could be wrong :-) ) |
| 23:12 | <Hixie> | that seems sad |
| 23:12 | <roc> | we're always 1:1 |
| 23:12 | <Philip`> | Why? |
| 23:13 | <roc> | changing that would be pretty easy, but someone has to think about dynamic DPI changes |
| 23:13 | <Philip`> | s/^/Hixie: / |
| 23:14 | <Hixie> | Philip`: because it means that i can't pick a convenient coordinate space |
| 23:15 | <Philip`> | Not quite sure what you mean |
| 23:15 | <Hixie> | Philip`: i have to think about what my biggest likely rendering size (in terms of css pixels) will be |
| 23:15 | <Hixie> | instead of just saying "well i'll just work in the range 0..1" |
| 23:16 | <Philip`> | ctx.scale(canvas.width, canvas.height) would let you work in the range 0..1 |
| 23:16 | <Hixie> | true |
| 23:17 | <roc> | Hixie: someone has to think about that. The browser can't really know. |
| 23:17 | <Hixie> | the browser could just use big abcking stores |
| 23:18 | <roc> | if it didn't care about performance |
| 23:18 | <Hixie> | right |
| 23:18 | <roc> | it turns out we do care about performance |
| 23:18 | <Hixie> | that's a tradeoff each browser vendor can make |
| 23:18 | <annevk> | if the author wants hires they should just use a huge <canvas> |
| 23:18 | <annevk> | imo |
| 23:18 | <roc> | it's useful to be able to get information from authors. Some authors care about performance too |
| 23:19 | <annevk> | and then scale using CSS |
| 23:19 | <Philip`> | Do any authors not care about performance? |
| 23:20 | <Philip`> | <canvas> is always going to be slow, because people want hi-res full-screen canvases with millions of pixels, so performance is unlikely to ever become irrelevant |
| 23:23 | Philip` | likes to think of <canvas> as dynamic <img>, where you just say it's got w*h pixels and you can stick colour values in them, and tries not to think of <img src=x.svg> which breaks that model |
| 23:24 | <Philip`> | and anything more complex makes my head hurt |
