| 00:25 | <variable> | The One Page Principle: A specification that will not fit on one page of 8.5x11 inch paper\ cannot be understood. -- Mark Ardis |
| 00:25 | <variable> | :-| |
| 00:26 | <Philip`> | And a specification that will fit cannot be interoperably implemented |
| 00:26 | <Philip`> | Understanding is overrated |
| 00:27 | <Dashiva> | You don't need to understand the spec, just pieces of it big enough to make a test suite |
| 00:27 | <jcranmer> | a specification that fits on one page of 8.5x11 inch paper was written by an academic who has no concept of what the real world actually looks like |
| 00:28 | <jcranmer> | writing the specification for a language implemented by a ~800-line parser (including internal documentation comments and whitespace) is 3 pages long |
| 00:29 | <variable> | jcranmer, as a corollary of Mark Ardis and you: no real world spec could ever be understood |
| 00:29 | <Rik`> | I think we can conclude that the real world cannot be understood |
| 00:29 | <variable> | I just mentioned it cause it came on fortune ;) |
| 00:29 | <Dashiva> | We could just conclude that Mark Ardis is wrong |
| 00:30 | <Dashiva> | Or we can correctly state that he doesn't specify a minimum font size |
| 00:30 | <Dashiva> | Even HTML5 fits on one page if you make the font small enough! |
| 00:31 | <variable> | Dashiva, true, true |
| 00:32 | <Dashiva> | I've had exams where we were allowed to bring notes, one allowed a single page and another a single index card. The page case specified minimum 10px font, the index card "big enough that the teacher can read it without a magnifying lens" |
| 00:33 | <variable> | Dashiva, hillarious. Neither specifies the max size of the paper |
| 00:33 | <variable> | or the font itself |
| 00:33 | <variable> | I could create a font where 9px is tiny |
| 00:33 | <Dashiva> | It was A4 paper and 5x3 index card |
| 00:34 | <variable> | too bad |
| 00:34 | <Dashiva> | They were handed out beforehand. The paper because it had letterhead, and the index card for no particular reason |
| 00:35 | <variable> | Dashiva, what class was this for? |
| 00:36 | <Dashiva> | One was parallel systems and programming, the other was modern history |
| 00:38 | <jcranmer> | Dashiva: that's gotta suck for me |
| 00:38 | <jcranmer> | I can read my own notes without magnifying lens |
| 00:38 | <jcranmer> | but many people would have problems doing the same |
| 00:38 | <jcranmer> | to put it another way |
| 00:39 | <jcranmer> | I squished a 7x7 matrix in 2x2 of quadrille-ruled notebook paper |
| 00:40 | <Dashiva> | Well, you could... write bigger |
| 00:40 | <jcranmer> | ... |
| 00:41 | <jcranmer> | I've tried |
| 00:41 | <jcranmer> | I generally fail |
| 00:41 | <Dashiva> | You could ask someone else to write for you :) |
| 01:21 | Philip` | tends to write small too |
| 01:21 | <Philip`> | I currently have 28 shopping lists on an A8 piece of paper |
| 01:21 | <Philip`> | (Not extremely long lists, admittedly) |
| 08:53 | <myakura> | βAt this time we do not plan on fixing this issue.β :( https://connect.microsoft.com/IE/feedback/details/577604/borders-on-iframe-cannot-be-styled-via-css |
| 08:53 | <myakura> | same markup fails :( |
| 09:00 | <Hixie> | myakura: i thought microsoft had committed to fixing every bug? |
| 09:01 | <Hixie> | didn't they say that in a recent blog post? |
| 09:01 | <hsivonen> | Does DOM Range have an active editor? |
| 09:02 | <hsivonen> | Range doesn't have a component in the W3C Bugzilla :-( |
| 09:02 | <Hixie> | it does not |
| 09:02 | <Hixie> | i'm collecting feedback though if you have a bug to report |
| 09:02 | <Hixie> | ("the spec is woefully underdefined" is a known bug) |
| 09:02 | <hsivonen> | Hixie: collecting via what mechanism? |
| 09:02 | <Hixie> | same as the whatwg mail |
| 09:03 | <Hixie> | my imap folders |
| 09:03 | <hsivonen> | Hixie: should I send the email to whatwg, webapps or www-dom? |
| 09:03 | <Hixie> | public-web-apps or www-dom is probably best, cc me |
| 09:03 | <hsivonen> | ok thanks |
| 09:05 | <Hixie> | np |
| 09:05 | <Hixie> | dunno what i'll do with the feedback |
| 09:06 | <Hixie> | if no editors come along i might just rewrite it miself |
| 09:06 | <Hixie> | myself even |
| 09:17 | <annevk> | hsivonen, Hixie, DOM Range is http://bitbucket.org/ms2ger/dom-range |
| 09:17 | <annevk> | ms2ger = awesome |
| 09:17 | <annevk> | (though it's quite incomplete still, but comes with some tests) |
| 09:17 | <Hixie> | how do i view it? |
| 09:18 | <Hixie> | if ms2ger wants to do that, i should send him the messages i've collected |
| 09:18 | <annevk> | http://bitbucket.org/ms2ger/dom-range/raw/tip/source.html |
| 09:19 | <annevk> | (in Opera you can open it somewhat directly if you configure it correctly; haven't figured out a way yet to just view the file) |
| 09:19 | <hsivonen> | awesomeness. |
| 09:20 | <hsivonen> | ms2ger: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0703.html |
| 09:20 | <annevk> | Hixie, btw, I'm going to fix DOM Core and will do it in such a way that you can remove a bunch of stuff from HTML5 |
| 09:20 | <Hixie> | hm, not much there yet |
| 09:20 | <Hixie> | annevk: oh? |
| 09:20 | <annevk> | DOM Core is http://bitbucket.org/ms2ger/web-dom-core (has a bunch more) |
| 09:21 | <annevk> | (about 80% done \o/) |
| 09:21 | <zcorpan_> | annevk: and 80% left to do? :) |
| 09:21 | <Hixie> | annevk: kill Attr |
| 09:22 | <hsivonen> | annevk: regarding getElementsByTagName(), is there any reason not to use localName except theoretical deliberate impurity of Level 1? |
| 09:23 | <annevk> | zcorpan_, exactly |
| 09:23 | hsivonen | hasn't read the latest draft, just annevk's IRC remarks |
| 09:23 | <Hixie> | "The nodeName, nodeValue and nodeType attributes must, on getting, return what is in the second, third and fourth column, respectively, if the node also implements the interface in the first column on the same row in the following table" is a very confused sentence |
| 09:24 | <annevk> | hsivonen, setAttribute, getAttribute, hasAttribute all use qualified name |
| 09:24 | <Hixie> | annevk: is the HTMLCollection stuff up to date? |
| 09:24 | <Hixie> | seems weird for DOM Core to define things that depend on HTML elements |
| 09:25 | <Hixie> | oh, i see, .children |
| 09:25 | <annevk> | Hixie, since we only talk about namespaces and type of documents I think it is okay |
| 09:25 | <Hixie> | well that's fun |
| 09:25 | <hsivonen> | annevk: why does that need to generalize to getElementsByTagName? |
| 09:25 | <annevk> | there's no HTML dependency |
| 09:25 | <hsivonen> | annevk: using localName would be good for code simplicity and perf |
| 09:26 | <annevk> | hsivonen, you do not store the qualifiedName internally? |
| 09:26 | Hixie | suggests again removing Attr forever |
| 09:26 | <hsivonen> | annevk: there's no HTML dependency if you make getElementsByTagName match localName and wildcard namespace |
| 09:26 | <annevk> | Hixie, you mean making it no longer inherit from Node? |
| 09:26 | <hsivonen> | annevk: IIRC, we don't |
| 09:27 | <Hixie> | annevk: no, i mean, not having it in the platform |
| 09:27 | <Hixie> | annevk: not supported |
| 09:27 | <Hixie> | annevk: gone |
| 09:27 | <Hixie> | annevk: unimplemented |
| 09:27 | <Hixie> | annevk: no longer in the global namespace |
| 09:27 | <annevk> | how would .attributes work? |
| 09:27 | <Hixie> | drop that too |
| 09:28 | <annevk> | don't sites rely on that? |
| 09:28 | <Hixie> | not to my knowledge |
| 09:28 | <Hixie> | if they do, find out what they actually rely on |
| 09:28 | <Hixie> | and just provide the minimum API to support that |
| 09:29 | <annevk> | chrome has these statistic collection thingies right? maybe someone can figure it out |
| 09:29 | <annevk> | hmm |
| 09:29 | <annevk> | would certainly be nice |
| 09:30 | <annevk> | hsivonen, you still need to lowercase the argument for HTML nodes |
| 09:32 | <hsivonen> | annevk: good point |
| 09:33 | <hsivonen> | so DOM Core has to know about the HTML namespace and the HTMLness bit |
| 09:33 | <annevk> | it already does |
| 09:33 | <hsivonen> | annevk: anyway, I think CSS element selector gets this right |
| 09:33 | <hsivonen> | would be nice if the DOM did, too |
| 09:34 | jgraham | relies on .attributes |
| 09:34 | jgraham | goes to read the backscroll |
| 09:34 | <annevk> | so either ele.namespaceURI == HTMLNS && ele.localName == localName.toLowerCase() or ele.localName == localName |
| 09:35 | <annevk> | or do we want this just for HTML documents also? |
| 09:40 | <zcorpan_> | annevk: just check localName |
| 09:40 | <zcorpan_> | though it might be too late to change it |
| 09:40 | <hsivonen> | annevk: opinion differs between reasonable people on the "HTML documents" part |
| 09:41 | <hsivonen> | annevk: depends on how much you are willing to tear down XML architecture in order to unify it with the HTML side |
| 09:43 | <annevk> | well, XML means namespaces in my book, so no "DOM1Core methods", but I do not really care |
| 09:43 | <annevk> | i added a note about changing it back |
| 09:44 | <hsivonen> | annevk: considering the problem holistically includes deciding if Selectors should always be ASCII-case-insensitive when matching on XHTML-namespace nodes even in XML docs |
| 09:45 | <jgraham> | "TLS server side implementers seem to be a little challenged [...] I very much hope WS implementers can do a better job" β how far we have come from "Amateur Programmers" |
| 09:45 | <annevk> | hsivonen, I would have no problem with that |
| 09:46 | <hsivonen> | now constituencies that are supposed to rank higher than theoretical purity need to remember to use lower case only in user style sheets and UA style sheet supplements (in browser extensions) |
| 09:46 | <hsivonen> | jgraham: I initially read WS as WS-*. |
| 09:46 | <annevk> | jgraham, yeah, wtf |
| 09:46 | <annevk> | better job than TLS |
| 09:46 | <annevk> | lolz |
| 09:50 | <Workshiva> | hsivonen: Maybe one day people won't remember WS-* |
| 09:52 | <Hixie> | hsivonen: tag names and attributes in Selectors should not match case-insensitively in XML |
| 09:53 | <Hixie> | hsivonen: they only match case-insensitively in HTML because the parser on the HTML side is itself doing case-folding |
| 09:57 | <annevk> | Hixie, they could match case-insensitively for nodes in the HTML namespace regardless of the type of the Document |
| 09:57 | <annevk> | Hixie, that is much closer to how things work in implementations (except the case-insensitve is also guarded by a isHTMLDocument check) |
| 09:58 | <Hixie> | well, hold on |
| 09:58 | <Hixie> | depends what you mean by case-insensitively, i guess |
| 09:58 | <Hixie> | do you want A {} to match <A xmlns="http://www.w3.org/1999/xhtml"/>; ? |
| 09:58 | <Hixie> | er |
| 09:58 | <Hixie> | do you want a {} to match <A xmlns="http://www.w3.org/1999/xhtml"/>; ? |
| 09:58 | <annevk> | no |
| 09:58 | <annevk> | neither would match, in fact, with these rules |
| 09:58 | <Hixie> | well you want the first to match |
| 09:59 | <Hixie> | clearly |
| 09:59 | <zcorpan_> | why? |
| 09:59 | <annevk> | it won't match in HTML documents with HTML5 reality |
| 09:59 | <Hixie> | ? |
| 09:59 | <annevk> | it will match in XML documents as long as we keep the isHTMLDocument() check |
| 09:59 | <Hixie> | in HTML, if I do <A>, it turns into <a>, so it's fine |
| 09:59 | <Hixie> | in XML it doesn't |
| 09:59 | <annevk> | you can still do createElementNS() in HTML |
| 10:00 | <Hixie> | you can, sure, but that's far less of a worry |
| 10:00 | <zcorpan_> | why are you worried about <A xmlns="http://www.w3.org/1999/xhtml"/>;? |
| 10:00 | <zcorpan_> | that's invalid anyway |
| 10:00 | <annevk> | uppercase HTML element names is a worry? |
| 10:00 | <annevk> | seems as theoretical as createElementNS |
| 10:00 | <Hixie> | i'm worried about <myWidget> |
| 10:00 | <Hixie> | or <x-myWidget> |
| 10:01 | <annevk> | if people used XML, sure |
| 10:01 | <zcorpan_> | Hixie: i think there are basically 0 pages that rely on that |
| 10:01 | <Hixie> | today, sure |
| 10:02 | <zcorpan_> | so then we can change it today |
| 10:02 | <Hixie> | but if we ever introduce something like <x-foo> as an element name, e.g. for use with XBL, it'd be very confusing to authors if they suddenly could only style their elements if they were lowercase |
| 10:02 | <Hixie> | look i'm all for simplifying and all, but let's not do so by burning bridges that don't need to be burnt |
| 10:02 | <Hixie> | the platform is crazy unintuitive enough as it is |
| 10:03 | <zcorpan_> | data-* already requires lowercase |
| 10:04 | <Hixie> | yeah, but not much we can do about that |
| 10:04 | <hsivonen> | Hixie: making Selectors work right with SVG camelCase and HTML "case-insensitive" names in HTML docs means that the data structures representing selectors have to contain the original-case string as an interned pointer and the ascii-lowercased string as an interned pointer |
| 10:04 | <Hixie> | hsivonen: authors > implementors |
| 10:05 | <hsivonen> | Hixie: once you've gone that far, not doing the same thing in XHTML only makes the style sheets less cacheable and the matching code have two cases |
| 10:06 | <Hixie> | that went over my head |
| 10:06 | <zcorpan_> | Hixie: i'm not convinced the current setup is any better for authors |
| 10:06 | <hsivonen> | Hixie: if you've implemented what makes sense for HTML (which is real-world constrained), making the XML side do something different means you have to support two cases |
| 10:07 | <hsivonen> | Hixie: the second one of which is motivated by theoretical purity |
| 10:07 | <Hixie> | there's a difference between theoretical purity and clean design |
| 10:08 | <hsivonen> | Hixie: and if you don't want to check isInHtmlDocument() at selector matching time, you make the HTML-specific interned string be case-folded or not case-folded at style sheet parse time |
| 10:08 | <hsivonen> | Hixie: which means compiled style sheets aren't cacheable across HTML and XML |
| 10:08 | <Hixie> | i thought we weren't caring about theoretical concerns? |
| 10:08 | <hsivonen> | different concerns! :-) |
| 10:09 | <Hixie> | uh huh |
| 10:09 | <Hixie> | XML is case-sensitive |
| 10:09 | <Hixie> | it is not intuitive for it to be inconsistent |
| 10:09 | <Hixie> | one of the few things about the XML side of the platform that is actually a redeeming factor is that it is at least somewhat consistent and mostly free of weird quirks |
| 10:10 | <Hixie> | let's not go and bring them all into XML |
| 10:10 | <Hixie> | it's one thing to have namespace-specific features (like backgrounds on <html:body> propagating to the viewport) in the name of compat, but it's far worse to have quirks on elements that don't even exist yet |
| 10:10 | <hsivonen> | making something case-insensitive is one of those things that seem really simple when someone first suggests it but that lead down to an abyss of implementation troubles |
| 10:11 | <hsivonen> | of course, the usability folks will claim that the abyss doesn't matter, because case-insensitivity is supposed to be human-friendly |
| 10:11 | <annevk> | so I'm now more radical than Hixie ;p |
| 10:13 | <Hixie> | annevk: my "radicalness" is usually driven by trying to simplify -- I don't think this simplifies. Or rather, it simplifies implementations, at the cost of complicating the platform for authors, which is the wrong prioritisation. |
| 10:13 | <hsivonen> | Hixie: fwiw, cacheability isn't a theoretical concern for impls. You know that clueful implementors feel they have to make caching work "right" even if the case breaking caching were rare to non-existent in practice |
| 10:13 | <hsivonen> | Hixie: I mean, you could put a caching test in Acid4 for all an implementor knows! |
| 10:14 | <Hixie> | parsing a sheet is cheap |
| 10:14 | <hsivonen> | Hixie: you still have to write the code and do the QA to make sure you actually reparse. that's my point. |
| 10:15 | <Hixie> | *shrug* |
| 10:15 | <Hixie> | it's already written in most browsers |
| 10:15 | <hsivonen> | (I agree that it would suck for UA style sheets to match nodes that didn't actually get the right implementation classes) |
| 10:15 | <hsivonen> | (so dominos would fall...) |
| 10:16 | <zcorpan_> | UA style sheets already don't use the case sensitivity rules for author style sheets per html5 |
| 10:17 | <zcorpan_> | for attribute values |
| 10:17 | <Hixie> | that doesn't affect future elements that the author might invent |
| 10:18 | <Hixie> | wow, julian thinks that image/svg+xml not being registered for 10 years is a _success_ |
| 10:21 | <Hixie> | anyway, i should go to bed |
| 10:21 | <Hixie> | nn |
| 10:33 | <abarth> | jgraham: the hybi working group is just insane |
| 10:33 | <abarth> | jgraham: i'm secretly hoping they screw up the protocol so badly that it's unusable :( |
| 10:35 | <jgraham> | abarth: Not very secretly anymore :) |
| 10:36 | <jgraham> | Anyway it seems unlikely that it will go that badly wrong, but it may be suboptimal |
| 10:36 | <annevk> | abarth, fwiw, I was mostly j/k on the cookie list |
| 10:36 | <abarth> | i know |
| 10:36 | <annevk> | abarth, Opera even implemented Cookie2 |
| 10:36 | <annevk> | (though we're gonna nuke it one of these days) |
| 10:36 | <jgraham> | The "four weeks" timetable has been entirely ignored |
| 10:36 | <jgraham> | Which is a pity |
| 10:37 | <jgraham> | Because it means that -76 will have lots of time to get traction |
| 10:37 | <jgraham> | Whether they want it to or not |
| 10:37 | <ake1> | is there no standard font-family/size etc. on textareas? i have come to realise that using textareas and em is a bad idea. |
| 10:38 | <annevk> | yeah, they way hybi is being run now it seems like it might take years |
| 10:38 | <abarth> | annevk: i wish we could give people a better way to manage state than cookies, but it's a tough problem |
| 11:23 | <jgraham> | abarth: Did you say you had more parser tests? |
| 11:24 | <abarth> | i pushed a handful to html5lib |
| 11:24 | <abarth> | nothing too exciting |
| 11:24 | <jgraham> | Oh you pushed them already? |
| 11:24 | <jgraham> | Great |
| 11:24 | <jgraham> | Thanks :) |
| 11:24 | <abarth> | we're basically done, so we probably won't be generating too many more |
| 11:24 | <abarth> | unless we have bugs |
| 11:24 | <jgraham> | Sure |
| 11:24 | <abarth> | at some point we need to review all the changes to the spec to make sure we have them all |
| 11:24 | <jgraham> | Ones from bugs are possibly the most intersting of course |
| 11:25 | <abarth> | so far the bugs we've had are mostly with integrating with the render tree |
| 11:25 | <abarth> | not with the DOM |
| 11:25 | <abarth> | there's something goofy called a "demoted" form element |
| 11:26 | <abarth> | that means the form element magically renders differently depending on what happens to it during parsing |
| 11:26 | <abarth> | very strange |
| 11:26 | <jgraham> | Wow |
| 11:26 | <hsivonen> | abarth: what's the motivation for having that sort of thing? |
| 11:27 | <abarth> | the layout of some sites break without it |
| 11:27 | <abarth> | i think it's just a design error |
| 11:27 | <abarth> | in the render tree |
| 11:27 | <hsivonen> | abarth: what happens in Gecko on those sites? |
| 11:27 | <abarth> | they render correctly |
| 11:27 | <hsivonen> | abarth: why? |
| 11:28 | <abarth> | this is the case when the form element gets inserted in teh InTableBody insertion mode |
| 11:28 | <abarth> | if you don't "demote" the form element |
| 11:28 | <abarth> | it gets rendered as if it were a table-cell |
| 11:28 | <abarth> | which throws off the layout of the table |
| 11:28 | <abarth> | the right fix is probably to fix the render tree |
| 11:29 | <abarth> | so that it doesn't create these nutty anonymous table cells |
| 11:29 | <abarth> | but the expedient solution, for the time being, was to just set the "demoted" flag on the form |
| 11:29 | <hsivonen> | abarth: we have a UA style sheet rule for that |
| 11:30 | <abarth> | oh yeah? |
| 11:30 | <abarth> | what does that look like? |
| 11:30 | <zcorpan_> | it's specced in html5 iirc |
| 11:30 | <hsivonen> | abarth: http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#465 |
| 11:31 | <abarth> | Important: don't show these forms in HTML |
| 11:31 | <abarth> | :) |
| 11:31 | <hsivonen> | :-moz-is-html matches if the owner doc of the node has the HTMLness bit set |
| 11:31 | <zcorpan_> | "In HTML documents, the user agent is expected to hide form elements that are children of table, thead, tbody, tfoot, or tr elements, irrespective of CSS rules." |
| 11:31 | <zcorpan_> | http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#display-types |
| 11:32 | <abarth> | ok, i can try something like that |
| 11:32 | <abarth> | i usually stay away from the render tree |
| 11:32 | <abarth> | so i might ask some who knows about rendering to try it |
| 12:47 | <annevk> | emailed public-webapps with Web DOM Core notes |
| 12:57 | <annevk> | prolly best presentation at dConstruct: http://booktwo.org/notebook/wikipedia-historiography/ |
| 12:58 | <annevk> | those books are huge btw |
| 12:59 | <adactio> | annevk: James Bridle completely blew my mind with his presentation. Awesome, in the true sense of the word. |
| 13:00 | <adactio> | annevk: By the way, it was good to see you, brief as it was. Shame we didn't have a chance to chat some more. |
| 13:02 | <annevk> | depending on the length of your stay, we can probably chat in the Netherlands start of October |
| 13:03 | <Peter`> | so you're coming now after all, annevk? :-p |
| 13:04 | <annevk> | well, I'm in town :) |
| 13:11 | <annevk> | hmm, DOM3Core is full of bugs |
| 13:11 | <annevk> | e.g. pseudo-code that assumes there is always a root element (return documentElement.isDefaultNamespace(namespaceURI);) |
| 13:13 | <zcorpan_> | that's not normative though is it? |
| 13:14 | <annevk> | the normative text says "See Namespace URI Lookup for details on the algorithm used by this method." |
| 13:14 | <annevk> | now idea on how else you would know the answer |
| 13:15 | <zcorpan_> | awesome |
| 13:15 | <hsivonen> | isDefaultNamespace and lookupNamespaceURI are not my favorite DOM methods |
| 13:16 | <zcorpan_> | what's your favorite? |
| 13:16 | <hsivonen> | good question |
| 13:16 | <hsivonen> | dunno, but those aren't it |
| 13:17 | <jgraham> | That sounds like a very geeky lame chat up line |
| 13:17 | <zcorpan_> | annevk: btw baseURI is going to need some html-specific processing |
| 13:17 | <jgraham> | Like an alternative to "what's your favourite colour" |
| 13:17 | <jgraham> | Well "chat up" is not quite right |
| 13:18 | <jgraham> | Umm, I should stop being incoherent about now, right? |
| 13:18 | <hsivonen> | what's the idiomatic way to sort a set of key-value pairs of strings by the lexical UTF-16 code unit order of the keys in JS? |
| 13:18 | <annevk> | zcorpan_, we are providing hooks instead |
| 13:19 | <zcorpan_> | annevk: ok |
| 13:19 | <annevk> | at least, we do that elsewhere at the moment for base URL fixups |
| 13:19 | <jgraham> | hsivonen: sort with a custom comparison function? |
| 13:19 | <jgraham> | assuming you have [[key1:value1], [key2:value2]] or similar |
| 13:19 | <jgraham> | s/:/,/g |
| 13:19 | <annevk> | but baseURI can be set, so HTML5 can just set it, afaict |
| 13:20 | <hsivonen> | jgraham: I guess I'm going to follow http://stackoverflow.com/questions/890807/iterate-over-a-javascript-associative-array-in-sorted-order |
| 13:20 | <hsivonen> | i.e. put keys in an array and .sort() then iterate over the array |
| 13:21 | hsivonen | is mildly disappointed at not being able to iterate over the keys of an object directly in the lexical order |
| 13:23 | <jgraham> | hsivonen: Oh, you have an object you are using as a hashmap? |
| 13:24 | <jgraham> | That is a bit different then |
| 13:24 | <hsivonen> | jgraham: yeah |
| 13:24 | <hsivonen> | jgraham: what I want to do is sorting the attributes of a node in the right order for the html5lib tree builder tests |
| 13:24 | <jgraham> | But it seems asking a lot for the language to support this use case directly |
| 13:24 | <jgraham> | hsivonen: I see |
| 13:25 | <hsivonen> | jgraham: in Java, I used TreeMap and it does the right thing on iteration |
| 13:25 | <jgraham> | That seems undesirable in general, doesn't it? |
| 13:26 | <hsivonen> | jgraham: if you don't want sorted iteration, you use HashMap in Java |
| 13:26 | <hsivonen> | TreeMap by design orders stuff |
| 13:26 | <jgraham> | Hmm |
| 13:27 | <hsivonen> | and in Python, you can ask a map for its keys and sort that list |
| 13:27 | <hsivonen> | anyway time to just write this in code |
| 13:27 | <jgraham> | In ES5 you can ask for the keys directly |
| 13:27 | <hsivonen> | ooh. how? |
| 13:28 | <jgraham> | Object.keys or so |
| 13:28 | <jgraham> | Object.keys(my_object) |
| 13:28 | <jgraham> | I think |
| 13:28 | <hsivonen> | cool. |
| 13:28 | <hsivonen> | thanks |
| 13:28 | <jgraham> | But I have never used it |
| 13:28 | hsivonen | tries if it works in Gecko |
| 13:29 | <hsivonen> | cool. works |
| 13:31 | <hsivonen> | annevk: fwiw, I'm just working on code that uses Element.attributes |
| 13:31 | <hsivonen> | useful for test cases :-/ |
| 13:32 | jgraham | guesses hsivonen is using it in exactly the same way he is |
| 13:33 | <Philip`> | The Live DOM Viewer uses .attributes too |
| 13:33 | <jgraham> | Heh |
| 13:33 | <annevk> | how is everyone using it? |
| 13:34 | <hsivonen> | annevk: iterating over attributes to get localName, namespaceURI and value |
| 13:34 | <hsivonen> | annevk: in order to print them all |
| 13:34 | <annevk> | that should be easy enough to keep |
| 13:35 | <annevk> | kind of depends to what level people are willing to hack on the DOM to simplify it and see if things break |
| 13:35 | <annevk> | otherwise we'll just end up with complexity |
| 13:35 | <annevk> | so if maciej/sicking can be convinced to play around a bit there's a good chance I think |
| 13:35 | <annevk> | otherwise not so much |
| 13:38 | Philip` | sees pages using getNamedItem(name).value, item=createAttribute(name), setNamedItem(item), etc |
| 13:39 | <annevk> | really? sigh |
| 13:40 | <annevk> | especially createAttribute is kind of unfortunate |
| 13:41 | <Philip`> | http://tonik.webovastranka.cz/friend?type=file&subservice=1 |
| 13:49 | <hsivonen> | sigh. for (var e in array) doesn't work as expected |
| 13:49 | <hsivonen> | shows how rusty my JS is |
| 13:49 | <jgraham> | hsivonen: What do you expect? |
| 13:50 | <hsivonen> | jgraham: e to become each of the array elements in turn |
| 13:50 | <jgraham> | Ah, no, that would be python :) |
| 13:51 | <Philip`> | "for each (var e in array)" if you want to use SpiderMonkey extensions |
| 13:51 | <Philip`> | though the warnings in https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in#Description are relevant |
| 13:52 | <hsivonen> | I guess I'll just go with an index |
| 13:53 | <zcorpan_> | that's what i usually do |
| 13:53 | <Philip`> | (I think SpiderMonkey changes the array iteration order depending on whether it applies the dense array optimisation or not, so it'll often be ordered but not always) |
| 13:54 | <hsivonen> | Philip`: oh, I want ordered iteration |
| 13:54 | <Philip`> | Which order? :-) |
| 13:54 | <hsivonen> | Philip`: the order of the array |
| 13:54 | <hsivonen> | as returned by .sort() on another one |
| 13:54 | <Philip`> | Ah |
| 13:56 | <Philip`> | I think you need either for(i=0;i<a.length;++i) or a.forEach(function(){ ... }) then, since nothing else provides enough guarantees |
| 13:58 | <peterhil> | hsivonen: I'm not sure what you want to do, but Trie could be used for sorting: http://en.wikipedia.org/wiki/Trie#Sorting |
| 14:00 | <jarib> | anyone know where a good place would be to find tests for HTMLTableElement.rows (especially with regard to nested tables)? |
| 14:01 | <hsivonen> | peterhil: JavaScript doesn't have built-in tries, does it? |
| 14:02 | <hsivonen> | I used Object.keys(foo).sort() |
| 14:02 | <peterhil> | Guess it doesn't. |
| 14:17 | <hsivonen> | the html5lib license file has the wrong copyright year and lacks authorship data for the WebKit tests |
| 14:17 | <hsivonen> | ezyang, too |
| 14:17 | <MikeSmith> | jarib: http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/HTMLTableElement ,maybe |
| 14:20 | <annevk> | zcorpan_, do you know why http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html does originalElement.lookupNamespaceURI(Element's prefix) == namespaceURI) checks? |
| 14:21 | <annevk> | in lookupNamespacePrefix? |
| 14:21 | <annevk> | they seem redundant |
| 14:30 | <jgraham> | hsivonen: You planning to fix? |
| 14:30 | <hsivonen> | jgraham: not really |
| 14:31 | <jarib> | MikeSmith: thanks, will take a look |
| 14:31 | <hsivonen> | jgraham: I could fix the year, but I don't know if the unlisted contributors chose to waive notice |
| 14:31 | <MikeSmith> | jarib: np |
| 14:31 | <hsivonen> | jgraham: And I don't know who the copyright holder for the contribs abarth landed is |
| 14:32 | <jgraham> | hsivonen: AFAIK it was abarth and eseidel |
| 14:32 | <hsivonen> | jgraham: but it would be really nice to have the legal stuff in order before I import the new tests to m-c |
| 14:33 | <hsivonen> | jgraham: well, I don't know if that means abarth and eseidel, UC Berkeley, Google or something else, so I'm not gonna land legal stuff based on guessing |
| 14:33 | <jgraham> | hsivonen: I was told by Eric that they considered them public domain |
| 14:33 | <hsivonen> | jgraham: cool. that works |
| 14:33 | <jgraham> | But I agree you should ask them |
| 14:34 | <hsivonen> | jgraham: than I can update the year to 2010, since the contribs I've been landing are Copyright 2010 Mozilla Foundation |
| 14:34 | <hsivonen> | *then |
| 14:34 | <jgraham> | (not least because I don't remember *where* I was told that so might have difficulty producing documentary evidence) |
| 14:42 | <hsivonen> | soo... window.btoa assumes the code points in the argument have the high half as zeros |
| 14:42 | <hsivonen> | what's the correct way to to convert a JS string to base64 so that it's first encoded as UTF-8? |
| 14:59 | <Workshiva> | hsivonen: Could you give an example of what doesn't work? |
| 15:00 | jgraham | wonders why hsivonen is doing base64 conversions at all |
| 15:03 | <hsivonen> | jgraham: afterwards I realized that I can stick a JS string unescaped into a data: URL and the right magic will happen |
| 15:40 | <annevk> | so DOM3Core states |
| 15:40 | <annevk> | "Before returning found prefix the algorithm needs to make sure that the prefix is not redefined on an element from which the lookup started." |
| 15:40 | <annevk> | that seems to assume async lookup |
| 15:40 | <annevk> | which is not at all the case |
| 15:41 | <annevk> | what were these people smoking |
| 15:42 | <annevk> | the more I complete this new doc the less I will have to study it I suppose |
| 15:42 | <annevk> | yay |
| 16:00 | <annevk> | now wondering why isDefaultNamespace is a method rather than an attribute that returns the default namespace |
| 16:00 | <annevk> | could just be an attribute |
| 16:09 | <boogyman> | Can someone point me to literature explaining the purpose behind allowing block-level elements to be encapsulated by an anchor tag in html5 |
| 16:09 | <Workshiva> | People do it, browsers support it, none of the alternative solutions were any better |
| 16:12 | <annevk> | also, we obsoleted the block-level concept so it made sense |
| 16:12 | <annevk> | but really |
| 16:12 | <annevk> | dom3core was designed by .... |
| 16:13 | <boogyman> | monkeys |
| 16:13 | <jgraham> | with guns |
| 16:13 | <hsivonen> | Hixie: FYI, another interesting <base>-related site compat problem: https://bugzilla.mozilla.org/show_bug.cgi?id=593807 |
| 16:14 | <hsivonen> | boogyman: people really wanted the feature and it mostly worked already |
| 16:14 | <hsivonen> | boogyman: IIRC, it had use cases, too :-) |
| 16:15 | <boogyman> | so because people want it, it should be so? |
| 16:16 | <hsivonen> | boogyman: IIRC, they had use cases to go with the wanting |
| 16:16 | <hsivonen> | boogyman: on Eric Meyer's blog, IIRC |
| 16:16 | <boogyman> | can you point me to the logs and/or literature? |
| 16:17 | <hsivonen> | boogyman: http://meyerweb.com/eric/html-xhtml/html5-linking.html |
| 16:20 | <boogyman> | hsivonen: thanks for the link, and can you provide a situation where linking an entire table row is using proper design techniques? |
| 16:22 | <hsivonen> | boogyman: sorry, at this point, I'm going to defer to the search function of the whatwg list and Eric Meyer's site |
| 16:22 | <hsivonen> | gotta run |
| 16:22 | <hsivonen> | AFK |
| 16:22 | <boogyman> | t/c |
| 16:24 | <espadrine> | boogyman: the tool is neutral... |
| 16:25 | <boogyman> | what tool? |
| 16:25 | <espadrine> | Sure, people can link an entire table row. |
| 16:26 | <espadrine> | But the fact that it is allowed doesn't mean anyone should do it. |
| 16:26 | <jgraham> | Umm, you can't using the current method anyway |
| 16:26 | <jgraham> | Unless you use XHTML or javascript |
| 16:27 | <jgraham> | Linking an entire table row seems rather useful though |
| 16:29 | <boogyman> | It seems like it's feeding back into improper design... Tables are already abused, so why offer the ability to abuse further? I can see where one might want to link an entire row, but that row, should consist of exactly 1 data/head cell with the appropriate column span |
| 16:30 | <nimbupani> | i dont see why it is improper design, sometimes all you want to do is have tabular data linked to one common page. |
| 16:30 | <nimbupani> | the table is visual data |
| 16:31 | <nimbupani> | linking is not visual but just navigation. |
| 16:31 | <annevk> | but linking table rows is not going to work |
| 16:31 | <jgraham> | boogyman: A good example colud be a mail client where the whole row was a link to the message |
| 16:32 | <annevk> | other example: http://html5.org/tools/web-apps-tracker |
| 16:32 | <jgraham> | It is clearly tabular data |
| 16:32 | <annevk> | but it does not work with the HTML5 parser (or with CSS) |
| 16:32 | <boogyman> | jgraham: there's no reason the whole row must be a link.. the TITLE of the message is perfectly capable of carrying that distinction |
| 16:32 | <annevk> | well, it would work with CSS if <a> replaced the <tr> |
| 16:32 | <annevk> | but then the semantics get dubious |
| 16:33 | <jgraham> | boogyman: There's no reason it *has* to be of course. But there's no reason it *shouldn't* be either |
| 16:33 | <jgraham> | if it makes nice UI |
| 16:33 | <annevk> | expressing the target area of a link in CSS might be neat |
| 16:34 | <annevk> | so you can say tr { redirect-hit-testing:childA } (bogus syntax) |
| 16:35 | <nimbupani> | does it not lead to more confusion between content and presentation? |
| 16:35 | <boogyman> | jgraham: proper design and/or ui techniques mandate that links be clearly distinguishable, and having 1 long "underline" across row after row ... doesn't make for good UI |
| 16:36 | <jgraham> | One would clearly not have one long underline |
| 16:36 | <boogyman> | So you're proposing to remove the default user-agent rendering of anchor tags? |
| 16:36 | <annevk> | web page UI != web app UI |
| 16:37 | <jgraham> | Anyway I am pretty sure it would make for good UI because I have often wished things would behave like this and many desktop apps do |
| 16:37 | <jgraham> | I don't see how the defaults really matter |
| 16:37 | <boogyman> | graceful degradation, and 508 compliance? |
| 16:38 | <jgraham> | Browsing without CSS will many many sites less usable |
| 16:38 | <jgraham> | *make many |
| 16:39 | <jcranmer> | try browsing the web without JS |
| 16:39 | <boogyman> | So you're okay with changing the specification because of the poor designs of some arbitrary number of websites, main-stream or not? |
| 16:39 | <jgraham> | Hmm? |
| 16:40 | <jgraham> | I am OK with making good design possible from pure markup even if it doesn't look great with the default style sheet |
| 16:40 | <boogyman> | Just because some websites do not follow proper design techniques is not a reason to abandon |
| 16:40 | <jcranmer> | making an HTML agent without supporting CSS or JS is just shooting yourself in the foot |
| 16:40 | <jgraham> | In this case it is a fail anyway because the solution doesn't work with table rows |
| 16:41 | <boogyman> | jcranmer: Markup first, Then presentation, Then dynamic content |
| 16:41 | <annevk> | boogyman, UAs without CSS could provide reasonable alternative presentation once the pattern becomes more prevalent |
| 16:42 | <annevk> | boogyman, if we only sticked with what is allowed in the past there would be no progress |
| 16:42 | <boogyman> | I agree, but not all progress is good |
| 16:42 | <jcranmer> | you say to-may-to, I say to-mah-to |
| 16:43 | <annevk> | I have a colleague that really makes a point of that tomato thing |
| 16:43 | jcranmer | needs to choose idioms that are easier to express in written language |
| 16:44 | <annevk> | btw |
| 16:44 | <annevk> | getting the default namespace is as easy as lookupNamespaceURI(null) |
| 16:44 | <boogyman> | I'd rather have these types of situations sorted before the specification comes out of draft form, as it will take 5-10 yrs for most user-agents to reasonably support it |
| 16:45 | <jcranmer> | the only compelling argument I see for having <a> only include inline content is that it keeps links small if people forget the </a> |
| 16:46 | <boogyman> | jcranmer: which in development should be sorted... |
| 16:46 | <jcranmer> | so it's not a very strong argument, then |
| 16:47 | <jgraham> | This is something UAs already support |
| 16:47 | <jgraham> | That's why we ended up with the doesn't-work-with-tables solution |
| 16:49 | <jgraham> | (a good argument against the current solution might be that it will encourage people to use <div> instead of table cells for tabular data and mnake it all display:table-cell or whatever |
| 16:50 | <jgraham> | like <div class="table"><a class="tr"><div class="td"> and so on, and some CSS attached to the classes) |
| 16:51 | <boogyman> | WOW, more improper design techniques |
| 16:51 | <jcranmer> | it all depends on the copy-paste sources |
| 17:17 | <annevk> | oh god |
| 17:17 | <annevk> | isSupported() |
| 17:18 | <annevk> | bloat |
| 17:20 | <Dashiva> | annevk.hasFeature('HtmlEditor') |
| 17:23 | <annevk> | it's just painful how much stuff is in here that is poorly thought out and designed |
| 17:25 | <annevk> | of course, it wasn't news to anyone that the DOM was a kludge, but it was news to me how that was driven throughout the design whole of it -- it is inherently a kludge, so to say |
| 17:31 | <annevk> | another one |
| 17:31 | <annevk> | Text.wholeText is readonly |
| 17:31 | <annevk> | Node.textContent is roughly of equivalent functionality but can also be set |
| 17:31 | <jcranmer> | if we could, I suppose we would rewrite everything from scratch |
| 17:31 | <annevk> | for Text.wholeText we need Text.replaceWholeText() |
| 17:32 | <annevk> | this whole wholeText feature is dubious to start with, but apparently every silly browser has it implemented |
| 17:33 | <annevk> | jcranmer, when I think about that I never no at what level it would be appropriate to stop |
| 17:33 | <annevk> | s/no/know/ |
| 17:34 | <annevk> | it's also a lot easier of course to set up a slightly enhanced system now we know the requirements of now |
| 17:43 | <abarth> | jgraham, hsivonen: if you're talking about the html5lib tests, they're available under this license: http://trac.webkit.org/browser/trunk/WebKit/LICENSE |
| 17:44 | <abarth> | everything in svn.webkit.org that doesn't have an explicit license is available under that license |
| 17:44 | <annevk> | what about 2010? |
| 17:44 | <abarth> | :) |
| 17:45 | <abarth> | not sure who's supposed to bump the year on the file |
| 17:45 | <abarth> | i'm told that it doesn't actually matter |
| 17:45 | <annevk> | licensing is so passe anyway ;p |
| 17:48 | <abarth> | (to be clear, i was told the year doesn't actually matter. the rest is moderately important) |
| 18:30 | <hsivonen> | abarth: whoa so the test cases you committed to html5lib aren't actually under the same license as the rest of html5lib? |
| 18:31 | <hsivonen> | abarth: is there a lawyer-satisfying statement on the WebKit site somewhere saying that license headerless test cases in the WebKit tree are under the Apple license even if they came from non-Apple contributors? |
| 18:32 | <abarth> | would you like them under the MIT license? |
| 18:32 | <hsivonen> | abarth: it would be simpler if everything in the html5lib repo were MIT, sure |
| 18:33 | <abarth> | IANAL, but i think this is the operative text: |
| 18:33 | <abarth> | http://pastebin.com/kXF5RqLm |
| 18:33 | <abarth> | you agree to that every time you upload a patch |
| 18:34 | <abarth> | also the committer agreement you sign when you get commit rights says something similar |
| 18:35 | <hsivonen> | abarth: thanks! I'll point Mozilla legal to that |
| 18:35 | <abarth> | i suspect, actually, they're already licensed under MIT as well |
| 18:35 | <abarth> | given that eric and i wrote them |
| 18:35 | <abarth> | and we added them to html5lib |
| 18:35 | <abarth> | which is licensed under MIT |
| 18:36 | <abarth> | ideally we would have agreed to something that says everything we push to html5lib is licensed under MIT |
| 18:36 | <abarth> | or, even better, the files themselves would carry a license block |
| 18:38 | <hsivonen> | abarth: I expected them to be under MIT, but the I noticed that the contributors weren't listed in the LICENSE file on the top level of html5lib |
| 18:39 | <abarth> | ok, i can add eric and myself to that list if you think that's helpful |
| 18:41 | <hsivonen> | abarth: I think it would be helpful to have the copyright holders listed, there (unless there are copyright holders who deliberately wish to waive notices) |
| 18:41 | <hsivonen> | s/,// |
| 18:42 | <abarth> | done |
| 18:42 | <abarth> | this licensing stuff is mostly religion as far as i can tell |
| 18:42 | <hsivonen> | abarth: thanks |
| 18:43 | <hsivonen> | abarth: sorry about being annoying, but I need to cover my legal behind for stuff I push to mozilla-central |
| 18:43 | <abarth> | oh, not at all. Everyone in the community appreciates your being careful |
| 18:43 | <abarth> | webkit isn't careful enough, IMHO |
| 18:44 | <abarth> | i've long thought we should have a license bot that checks all incoming patches for appropriate license blocks |
| 19:03 | <AryehGregor> | MediaWiki developers don't seem to care about licenses at all. No one signs anything when they submit patches or get commit access, and almost none of the files have license blocks. |
| 19:04 | <Moo^_^> | AryehGregor: live dangerously, die young? :) |
| 19:06 | <jgraham> | There are more people missing from the license file |
| 19:06 | <jgraham> | Looking at the commit history. And I should change my email address |
| 19:06 | <jgraham> | And there is probably more that is wrong |
| 19:58 | AryehGregor | discovers that Chrome now suggests the Readability bookmarklet when he starts typing "readability" in the Omnibox, which is awesome, since he can't figure out how to actually bookmark it |
| 20:26 | <aho> | AryehGregor, just create a new bookmark and paste that "javascript:..." junk there (in this case you can get that by right clicking the readability button and then selecting "copy link location" from the context menu) |
| 20:26 | <AryehGregor> | Oh, you know, I think that's what I did. |
| 20:26 | <AryehGregor> | Which is why Chrome found it. |
| 20:26 | <AryehGregor> | Duh. |
| 20:27 | AryehGregor | was vaguely wondering how it could have associated the bookmarklet with "Readability" automatically |
| 20:27 | <aho> | heh |
| 20:27 | AryehGregor | guesses he just assumes Chrome is magical |
| 20:28 | <paul_irish> | it certainly is. |
| 20:48 | <AryehGregor> | Does Firefox support ping? There's a ping IDL attribute on a and area, it looks like, at least in Minefield. |
| 20:52 | <AryehGregor> | "On setting, the given value must be converted to the shortest possible string representing the number as a valid non-negative integer" |
| 20:52 | <AryehGregor> | That sounds non-trivial, and somehow I suspect browsers don't do it. |
| 20:53 | <AryehGregor> | I bet they do whatever ECMAScript says. |
| 20:53 | AryehGregor | wouldn't bet *too* much, though. |
| 20:54 | <Philip`> | AryehGregor: That just means omitting any leading 0s, I think |
| 20:54 | <AryehGregor> | It doesn't allow exponential notation? |
| 20:54 | AryehGregor | checks |
| 20:55 | <AryehGregor> | Oh, it doesn't. |
| 20:55 | <AryehGregor> | Okay, you're righ.t |
| 20:55 | <AryehGregor> | right. |
| 20:55 | <Philip`> | and omitting whitespace |
| 20:55 | <AryehGregor> | Ah, for floats it does reference ToString: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#best-representation-of-the-number-as-a-floating-point-number |
| 21:28 | <AryehGregor> | Wow, IE8 supports "maxlength" instead of "maxLength" as an IDL property. Impressive. |
| 21:28 | <AryehGregor> | By the way, is it correct to call them "IDL properties"? Or is there some better name? |
| 21:28 | <AryehGregor> | Because I'm calling them IDL properties everything in the code for this test case, and it would be nice if I weren't completely confusing everyone. |
| 21:28 | <AryehGregor> | IDL attribute, I mean. |
| 21:29 | <AryehGregor> | Okay, the spec calls them that, so I'm safe. |
| 21:33 | <AryehGregor> | Oh, wait, IE8 supports textarea.maxlength but input.maxLength? . . . never mind, I don't even want to know. |
| 21:35 | <espadrine> | I don't understand why this does not work: |
| 21:36 | <espadrine> | http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0,%200,%20640,%20480);%0Ac.save();%0A%0Avar%20img%20%3D%20new%20Image();%0Aimg.src%20%3D%20'http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg';%0Ac.fillStyle%20%3D%20c.createPattern(img,'');%0Ac.fillRect(0,0,c.canvas.width,c.canvas.height);%0A%0Ac.restore();%0A |
| 21:36 | <AryehGregor> | "Work" in what sense? |
| 21:37 | <espadrine> | If you use one of the images Hixie gives, they appear. |
| 21:37 | <espadrine> | On the background. |
| 21:37 | <espadrine> | As a pattern. |
| 21:40 | <espadrine> | I have tested this piece of code on a number of browsers, none of them draw the image of the lion on the background... |
| 21:44 | <espadrine> | Actually, Opera *does*, but only if we *click* on the canvas. |
| 21:44 | <espadrine> | ... and it crashes. |
| 21:44 | <AryehGregor> | Yeah, the example froze up Opera for me. |
| 21:44 | <AryehGregor> | And it threw some error in Firefox nightly. |
| 21:44 | <AryehGregor> | Displayed a lion picture in Chrome dev, though. |
| 21:44 | <espadrine> | Firefox refuses SVG images |
| 21:45 | <AryehGregor> | Dunno if it's correct, but it's a pretty lion picture, so I consider it the winner. |
| 21:45 | <espadrine> | No way! I tested Chrome dev seconds ago! |
| 21:45 | <AryehGregor> | What do you see? |
| 21:46 | <espadrine> | Nothing! (Elephants Dream reminiscence :) |
| 21:46 | <espadrine> | It is plain blank for me. |
| 21:48 | espadrine | is downloading the latest webkit... |
| 21:49 | <espadrine> | Nothing on the latest webkit too... |
| 21:53 | <espadrine> | Feels like SVG images are a big bag of bugs in all browsers, not just Firefox... |
| 22:00 | <AryehGregor> | I like to test the quality of my refactoring commits by doing git diff | grep ^- | wc -l and comparing to git diff | grep ^+ | wc -l. |
| 22:00 | AryehGregor | sees -151, +77 on this commit, yay |
| 22:00 | <Hixie> | espadrine: you're painting it before it's leaded |
| 22:01 | <Hixie> | loaded |
| 22:01 | <Philip`> | AryehGregor: Tried "git diff | diffstat"? |
| 22:01 | <espadrine> | Hixie: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0,%200,%20640,%20480);%0Ac.save();%0Avar%20img%20%3D%20new%20Image();%0Aimg.src%20%3D%20'http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg';%0Aimg.onload%20%3D%20function()%20{%0Ac.fillStyle%20%3D%20c.createPattern(img,'');%0Ac.fillRect(0,0,c.canvas.width,c.canvas.height);%0A}%0Ac.restore();%0A |
| 22:02 | <Philip`> | AryehGregor: or "git diff --stat" |
| 22:02 | <AryehGregor> | Philip`, this is git, we don't -- yeah, I was about to say that. |
| 22:02 | <Philip`> | AryehGregor: Seems easier than grepping |
| 22:02 | <AryehGregor> | git doesn't need any silly "external program" things. |
| 22:02 | <Philip`> | So why are you using grep and wc? :-) |
| 22:02 | <Hixie> | espadrine: the code in the box gets called ten times a second |
| 22:02 | <AryehGregor> | Because I used to a) use SVN, and b) not know about diffstat. |
| 22:02 | <Hixie> | espadrine: by the time the image has loaded you've launched another 20 image loads |
| 22:03 | <Hixie> | espadrine: and they'll all wipe out the one that did load |
| 22:06 | <espadrine> | Hixie: well... this is an issue indeed, but I swear it doesn't work! I just tested a version of it in an html test file! |
| 22:08 | AryehGregor | goes to get something to eat before he tries porting enums to the rewrite of his reflection testing framework |
| 22:10 | <jgraham> | espadrine: If you have crashed Opera could you file a bug, please |
| 22:11 | <espadrine> | jgraham: sure... although it seems to happen once in twenty times... |
| 22:11 | <Hixie> | espadrine: uri? |
| 22:13 | <jgraham> | espadrine: No problem |
| 22:13 | <jgraham> | Just note that in the description |
| 22:13 | jgraham | can't get the page to load from the permalink for some reason |
| 22:14 | <espadrine> | Hixie: http://jseed.sourceforge.net/bugs/bugCan.html |
| 22:20 | <Hixie> | can you add a document.body.appendChild(img) |
| 22:22 | <Hixie> | so that we can see if it's loading right? |
| 22:23 | <espadrine> | Hixie: That does it for Chrome dev. http://jseed.sourceforge.net/bugs/bugCan.html |
| 22:23 | <espadrine> | Opera does not trigger the onload event for SVG images, on the other hand. |
| 22:23 | <Hixie> | does what? |
| 22:23 | <Hixie> | still isn't painting |
| 22:24 | <Hixie> | weird |
| 22:24 | <Hixie> | OH! |
| 22:24 | <Hixie> | dude |
| 22:24 | <espadrine> | Hixie: it is painting for me on Opera. |
| 22:24 | <Hixie> | "''" isn't a valid argument to createPattern() |
| 22:25 | <Hixie> | though 'repeat' should be assumed so that shouldn't be it |
| 22:25 | <espadrine> | Yes it is! It is the same as null and "repeat" |
| 22:25 | <Hixie> | hm |
| 22:25 | <Hixie> | no, it's not valid |
| 22:25 | <Hixie> | "The second argument must be a string with one of the following values: repeat, repeat-x, repeat-y, no-repeat." |
| 22:25 | <Hixie> | other values are non-conforming, though '' is treated as 'repeat' for some reason |
| 22:25 | <espadrine> | Right. It is "tolerated". |
| 22:25 | <Hixie> | it's invalid |
| 22:25 | <Hixie> | but anyway, it shouldn't affect this |
| 22:26 | <espadrine> | It doesn't (I just changed the uri). |
| 22:28 | <Hixie> | does it work if you use a png instead of an svg? |
| 22:30 | <espadrine> | Yes. |
| 22:30 | <Hixie> | must just be poor support for SVG then |
| 22:37 | <espadrine> | Maybe IE9 is the only browser to render it well, I cannot test it. |
;%0Ac.save();%0A%0Avar%20img%20%3D%20new%20Image();%0Aimg.src%20%3D%20'http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg';%0Ac.fillStyle%20%3D%20c.createPattern(img,'');%0Ac.fillRect(0,0,c.canvas.width,c.canvas.height);%0A%0Ac.restore();%0A){kind=link}
;%0Ac.save();%0Avar%20img%20%3D%20new%20Image();%0Aimg.src%20%3D%20'http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg';%0Aimg.onload%20%3D%20function()%20{%0Ac.fillStyle%20%3D%20c.createPattern(img,'');%0Ac.fillRect(0,0,c.canvas.width,c.canvas.height);%0A}%0Ac.restore();%0A){kind=link}