| 02:06 | <Hixie> | so tempted to test E4X in Acid3 |
| 02:09 | <jruderman> | eww |
| 02:09 | <jruderman> | i'm not a fan of E4X |
| 02:10 | <jruderman> | do you test trailing commas in array literals and object literals? |
| 02:11 | <Hixie> | yup |
| 02:12 | <Hixie> | test 81 |
| 02:12 | <Hixie> | at least, i do for array literals |
| 02:12 | <Hixie> | how should i test it for oject literals? |
| 02:14 | <eseidel> | { "foo": "bar",} ? |
| 02:15 | <Hixie> | but how do i test it? |
| 02:15 | <Hixie> | what's the failure condition? |
| 02:15 | <eseidel> | eval? for a parse error? |
| 02:15 | eseidel | doesn't know |
| 02:15 | <Hixie> | oh, there are browsers that have parse errors with that? |
| 02:15 | <Hixie> | wow |
| 02:15 | Hixie | tests |
| 02:16 | <eseidel> | Hixie: I doubt there are |
| 02:17 | eseidel | doesn't understand what support would mean other than not erroring out |
| 02:17 | Hixie | can't find object literals in es3 |
| 02:20 | <Hixie> | so uh |
| 02:20 | <Hixie> | {a:0,} is illegal |
| 02:21 | <Hixie> | safari and opera allow it |
| 02:21 | <Hixie> | firefox and ie throw |
| 02:24 | <othermaciej> | Hixie: are you sure? |
| 02:24 | <othermaciej> | javascript:alert({a:0,}) |
| 02:24 | <othermaciej> | that works for me in Firefox |
| 02:25 | <Hixie> | what does it alert? |
| 02:25 | <Hixie> | http://software.hixie.ch/utilities/js/js-eval-window/ for {a:0,} raises a SyntaxError for me |
| 02:25 | <othermaciej> | [object Object] |
| 02:25 | <othermaciej> | (it's obviously not a parse error) |
| 02:25 | <othermaciej> | I think the syntax error might be because it parses it as a block |
| 02:25 | <Hixie> | ah indeed |
| 02:26 | <othermaciej> | if you put it in parens I bet it works |
| 02:26 | <Hixie> | yeah |
| 02:26 | <Hixie> | that's what i just did |
| 02:26 | <Hixie> | i'm so not going near this in acid3 |
| 02:26 | <othermaciej> | Safari and Opera probably are doing extra semicolon insertion |
| 02:26 | <othermaciej> | when parsing as a block |
| 02:26 | <othermaciej> | or something |
| 02:27 | <othermaciej> | actually 0, isn't even a valid comma expression |
| 02:27 | <othermaciej> | I'm not sure why it parses |
| 02:27 | <Hixie> | yeah |
| 03:38 | <jwalden> | Hixie, eseidel: ES4 is making the trailing comma in object literals optional -- and furthermore, it's not a spec violation because the spec explicitly allows extensions to what it considers valid syntax |
| 03:42 | <othermaciej_> | jwalden: by making the optional, you mean, making it optional for implementations, or optional for code (i.e. mandatory for implementations to support) |
| 03:44 | <jwalden> | othermaciej: right now the spec grammar doesn't allow them; ES4 will allow them to be present (but have no semantic effect) |
| 03:45 | <othermaciej> | jwalden: by "right now" you mean ES3, right? |
| 03:45 | <othermaciej> | and the ES4 grammar will allow them? |
| 03:45 | <jwalden> | othermaciej: yes |
| 03:45 | <jwalden> | yes |
| 03:45 | <jwalden> | allow in the same way that the trailing comma in an array literal is allowed to be present but otherwise has no effect (in the absence of any other trailing commas, that is) |
| 03:45 | <jwalden> | so 1 === [1,] and 2 === [1,2,] |
| 03:46 | othermaciej | hopes ES4 has a work-in-progress spec draft to reference soon |
| 03:46 | <jwalden> | brendan follows rather more closely than I do; I don't know the state of what's publicly published as of yet |
| 03:47 | <jwalden> | er, with .length after those examples |
| 03:49 | <othermaciej> | yeah I know how commas in array literals work |
| 03:49 | <othermaciej> | and I think everyone now implements trailing commas in object syntax too |
| 03:51 | <jruderman> | i think IE still rejects object literals with trailing commas |
| 03:52 | <jruderman> | but since it isn't covered by a 2004-or-earlier spec, i guess it's out for acid3 |
| 03:52 | <jruderman> | too bad, that one annoyed me ;) |
| 03:56 | <jwalden> | Opera threw a SyntaxError for awhile; lemme track down the blog post grumbling about it :-) |
| 03:58 | <jwalden> | http://my.opera.com/hallvors/blog/show.dml/26650 |
| 04:01 | <jwalden> | Hixie: oh, on commas: another test which Firefox fails is javascript:alert(1 in [0, , 2] ? "FAIL" : "PASS") |
| 04:10 | <othermaciej> | I bet Microsoft's JS compatibility document would be a goldmine of JS bugs in all browsers |
| 04:10 | <othermaciej> | (have they posted that publicly anywhere?) |
| 04:11 | <othermaciej> | linked here as a PDF: http://blogs.msdn.com/jscript/archive/2007/10/29/ecmascript-3-and-beyond.aspx |
| 04:15 | <jruderman> | othermaciej++ |
| 04:16 | <othermaciej> | I mean, they conveniently documented their bugs for the world to see |
| 04:16 | <othermaciej> | so that's handy |
| 04:17 | <jruderman> | exactly |
| 04:20 | <MacDome> | othermaciej: holy crap, they've documented our bugs too! |
| 04:22 | <jwalden> | yeah, that thing was amazing |
| 04:23 | <jwalden> | also because it exactly laid out just how much IE's JS sucks :-) |
| 04:26 | <othermaciej> | in some cases I think the IE behavior should just be declared correct, but it's hard to tell which way is more of a compat issue sometimes |
| 04:27 | <othermaciej> | some of the things they label as "deviations" are actually technically unspecified |
| 04:27 | <othermaciej> | perhaps also vice versa |
| 04:29 | <othermaciej> | oh, I guess I missed the section break actually |
| 04:34 | <jruderman> | what's the highest possible score in the current version of acid3? |
| 04:35 | <gavin> | 100% |
| 04:35 | <gavin> | incomplete tests are treated as passes, afaik |
| 04:35 | <gavin> | non-existent, I should say |
| 04:35 | <jruderman> | oh, wow, gecko and webkit have a ways to go then ;) |
| 04:51 | <Hixie> | jwalden: where in the spec does it say what should happen for that? |
| 04:52 | <jwalden> | gnarliness in 11.1.4, sec |
| 04:58 | <othermaciej> | Hixie: you should check out the Microsoft compat document I linked |
| 05:04 | <jwalden> | https://bugzilla.mozilla.org/show_bug.cgi?id=260106 while I'm tracking through to find the exact details |
| 05:06 | <jwalden> | The production Element List: ElementList , ElisionAssignment Expression is evaluated as follows: |
| 05:07 | <jwalden> | step 2 is "Evaluate Elision_opt, if not present use the value zero" |
| 05:07 | <jwalden> | (insert "_opt " after the first "Elision" two lines ago) |
| 05:08 | <jwalden> | and then step 6 calls [[Put]] with arguments (Result(2) + Result(5)) and Result(4) |
| 05:08 | <jwalden> | 4 calculates the element's value |
| 05:08 | <jwalden> | Result(5) is the length of the partially-constructed array |
| 05:08 | <jwalden> | Elision is evaluated as "Return the numeric value 1" |
| 05:09 | <jwalden> | so an elision shifts all inserted values up an index, but it doesn't result in any value being inserted at the elided index |
| 05:09 | <jwalden> | so that index/property is not present, so |index in array| should be false |
| 05:09 | <jwalden> | Hixie: ^ |
| 05:23 | <MacDome> | jruderman: the nightlies are OK at acid3 |
| 05:23 | <MacDome> | jruderman: there were like 17 fixes or something since 3.0.4 |
| 05:23 | <MacDome> | jruderman: still awful :) |
| 05:23 | <MacDome> | but better than 3.0.4 |
| 05:24 | <MacDome> | Hixie: the blog comments also list more bugs :) |
| 05:26 | <jruderman> | MacDome: cool |
| 05:29 | <jruderman> | eep, at 14%, both webkit trunk and firefox trunk hang for a bit |
| 05:30 | <jruderman> | webkit trunk gets 71% and firefox trunk gets 67%. not that it means anything, since hixie is taking bug suggestions from both teams ;) |
| 05:32 | <jruderman> | it triggers |
| 05:32 | <jruderman> | ###!!! ASSERTION: ReplaceElementAt(negative index): 'aIndex >= 0', file nsVoidArray.cpp, line 491 |
| 05:32 | <jruderman> | nice |
| 05:32 | <jruderman> | might be https://bugzilla.mozilla.org/show_bug.cgi?id=378969 |
| 05:33 | <jruderman> | which appears to be a TreeWalker bug |
| 05:33 | <jwalden> | jruderman: see the spreadsheet, known |
| 05:33 | <jruderman> | the spreadsheet? |
| 05:34 | <jwalden> | jruderman: and the "hang" is Hixie triggering GC |
| 05:34 | <jwalden> | bug acid3 |
| 05:34 | <jwalden> | lemme add you to the editor list, actually |
| 05:40 | <jwalden> | the instability of the numbering isn't helping things all that much :-) |
| 05:41 | <jruderman> | hehe |
| 05:41 | <jruderman> | maybe we can convince hixie to give them names instead of numbers? |
| 05:42 | <jwalden> | it's also fun sometimes to load it and get a random debugging alert that halts the test :-) |
| 05:42 | <jwalden> | possibly |
| 05:42 | <jwalden> | although that just means it's harder to find specific tests in the source |
| 05:43 | <jwalden> | don't think there's a good solution here no matter how it's cut |
| 05:43 | <jwalden> | and this will all be immaterial when it's actually finished |
| 05:44 | <jruderman> | wow, that GC thing is evil |
| 05:44 | <jruderman> | var loops = (((new Date()).valueOf() - 1.07e12) / 32e9) * 0x800; // increases linearly over time |
| 05:45 | <jwalden> | oh, it's ghastly all right |
| 05:45 | <jruderman> | and a kungFuDeathGrip!?!?!? |
| 05:45 | <jwalden> | on the other hand...kungFuDeathGrip! |
| 05:45 | <jwalden> | haha |
| 05:46 | <jwalden> | you can't possibly not love the name |
| 05:52 | <Hixie> | jwalden: k |
| 05:54 | <Hixie> | jruderman: the tests sometimes get merged, too |
| 05:54 | <Hixie> | jruderman: (and more rarely, split) |
| 05:54 | <Hixie> | jruderman: (and sometimes removed altogether) |
| 05:54 | <jruderman> | k |
| 05:55 | <Hixie> | the GC thing is pretty evil, but i like the idea of sliding a perf test for DOM manipulation into the middle of the test there :-) |
| 05:55 | <Hixie> | safari does way better on that perf test than firefox at the moment |
| 05:56 | <othermaciej> | jwalden: I think Mozilla has that name all over internally |
| 05:56 | <jwalden> | Hixie: btw, the parens around |new Date()| aren't needed, as whatever's new'd ends at the first pair of parens |
| 05:56 | <othermaciej> | (kungFuDeathGrip) |
| 05:56 | <Hixie> | jwalden: interesting |
| 05:56 | <Hixie> | othermaciej: yeah, that's where i got the name from |
| 05:56 | <othermaciej> | we usually call variables for that same purpose "protect" or "protector" or something |
| 05:57 | <Hixie> | kungFuDeathGrip is so much more vivid a variable name |
| 05:57 | <Hixie> | jruderman: any idea what test triggers the assert? |
| 05:57 | <jwalden> | Hixie: jruderman could tell you all about that (or maybe he should have brendan tell you, seeing as brendan spent so much quality time on such issues somewhat recently) :-) |
| 05:57 | <othermaciej> | shich part of the test is secretly a perf test? |
| 05:57 | <jwalden> | Hixie: it's the treewalker test with currentNode mutations; the assert doesn't have any bad side effects |
| 05:57 | <othermaciej> | *which |
| 05:58 | <Hixie> | othermaciej: test 26, the part that attempts to force a GC |
| 05:58 | <Hixie> | (and which will do more and more loops with each passing day) |
| 05:58 | <jwalden> | or at least that's which one it appears to be based on inspection+stack of the assertion |
| 05:58 | <Hixie> | (though i really should increase the number of loops quadratically to take into account moore's law) |
| 05:59 | <jruderman> | Hixie: the spreadsheet says which test it is |
| 05:59 | <Hixie> | jwalden: k |
| 05:59 | <othermaciej> | Hixie: is it because the bug it is testing for fails only when a GC happens? |
| 05:59 | <Hixie> | jruderman: there's a spreadsheet? |
| 05:59 | <othermaciej> | moore's law does not apply to RAM bandwidth |
| 05:59 | <Hixie> | othermaciej: yeah |
| 05:59 | <jruderman> | Hixie: http://spreadsheets.google.com/pub?key=pNgBCwWdyRTT2JeiZn4B2Yw |
| 05:59 | <jruderman> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=acid3 links to it |
| 06:00 | <jwalden> | that bug needs another URL field |
| 06:00 | <Hixie> | jruderman: cool |
| 06:00 | <jruderman> | jwalden: hah |
| 06:01 | <Hixie> | jruderman: the tests from 49 to 80 massively changed numbers recently, btw |
| 06:01 | <Hixie> | basicaly bucket 5 is empty right now |
| 06:01 | <Hixie> | i merged what was 4 and 5 into 5 |
| 06:02 | <jruderman> | how do you decide how large each test should be? (wrt splitting / merging) |
| 06:03 | <jwalden> | Hixie: the earlier test numbers changed, too, probably a bit less, but I fixed them in the last hour or so :-) |
| 06:04 | <Hixie> | jruderman: judgement call, but basically i'd like each test to fail in at least one browser, and the more browsers fail each test the better |
| 06:04 | <jruderman> | hah |
| 06:04 | <jruderman> | if we fix a bug too soon, will it be removed from acid3 and replaced by something else? |
| 06:06 | <Hixie> | you can't fix a bug too soon |
| 06:07 | <Hixie> | however, if a test ends up not failing in any browser before the test is done, it might get replaced, if i can find something better |
| 07:37 | <kig> | having written my own isPointInPath is proving to be a clairvoyant decision |
| 07:38 | <kig> | screw browsers, they can't be trusted anyhow |
| 10:42 | <hsivonen> | Hixie: regarding iframe fallback content: should the fallback be expected to be targeted at Netscape 4 or is HTML5 meant to bless Opera-style disabling of iframes? |
| 10:44 | <Hixie> | i hadn't really thought about it |
| 10:44 | <hsivonen> | hmm. I wonder if someone should write a spec for Gecko's DTD catalog behavior so that the behavior could be considered grandfathered |
| 10:44 | <Hixie> | what difference does it make for you? |
| 10:45 | <hsivonen> | Hixie: If the parser has to treat it as CDATA and the validation layer needs to reparse it as markup, the cost/utility ratio of the whole thing is going to be seriously bad |
| 10:46 | <hsivonen> | Hixie: it is far easier to either parse it as markup the first time round or to do what is done now: parse as CDATA and not to place any conformance constraints on the text |
| 10:46 | <Hixie> | yeah i dunno |
| 10:46 | <Hixie> | i'm tempted to just say it shoul be the empty string |
| 10:47 | <Hixie> | but i dunno |
| 10:47 | <hsivonen> | as for the DTD catalog thing, I have long had an idea shelved away about validator support |
| 10:47 | <hsivonen> | that is, I could add a parser mode with Gecko DTD catalog emulation |
| 10:47 | <Hixie> | we can't parse as markup the first time around (i.e. we need to have a reparse stage somehow) because otherwise the DOM might not match reality, as it were |
| 10:47 | <hsivonen> | but I'm not sure if it would be worthwhile and Good for the Web |
| 10:48 | <hsivonen> | Hixie: OK, in that case, do we really care about checking the iframe contents? |
| 10:48 | <Hixie> | but if we allow <script> in the <iframe> contents, we're screwed in oh so many ways |
| 10:48 | <Hixie> | i dunno |
| 10:48 | <hsivonen> | wow. good point |
| 10:48 | <Hixie> | if we don't care, i'm just gonna require it be blank |
| 10:49 | <Hixie> | is <iframe> support widespread enough? |
| 10:49 | <Hixie> | (lynx, etc?) |
| 10:49 | <hsivonen> | can authors put a <script> in there and annoy Opera users who disable iframes? |
| 10:49 | <Hixie> | i have no idea what oepra does |
| 10:50 | <hsivonen> | Hmm. I haven't used Lynx for real browsing in a long time |
| 10:50 | <othermaciej> | DTD catalog? |
| 10:50 | othermaciej | read the logs |
| 10:50 | <othermaciej> | I guess I should google it |
| 10:50 | <Hixie> | othermaciej: the list of bugs that microsoft put out has some bugs (things that they claim are bugs but are in fact not) |
| 10:51 | <hsivonen> | othermaciej: lxr.mozilla.org :-) |
| 10:51 | <othermaciej> | Hixie: you should wait for their list of bugs, SP1 |
| 10:51 | <Hixie> | hehe |
| 10:51 | <hsivonen> | othermaciej: Gecko hard-wires certain public IDs to certain bogo-DTDs that only list character entities |
| 10:52 | <hsivonen> | othermaciej: and real Web content out there depends on it |
| 10:52 | <othermaciej> | awesome |
| 11:02 | <hsivonen> | othermaciej: http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/nsExpatDriver.cpp#285 that's the magic list |
| 11:03 | <hsivonen> | FWIW, I don't like the "resource://gre/res/mathml.css" bit at all |
| 11:05 | <othermaciej> | hsivonen: hey, it's your fault! |
| 11:06 | <othermaciej> | (WebKit has some hardcoded suport for HTML entities in XHTML content, probably because of that) |
| 11:06 | <hsivonen> | othermaciej: my fault? |
| 11:06 | <othermaciej> | oh, sorry |
| 11:06 | <othermaciej> | I saw you listed as the only "Contributor" |
| 11:07 | <othermaciej> | and forgot that there's also an "Original Code" statement |
| 11:08 | <othermaciej> | it's heikki's fault (whoever that is, sounds Finnish though) |
| 11:09 | <Hixie> | http://markus.fischer.name/about/archives/2005/10/17/ie-having-fun-with-js-and-links/ |
| 11:10 | <Hixie> | weirdest IE7 bug ever |
| 11:11 | <othermaciej> | Hixie: holy toledo |
| 11:12 | <Hixie> | that's going in acid3 for sure |
| 11:12 | <OmegaJunior> | Yet another reason to hate MSIE |
| 11:14 | <othermaciej> | I don't even understand how that bug could happen |
| 11:14 | <othermaciej> | it has to be somehow on purpose |
| 11:15 | <Hixie> | that's now test 99 |
| 11:17 | <Hixie> | 19 bugs to go |
| 11:27 | <Hixie> | ok, i have 16 tests to write |
| 11:27 | <Hixie> | all on one topic |
| 11:27 | <Hixie> | i could cave and test svg |
| 11:27 | <Hixie> | or i could test a more modern spec that we really want implemented |
| 11:28 | <Hixie> | or i could test e4x |
| 11:28 | <Hixie> | any preferences? |
| 11:28 | <Hixie> | i could test xbl2 :-) |
| 11:29 | <othermaciej> | is e4x a desirable thing to have implemented? |
| 11:29 | <othermaciej> | we don't consider WebKit's lack of support a bug |
| 11:30 | Philip` | almost wants DOM3 XPath |
| 11:31 | <othermaciej> | unfortunately that one is only a Note |
| 11:31 | <Philip`> | The previous version is a CR, though |
| 11:32 | <othermaciej> | so Note was just the way to abandon it before REC? |
| 11:32 | <othermaciej> | I'm actually not sure if WebKit's XPath API is that one or only the nonstandard IE stuff |
| 11:33 | <Philip`> | "The W3C DOM Working Group participants do not expect to provide two interoperable implementations of this module, /using the same binding/." |
| 11:33 | <Philip`> | Not quite sure what that means |
| 11:33 | <hsivonen> | guessing from package names, Xerces2-J has some kind of XPath DOM API |
| 11:33 | <othermaciej> | I guess they expected one Java one and one JS one |
| 11:33 | <hsivonen> | I'd expect it to be based on some kind of W3C document |
| 11:34 | Philip` | doesn't really care what the API is, as long as it can do "find all elements matching this string" without much effort, and it seems that at least Firefox and Opera can do that in the same way |
| 11:38 | <othermaciej> | I think every major browser has some kind of XPath API |
| 11:38 | <othermaciej> | I am not sure to what extent they match |
| 11:53 | <Hixie> | i like e4x as a compile-time-syntax-checked replacement for innerHTML |
| 12:00 | <Hixie> | i have no idea what to test with these 16 tests |
| 12:00 | <othermaciej> | you mean JS-parse-time instead of HTML-parse-time (on actual use of innerHTML) syntax-checked? |
| 12:00 | <othermaciej> | (cause there is no compile time) |
| 12:00 | <Hixie> | yeah |
| 12:00 | <Hixie> | when the JS is compiled |
| 12:01 | <othermaciej> | JS parse failures tend to be more catastrophic than HTML syntax errors |
| 12:01 | <Hixie> | right, which is why you want to catch them at compile time |
| 12:02 | <Hixie> | either the script compiles, or it doesn't |
| 12:02 | <othermaciej> | if hard failure is desirable, then at least XML's model makes the cause of the failure obvious |
| 12:03 | <othermaciej> | script parse errors make the page break with no meaningful error message displayed normally |
| 12:03 | <Hixie> | manipulating markup as strings is a horrible way to work |
| 12:03 | <othermaciej> | that's true |
| 12:03 | <Hixie> | manipulating markup as DOM objects is a horrible way to work |
| 12:03 | <Hixie> | E4X provides a third option, that imho is not quite so horrible |
| 12:04 | <Hixie> | (however, given its status as quite controversial, it obviously doesn't belong in acid3) |
| 12:04 | <Hixie> | i don't know what to test in bucket 5 though |
| 12:04 | <othermaciej> | but using XML literals as part of a language syntax is gross |
| 12:04 | <Hixie> | eh |
| 12:04 | <othermaciej> | and no one implements it in a useful way anyway |
| 12:04 | <Hixie> | no more gross than using numeric literals, imho |
| 12:05 | <Hixie> | i agree that mozilla's implementation is dumb |
| 12:05 | <othermaciej> | <, = and " already have meaning in JS |
| 12:05 | <Hixie> | svg is the only thing i can think of and i really don't want to test the svg dom in acid3 |
| 12:05 | <Dashiva> | heredoc xml next stop? |
| 12:05 | <othermaciej> | something with a clear delimiter would be better |
| 12:06 | <othermaciej> | so I'd actually be more excited about heredoc xml |
| 12:06 | <othermaciej> | Hixie: do you have XML tests? |
| 12:06 | <Hixie> | othermaciej: like what? |
| 12:06 | <othermaciej> | (XML DOM on actual XML documents) |
| 12:07 | <othermaciej> | presence of HTML dom on XHTML documents might be interesting too |
| 12:07 | <othermaciej> | although that's kind of in the "gratuitously mean to IE" category |
| 12:08 | <Hixie> | i have some dom2 xml tests |
| 12:09 | <Hixie> | that use the xhtml namespace |
| 12:09 | <Hixie> | i'm not sure i can come up with 16 more |
| 12:10 | <hsivonen> | othermaciej: I don't think it is gratuitously mean |
| 12:11 | <othermaciej> | ah, shit, Mac IE somehow made itself the default application for XHTML on my new laptop |
| 12:11 | <hsivonen> | othermaciej: I had a good-faith script that wasn't trying to expose any bugs that failed in WebKit in XHTML, because WebKit didn't do all the HTML DOM stuff on the XHTML side |
| 12:11 | <othermaciej> | yeah, I'm trying to remember if we fixed that yet in trunk |
| 12:11 | <othermaciej> | and whether it was broken in Safari 3 |
| 12:12 | <hsivonen> | the great December content model change leads to the deletion of a lot of code... |
| 12:13 | <Hixie> | well i'll work something out tomorrow for this remaining bucket of 16 tests |
| 12:13 | <Hixie> | (suggestions welcome) |
| 12:14 | <Hixie> | nn |
| 12:18 | <othermaciej> | yeah, HTMLDocument in xhtml works in WebKit trunk (though not in Safari 3) |
| 12:22 | <hsivonen> | othermaciej: nice. thanks |
| 12:23 | <othermaciej> | (we did support HTML element interfaces on xhtml elements already) |
| 12:26 | <othermaciej> | the way the E4X spec is written is weird |
| 12:30 | <hsivonen> | fun fun fun: fixing all the test cases that testing bimorphic stuff |
| 14:00 | <zcorpan> | wtf... https://www.tdnam.com/trpItemListing.aspx?miid=10238899 |
| 14:02 | <othermaciej> | did whatwg itself formerly have the .com? |
| 14:03 | <zcorpan> | don't think so |
| 14:18 | <zcorpan> | Hixie: please test svg in acid3... not necessarily the weird svg udom parts, but basic support and support for svg in <img> and 'background' would be nice |
| 14:20 | <zcorpan> | without svg in 'background', svg is basically unusable for layout purposes |
| 14:21 | <zcorpan> | this is way more requested by authors than e4x |
| 14:21 | <zcorpan> | (in fact, i think no-one even cares about e4x) |
| 14:22 | <zcorpan> | see e.g. http://www.sitepoint.com/forums/showthread.php?t=523315 |
| 14:25 | <othermaciej> | zcorpan: using SVG in CSS backgrounds is pretty bleeding-edge and not clearly justified by any spec that has ever reached CR |
| 14:25 | <othermaciej> | zcorpan: that being said I do think it is a really good feature |
| 14:26 | <OmegaJunior> | I think internal builds of Opera 9.5 have an implementation of exactly that. |
| 14:27 | <othermaciej> | WebKit trunk has an implementation of it as well |
| 14:28 | Philip` | wondered why his page was using the incorrect font size inside <table>s, and then realised he had written <DOCTYPE HTML> |
| 14:28 | <othermaciej> | (ain't just internal) |
| 14:28 | <Philip`> | (so quirks mode is not much fun even when I'm specifically trying to avoid using it) |
| 14:29 | <Philip`> | OmegaJunior: Non-internal Opera 9.5 alphas/betas have that too |
| 14:31 | <othermaciej> | WebKit even suports svg images in -webkit-border-image |
| 14:32 | <Philip`> | Does WebKit support SVG images in canvas drawImage? |
| 14:32 | <othermaciej> | if they are in an <img> tag I'm sure it does |
| 14:33 | <Philip`> | Including SVG with foreignContent? |
| 14:33 | <othermaciej> | I don't think it supports drawImage of an <svg> element |
| 14:33 | <othermaciej> | foreignObject you mean |
| 14:33 | <Philip`> | Oops, yes |
| 14:33 | <othermaciej> | I don't see why that wouldn't work, though I haven't tried it myself |
| 14:34 | <othermaciej> | it can certainly render svg in an img or as a CSS image if it embeds non-SVG markup |
| 14:34 | <othermaciej> | I guess you could use that as a very cheesy way to get text rendering in <canvas> |
| 14:35 | <Philip`> | Does it attempt to avoid security issues, like by preventing toDataURL / getImageData after you've drawn an SVG image? |
| 14:35 | <Philip`> | If not, that may be a potential problem :-) |
| 14:36 | <othermaciej> | we don't have toDataURL or getImageData (yet) |
| 14:36 | <othermaciej> | so not an issue |
| 14:36 | <Philip`> | Oh, good point |
| 14:36 | <othermaciej> | I imagine SVG images would be subject to the same security restrictions for those purposes as regular type images |
| 14:40 | <Philip`> | othermaciej: That might be inadequate, because it'd still let you e.g. move an <input type=file> into a same-origin SVG image and then render it onto a canvas and read the pixels to extract the file path and circumvent the browser's attempts at privacy |
| 14:40 | <OmegaJunior> | Hmm... can svg be used to draw real 3d objects? or are they mere simulations in 2d? I can imagine a conflict. |
| 14:41 | <OmegaJunior> | A conflict with getContext() |
| 14:41 | <othermaciej> | Philip`: you can read the value of <input type="file"> through the DOM |
| 14:42 | <othermaciej> | noted however that there may be security ieeus |
| 14:43 | <othermaciej> | OmegaJunior: it doesn't have real 3d, though you can sort of simulate it by moving polygons around in 2d |
| 14:43 | <OmegaJunior> | Good |
| 14:43 | <Philip`> | othermaciej: Oh, maybe I'm misremembering - Opera only returns the filename (not the displayed path) but FF and IE6 still seem to return the whole path |
| 14:44 | <othermaciej> | Safari doesn't even display the full path |
| 14:44 | <othermaciej> | (it doesn't have a type-in box for <input type="file">) |
| 14:45 | <Philip`> | (Hmm, Opera 9.2 draws a peculiar button for http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cbutton%3ETest%20test_test_test_test%3C%2Fbutton ) |
| 14:45 | <Philip`> | OmegaJunior: I'm not sure what you mean by "a conflict" |
| 14:47 | <Philip`> | (http://apike.ca/prog_svg_threed.html says "SVG has no 3D support. In fact, it is almost anti-3D.", which sounds possibly true - I don't remember seeing anything more advanced than a 3D cube in SVG) |
| 14:47 | <OmegaJunior> | Well, the mozilla tutorial I'm reading says only the 2d context is defined. The 3d context is theoretical at best. If SVG is used to display something in a canvas element, it will need to get a context. Following the tutorial, it will be a 2d context. However, if the SVG has 3d, it needs a 3d context. Hence the conflict. Since SVG does not do 3d, the conflict does not exist. |
| 14:49 | <Philip`> | OmegaJunior: Even if SVG did 3D things, SVG would describe how it's converted into a flat rectangular 2D bitmap, and that bitmap can be drawn onto a 2D canvas, so there wouldn't be a problem |
| 14:49 | <OmegaJunior> | Exactly. |
| 14:50 | <Philip`> | (The 3D context isn't really theoretical, given that there's at least two attempted implementations :-) ) |
| 14:50 | <OmegaJunior> | Really? Awesome. |
| 14:50 | <Philip`> | http://blog.vlad1.com/2007/11/26/canvas-3d-gl-power-web-style/ |
| 14:50 | <othermaciej> | this has some neat pseduo-3d in svg: http://www.lutanho.net/svgvml3d/index.html |
| 14:50 | <Philip`> | http://my.opera.com/timjoh/blog/2007/11/13/taking-the-canvas-to-another-dimension |
| 14:51 | <OmegaJunior> | OpenGL did come to mind, yes. Especially for web games. |
| 14:51 | <othermaciej> | (the rubik's cube one is neat) |
| 14:53 | <Philip`> | othermaciej: Aha, that looks better than plain cubes :-) |
| 14:53 | <Philip`> | It flickers a bit nastily in Firefox while redrawing, though |
| 14:53 | <othermaciej> | http://www.kevlindev.com/geometry/3D/js3d/index.htm |
| 14:54 | <Philip`> | Bah, wireframe is cheating :-p |
| 14:58 | zcorpan | would appriciate feedback about http://simon.html5.org/specs/xml-stylesheet5 from webkit and mozilla people |
| 15:01 | <othermaciej> | is it substantively different from the current xml-stylesheet PI spec? |
| 15:02 | <zcorpan> | it is pretty much aligned with firefox/ie/safari, actually |
| 15:03 | <zcorpan> | the parsing part is aligned mostly with firefox, i think |
| 15:03 | <othermaciej> | I'm not sure what this means: "When the UA is to stop parsing, it must return pseudo-attributes so that the appropriate semantics can be applied." |
| 15:03 | <othermaciej> | I think the syntax would be better expressed as a BNF grammar than a state machine |
| 15:04 | <zcorpan> | yeah, i don't know how to phrase that sentence |
| 15:04 | <zcorpan> | ok. but can BNF express how to handle error conditions? |
| 15:05 | <zcorpan> | for some errors you just drop the pseudo-attribute, for others you ignore the rest of the PI |
| 15:07 | <zcorpan> | stop parsing means basically... stop the state machine and return pseudo-attributes. is that clearer? |
| 15:10 | <othermaciej> | I'm not sure "return" is the right word |
| 15:10 | <othermaciej> | writing this in such an operational style makes it hard for me to follow |
| 15:10 | <othermaciej> | may review more later but not right now |
| 15:10 | <zcorpan> | ok |
| 15:10 | <zcorpan> | thanks |
| 15:11 | <othermaciej> | (gotta admit ?xml-styleshet? PI interop isn't that high on my personal priority list) |
| 15:11 | <zcorpan> | yeah, but the parsing part also applies to access-control and xbl |
| 15:12 | <othermaciej> | it would really be better if XML PIs applied XML-style draconian parsing to PI pseudo-attributes, just as if they were XML element attributes |
| 15:13 | <othermaciej> | that would be more consistent |
| 15:13 | <othermaciej> | I don't know if that creates compatibility issues for ?xml-stylesheet? specifically |
| 15:15 | <Philip`> | Does anyone know how current content relies on PI parsing? |
| 15:16 | <othermaciej> | I don't think there is that much CSS-styled XML on the web in general |
| 15:16 | <othermaciej> | (I guess the PI can also request XSLT processing, which may be more common; dunno) |
| 15:17 | Philip` | sees things like <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> |
| 15:17 | <Philip`> | (in text/html documents) |
| 15:19 | <othermaciej> | looks like that syntax might be part of an obsolete version of Namespaces in XML: http://www.w3.org/TR/1998/WD-xml-names-19980518 |
| 15:20 | <othermaciej> | nowadays use of that syntax would not be namespace-well-formed |
| 15:22 | <OmegaJunior> | Knowing the vendor, that means our parsers and validators have to allow for their kinks. |
| 15:22 | <othermaciej> | if that's in text/html content I am not sure it has much bearing on what needs to be allowed in XML |
| 15:23 | <OmegaJunior> | Hopefully none |
| 15:26 | <Philip`> | <?xml version=\"1.0\" encoding=\"UTF-8\"?> |
| 15:26 | <Philip`> | <?xml-stylesheet type=\"text/css\" href=\"css/standard.css\"?> |
| 15:26 | <Philip`> | on http://www.kletterzentrum-badtoelz.de/ though that redirects immediately away from there anyway |
| 15:26 | <Philip`> | Does xml-stylesheet ever do anything in text/html? |
| 15:27 | <OmegaJunior> | Yes, it works perfectly in Internet Explorer |
| 15:27 | <OmegaJunior> | (Tried it) |
| 15:28 | <OmegaJunior> | Remember that Internet Explorer doesn't do application/xhtml+xml, so anything that resembles html or xhtml will have to be sent as text/html |
| 15:28 | <OmegaJunior> | Hopefully this will change with MSIE8, but I doubt it. |
| 15:28 | <OmegaJunior> | As a result, MSIE renders xhtml as tag soup. |
| 15:32 | <Philip`> | http://philip.html5.org/data/pis.html is everything starting with "<?" in ~15K pages |
| 15:41 | <Philip`> | http://www.montere.it/ - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 Transitional//IT" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">; - hmm, not quite the right idea there |
| 15:52 | <kig> | hmm |
| 15:59 | <kig> | this'll be either difficult, slow, or a pain |
| 16:00 | <Philip`> | That's not too bad, if it's 'either' rather than all |
| 16:00 | <kig> | (drawing and animating a full-screen svg on canvas) |
| 16:01 | <kig> | difficult: only redraw portions that have changed |
| 16:01 | <kig> | slow: redraw everything |
| 16:02 | <kig> | pain: manually split document into layers, render them into images and hope that the html image renderer is faster than the canvas one |
| 16:03 | <Philip`> | Given the performance of background-position:fixed, I don't think I'd trust the browser to render layers fast |
| 16:04 | <Philip`> | (at least when the layers are moving relative to each other) |
| 16:04 | <Lachy> | wow, what a great example of why RDFa is a bad idea. http://www.w3.org/QA/2008/01/rdfa_and_html_imagemap.html - That's so complex and unnecessary. The SVG effect could be done entirely without the RDFa |
| 16:06 | <Philip`> | Lachy: The SVG effects *is* done entirely without the RDFa |
| 16:06 | <Philip`> | (or at least I can't see any RDFa bits in the XSLT code) |
| 16:09 | <hsivonen> | http://dubinko.info/blog/2008/01/07/yahoo-introduces-mobile-xforms/ is that a multi-UA thing or using a W3C spec as part of a single-UA system (like, e.g., Joost)? |
| 16:11 | <Lachy> | Philip`, yes, I know. That's why I said the RDFa wasn't necessary. It's just there as useless metadata |
| 16:16 | <hsivonen> | if a metadatum falls in the forest and there's no one to interpret it, is it a metadatum? |
| 16:17 | <Philip`> | Yes by definition, sine you already said it was a metadatum :-) |
| 16:17 | <Philip`> | *since |
| 16:19 | <Lachy> | hsivonen, I think that should be "if a metadatum falls in the forest and there's no one to interpret it, is it [useful?]" |
| 16:21 | <Philip`> | I assume the problem comes from saying "I'd like a way to say, "this area of the image depicts the person who is the primaryTopic of http://danbri.org/".";, rather than e.g. "I'd like a way to say "who is in this picture?" so that I can stalk people by finding all the photos (on a certain subset of web sites) that are linked to their homepage" |
| 16:24 | <Philip`> | but maybe that's just a simple fundamental difference of perspective, about the value of providing data without prior knowledge of how the data will be used |
| 16:31 | <zcorpan> | othermaciej: opera does drocanian parsing for xml-stylesheet currently |
| 16:31 | <zcorpan> | but i don't think it makes sense |
| 16:31 | <zcorpan> | what do you do when you create or update the PI with script? |
| 16:32 | <zcorpan> | should the xml processor have to know about xml-stylesheet, access-control and xbl? and other future PIs that might use pseudo-attributes? |
| 16:34 | <zcorpan> | speaking of which... i think i'll move the requirement about the placement of the PI from the parsing rules to the processing rules... since future PIs with pseudo-attributes might want to allow them in other places than in the prolog |
| 16:34 | <hsivonen> | zcorpan: by definition, no, but the next layer should |
| 16:36 | <zcorpan> | hsivonen: ok, wrongly phrased... why should the well-formedness of a given document depend on whether the UA supports xml-stylesheet, access-control or xbl? |
| 16:38 | <hsivonen> | zcorpan: well-formedness shouldn't. but rephrasing: why should YSoD depend on support for a particular PI |
| 16:39 | <hsivonen> | the Web is probably better off if there are as few YSoD reasons as possible |
| 16:39 | <zcorpan> | indeed |
| 16:39 | <zcorpan> | that's why my spec removes fatal errors for PIs |
| 16:39 | <hsivonen> | zcorpan: you could, though, be Draconian about what causes a PI to be rejected from further processing |
| 16:40 | <zcorpan> | yes |
| 16:40 | <zcorpan> | <?xml-stylesheet =="" href="a"?> is the same as <?xml-stylesheet?> |
| 17:47 | <kig> | Philip`: http://glimr.rubyforge.org/cake/canvas.html#DesignSketching <- the "pain" approach, not that it's much faster than the "slow" approach (20fps vs 10fps. though, if that were 60fps vs 30fps...) |
| 17:51 | <Philip`> | kig: Opera 9.2 really isn't very good at this :-( |
| 17:51 | <kig> | i can imagine |
| 17:55 | <kig> | might be easiest to make the site an svg document with html on top and a clipped canvas. but. uh. |
| 17:56 | <kig> | that's not going to look nice in firefox |
| 17:56 | <Philip`> | Why not? |
| 17:57 | <kig> | because firefox doesn't double-buffer svgs |
| 17:58 | <Philip`> | Ah |
| 17:58 | <kig> | (and i'd like to stay as far away from the <object>-tag as humanly possible) |
| 17:59 | <Philip`> | You could just use a PNG ;-) |
| 18:07 | <kig> | or wmv.. |
| 18:07 | <Philip`> | You can use APNG to do things like slowly-fading-out trails, in a not-too-inefficient way |
| 19:35 | <kig> | creating fewer arrays per frame sure reduces GC runs |
| 19:36 | <kig> | reusing a matrix arrays now.. |
| 19:36 | <kig> | -a |
| 19:40 | <Philip`> | You should avoid the GC entirely by packing all your data structures into integers |
| 19:41 | <Philip`> | Store two 10.5 fixed-point values per variable, use three variables per matrix, and it'll work perfectly! |
| 19:41 | <kig> | ssss |
| 19:41 | <kig> | sounds like a plan! |
| 19:42 | <kig> | i thought of writing a temp object allocator |
| 19:42 | <Philip`> | (How are you detecting the number of GC runs?) |
| 19:43 | <kig> | by watching the fps histogram when running an animation and "hey, it's 0.5fps now, go GC go!" |
| 19:44 | <Philip`> | Oh, okay |
| 19:44 | <Philip`> | Perhaps not quite the most scientific method :-) |
| 19:46 | <kig> | i could automate the fps-watching and draw pretty graphs titled "fps glitches per minute per browser" |
| 19:46 | <kig> | or maybe not bother |
| 19:46 | <Philip`> | I was thinking more of getting the GC system itself to tell you what it's doing |
| 19:46 | Philip` | goes away a bit |
| 19:46 | <kig> | that'd be harder :| |
| 19:52 | <kig> | temp array allocator: free-stack and reserved-list, alloc : function() { var a = free.pop(); reserved.push(a); }, free : function(a) { reserved.deleteFirst(a); maybeClear(a); free.push(a); }; all the joys of C with none of the performance |
| 20:20 | <Philip`> | I think I got useful GC numbers out of SpiderMonkey when embedding it into some other application, without too much bother, so perhaps Firefox could be modified a bit to report some numbers |
| 20:20 | <Philip`> | (or maybe it's easier to just use DTrace or something, except I haven't got a clue how to use that) |
| 20:29 | <gsnedders> | Philip`: DTrace for what? JS? |
| 20:30 | <Philip`> | gsnedders: Yes |
| 20:30 | <Philip`> | (particulary garbage collection) |
| 20:31 | <gsnedders> | Philip`: there's a patch for SpiderMonkey out there somewhere, IIRC |
| 20:31 | <gsnedders> | (which of course requires an OS that supports DTrace) |
| 20:32 | <Philip`> | (It's not like many people have Solaris desktops, so you might as well just say "OS X" :-p ) |
| 20:34 | <gsnedders> | Only Leopard :P |
| 20:34 | <gsnedders> | And only OpenSolaris based Solaris builds :P |
| 20:34 | <gsnedders> | (or is DTrace in Solaris 10?) |
| 20:34 | gsnedders | looks up |
| 20:34 | <gsnedders> | seemingly yes |
| 20:36 | <Philip`> | Seems it was in Solaris 10 and not in 9 |
| 20:37 | <Philip`> | except http://www.usenix.org/event/usenix04/tech/general/full_papers/cantrill/cantrill_html/ was before Solaris 10 was released, apparently |
| 20:37 | <Philip`> | (and says it was publicly available at that time) |
| 20:54 | <kig> | Philip`: btw, happen to know a way to do an in_fill check for a bezier path? |
| 21:00 | <eseidel> | Philip`: I think http://apike.ca/prog_svg_threed.html is broken. I think it depends on broken ASV behavior (of running all scripts *after* the document fully loads) |
| 21:03 | <Philip`> | kig: I guess you could do the non-zero-winding thing just with line/Bezier intersections, like http://www.kevlindev.com/gui/math/intersection/Intersection.js intersectBezier3Line, though that sounds a bit inefficient |
| 21:03 | <eseidel> | Philip`: Opera, FF and Safari all fail with that SVG |
| 21:03 | <eseidel> | Philip`: if you believe it's a browser error, we'd love to see a bug filed |
| 21:04 | <Philip`> | eseidel: Hmm, I thought I remembered seeing it working in a sensible browser at some point in the past |
| 21:04 | <kig> | Philip`: thanks, it isn't really speed-critical as i can ditch most paths with a bbox check |
| 21:06 | <Philip`> | eseidel: but I can't get it to work in any browser now, so I'll guess the code is just broken |
| 21:06 | <eseidel> | Philip`: it might work in IE+ASVG |
| 21:06 | <eseidel> | ASV, rather |
| 22:34 | Philip` | wonders how best to handle multiple lights in GLSL |
| 22:49 | jgraham | notes the main network in his department is entirely Solaris-on-the-desktop (though I think they are all running Solaris 9) |
| 22:57 | <Hixie> | zcorpan: svg-in-img and svg-in-background are not scripting tests |
| 22:58 | <kig> | re: JS GC tracking, there any tool to track allocations? want to figure out what i need to fix |
| 22:59 | <kig> | might be floats though.. |
| 23:01 | <eseidel> | Hixie: sadly, he's gone... but they also aren't spec'd yet. WICD is trying :) |
| 23:08 | <Hixie> | WICD is a waste of time |
| 23:08 | <Hixie> | how are they not specced? |
| 23:15 | <eseidel> | Hixie: where are <img src="foo.svg"> and background: foo.svg spec'd? |
| 23:15 | <eseidel> | if not by WICD |
| 23:16 | <Hixie> | HTML, SVG, and CSS |
| 23:16 | <Hixie> | same as <img src="foo.png"> and background: foo.png is specced by HTML, PNG, and CSS |
| 23:17 | <eseidel> | CSS 2.1 does make mention of non-fixed intrinsic sized replaced elements |
| 23:18 | <eseidel> | not sure about background: coverage for non-fixed size images, i'd have to go read more |
| 23:18 | <Hixie> | there may be holes in CSS/SVG/HTML |
| 23:18 | <Hixie> | in which case those specs should be fixed |
| 23:18 | <Hixie> | but that doesn't mean adding a whole new spec |
| 23:18 | <Hixie> | that's just retarded |