| 00:21 | <roc> | hmm |
| 00:22 | <roc> | SVG fonts are fine for Acid3, we'll do those |
| 00:22 | <roc> | SMIL, not so sure :-) |
| 00:23 | <Hixie> | the smil test was contributed by a browser vendor |
| 00:23 | <Hixie> | feel free to contribute a test to make their life hard too :-) |
| 00:25 | <roc> | it's not our lives SMIL makes hell, it's more authors :-) |
| 00:25 | <Hixie> | well |
| 00:25 | <Hixie> | that applies to all of svg |
| 00:25 | <Hixie> | so... |
| 00:25 | <roc> | there is a difference of degree |
| 00:26 | <Hixie> | wow, doctypes have become much more common over the past few years |
| 00:26 | <Hixie> | it was about 50% of pages that had a doctype a year or two ago |
| 00:26 | <Hixie> | now it's 66% |
| 00:27 | <Hixie> | and according to this, most of them are valid (like, ~99%) |
| 00:27 | <Hixie> | valid as in they parse per html5 without syntax errors |
| 00:28 | <Lachy> | Hixie, I find those stats really hard to believe |
| 00:29 | <Lachy> | there must be some mistake or maybe a bias sample |
| 00:30 | <Hixie> | why? |
| 00:32 | <Lachy> | 99% validity just seems way too high |
| 00:33 | <Hixie> | that's 99% of pages that emitted a doctype emitted one that was marked correct |
| 00:33 | <Hixie> | i think that's not that unreasonable given how most will be copy-and-pasted |
| 00:34 | <Hixie> | 28% of all pages were xhtml 1.0 transitional with uri |
| 00:34 | <Hixie> | 10% were html 4.01 transitional without uri |
| 00:35 | <Hixie> | only 66% had a doctype at all, so we're already more than half way there just with the two most common doctypes |
| 00:36 | <Hixie> | 7% are 4.01 transitional without uri |
| 00:36 | <Lachy> | oh, so you're just talking about the correctness of the doctype, not the validity of the whole page? |
| 00:36 | <Hixie> | right |
| 00:36 | <Lachy> | ok. Now it makes sense |
| 00:36 | <Hixie> | 5% are xhtml 1.0 strict with uri |
| 00:36 | <Ketsuban> | I don't understand why people don't use Strict rather than Transitional. :P |
| 00:36 | <Hixie> | er the 7% were with uri, not without uri |
| 00:37 | <Hixie> | 5% again are html 4.0 transitional without uri |
| 00:38 | <Hixie> | 2% are 4.01 strict with uri, the acid3 doctype |
| 00:38 | <Ketsuban> | Awesome, I'm part of a 2% minority. :D |
| 00:38 | <Hixie> | after that the values are all below 1% |
| 00:39 | <Hixie> | (the next one is 4.01 transitional with the uri "http://www.w3.org/tr/1999/rec-html401-19991224/loose.dtd";) (after lowercasing) |
| 00:39 | <Hixie> | 1.1 strict with uri is next |
| 00:39 | <Hixie> | which is ironic given that this is only testing text/html iirc, and 1.1 strict can't be sent as text/html legally |
| 00:40 | <Ketsuban> | Apparently not many people hold the belief that it's only worth using XHTML if you're going to be embedding other XML technologies like SVG, and if you're not you might as well use HTML. |
| 00:40 | <Lachy> | I think it's only a SHOULD NOT |
| 00:40 | <Hixie> | for 1.1 i thought it was a must not |
| 00:40 | <Lachy> | so techically, it can. But it's pointless |
| 00:40 | <Hixie> | i also have data about which doctypes had the most syntax errors |
| 00:41 | <Hixie> | and which had the most elements that they weren't allowed to have |
| 00:41 | <Hixie> | but that's harder to process from the raw data |
| 00:41 | <Ketsuban> | http://www.w3.org/TR/xhtml-media-types/#summary |
| 00:41 | <Hixie> | 50% of pages in this multi-billion file sample are in quirks. that's a huge step forward past the graph i had that ended in 2006. |
| 00:42 | <Hixie> | (40% limited quirks, 10% no quirks) |
| 00:56 | <takkaria> | Hixie: as in, 50% of pages are in standards mode? |
| 01:03 | <Hixie> | takkaria: almost standards and standards, yeah |
| 01:03 | <takkaria> | that's pretty awesome |
| 01:04 | <Hixie> | pretty surprising, too |
| 01:04 | <Hixie> | it's a much faster migration than i had expected |
| 01:04 | <takkaria> | Hixie: are you going to do a new webstats thing for code.google.com? |
| 01:05 | <Hixie> | probably not |
| 01:05 | <Hixie> | not any time soon anyway |
| 01:05 | <takkaria> | shame |
| 01:06 | <Hixie> | it's a lot of work :-) |
| 01:06 | <takkaria> | I could imagine. still, it's nice to hear that the web migrates fairly fast |
| 01:13 | <Dashiva> | Hixie: I wonder, though. How much is migration, and how much is simply from the web growing and more new pages being with doctype by default rather than intent? |
| 01:14 | <Hixie> | could be that too |
| 01:32 | <blooberry> | *reading back* hixie: wow. That *does* seem unbelievably high |
| 02:02 | <Hixie> | hmm |
| 02:02 | <Hixie> | <iframe> isn't in HTML4 strict |
| 02:02 | <Hixie> | this poses a problem for making Acid3 validate |
| 02:06 | <Dashiva> | Hixie: Not if you create it dynamically ;) |
| 02:06 | <Hixie> | these are specifically elements that have to be present statically |
| 02:07 | <Dashiva> | What's the issue with using transitional? |
| 02:08 | <Hixie> | i could |
| 02:08 | <Hixie> | what transitional doctype triggers standards mode? |
| 02:08 | <Lachy> | transitional doctypes only trigger almost standards mode |
| 02:09 | <Dashiva> | standard or almost standard? |
| 02:09 | <Hixie> | standards |
| 02:14 | <Hixie> | well |
| 02:14 | <Hixie> | this is a bummer |
| 02:14 | <Hixie> | not sure what to do |
| 02:15 | <Dashiva> | On one hand, it seems odd to worry about iframe validation when we're making a spec to allow iframe |
| 02:18 | <Hixie> | you know people will complain otherwise |
| 02:19 | <Dashiva> | That's the other hand I don't want to acknowledge :) |
| 02:19 | <Dashiva> | For me, doctypes are ingrained as something you use to choose a compat mode, nothing else |
| 02:21 | <Hixie> | sadly you are in a minority |
| 02:23 | <Dashiva> | USing the html5 doctype isn't an option either, since the validator complains there too |
| 02:25 | <SadEagle> | hood |
| 02:25 | <SadEagle> | uhm. wrong window. and a typo :( |
| 02:25 | Hixie | cheats using document.write() |
| 02:27 | <Hixie> | dbaron: in case you didn't see my comment earlier, i made the AttributeNode tests optional -- they'll pass if there is no support at al |
| 02:27 | <Hixie> | l |
| 02:27 | <dbaron> | Hixie, yep, saw it |
| 02:28 | <dbaron> | Hixie, not sure if I'll be able to convince other people to remove it -- I guess that depends what other browsers do. |
| 02:28 | <Hixie> | well, if it's not removed, it should presumably work interoperably |
| 02:28 | <Hixie> | but i think having the acid3 test make it optional will actually help the argument to remove it |
| 02:28 | <Hixie> | since it's easier to remove than support :-) |
| 02:29 | <Hixie> | dbaron: thanks for forcing the issue though, i agree it is something that needs to be dealt with |
| 03:04 | <Hixie> | hsivonen: getting a 503 from html5.validator.nu |
| 03:47 | <othermaciej> | dbaron: are attribute nodes really that bad? |
| 03:48 | <othermaciej> | I mean, they're pretty useless, but it's also not that hard to support them in a DOM-compliant way by creating hem lazily |
| 03:54 | <dbaron> | If they're pretty useless, why waste the code? |
| 04:34 | <jruderman> | Hixie: test 10 and test 60 use different, seemingly incompatible methods for determining whether attribute nodes are supported |
| 04:34 | <jruderman> | Hixie: and in test 60, i think you don't want to skip the whole test if attribute nodes are not supported |
| 04:35 | <jruderman> | and test 60 should return 4, not 1, when attribute nodes are not supported ;) |
| 06:23 | <hsivonen> | Hixie: v.nu is back up. the kernel had killed the process. reason not given. sorry about that. |
| 06:49 | <Hixie> | jruderman: fixed test 60 (copy/paste edit error) |
| 06:49 | <Hixie> | jruderman: why would i not want to skip the whole test? |
| 06:50 | <jruderman> | after reading the rest of the test, i think you're right to skip the whole test. so never mind. |
| 06:52 | <jruderman> | Hixie: i'd add to test 60 |
| 06:52 | <jruderman> | assertEquals(attr.value, 'ocelots', "attribute value wrong"); |
| 06:53 | <Hixie> | where? |
| 06:53 | <Hixie> | after setting it? |
| 06:53 | <jruderman> | yeah |
| 06:53 | <Hixie> | done |
| 06:55 | <jruderman> | :) |
| 07:14 | jwalden | finally sends the postMessage feedback and tests of the last several months to whatwg |
| 07:22 | MikeSmith | reads http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-January/013795.html |
| 07:22 | <MikeSmith> | How complete is the Firefox cross-messaging implementation? |
| 07:24 | <gavin> | complete! |
| 07:25 | <gavin> | (I think?) |
| 07:25 | <gavin> | jwalden knows |
| 07:25 | <jwalden> | Gecko's postMessage totally pwns the webkit one |
| 07:25 | <MikeSmith> | heh |
| 07:25 | <jwalden> | I mean it |
| 07:25 | <jwalden> | I don't think example.org can call postMessage on example.com in WebKit |
| 07:26 | <jwalden> | which is kinda the point of the feature |
| 07:29 | <jwalden> | no idea what the status of Opera's implementation is, if it were to be transplanted to Window |
| 07:32 | <MikeSmith> | Opera implementation is just a partial one, right? |
| 07:32 | <jwalden> | I don't know |
| 07:32 | <jwalden> | it's on document |
| 07:33 | <jwalden> | so it's rather incompatible from that point of view |
| 07:33 | <jwalden> | and IE and Gecko 1.9 don't allow access to documents across domains |
| 07:34 | <jwalden> | I hoped to run the tests against Opera to make sure they at least ran, before I found out that doing so would be pretty meaningless given postMessage's location in Opera |
| 07:38 | <MikeSmith> | jwalden - is there a version target for when this will be in a final FF release? I mean 3.1 or whatever |
| 07:38 | <jwalden> | MikeSmith: it'll be in 3.0b3 |
| 07:38 | <MikeSmith> | OK |
| 07:38 | <jwalden> | out in a week or so, with luck |
| 07:39 | <MikeSmith> | so it's targeted to go in the final 3.0 release? |
| 07:39 | <jwalden> | yes |
| 07:39 | <jwalden> | I still don't know quite how |
| 07:40 | <jwalden> | given when we were "backend-feature-complete" |
| 07:40 | <jwalden> | that said, as features go this one's actually not that complicated |
| 07:45 | MikeSmith | just now re-reads first paragraph of jwalden's message |
| 07:45 | <jwalden> | ah, you skipped that one? heh |
| 07:46 | <MikeSmith> | yeah, dunno why.. skipped ahead to interesting bits first :) |
| 07:46 | <MikeSmith> | like the part that starts "The spec's incomplete or vague on a few points right now..." |
| 07:47 | <jwalden> | the rest is only interesting given the first paragraph |
| 07:47 | <jwalden> | otherwise we're talking 5% of the web |
| 07:47 | <jwalden> | fact of life, sadly |
| 07:47 | jwalden | would like to see a totally homogeneous browser population |
| 07:48 | jwalden | suspects many web developers would disagree :-) |
| 07:48 | <MikeSmith> | jwalden - visit Korea |
| 07:48 | <MikeSmith> | you will find one there |
| 07:48 | <jwalden> | hm |
| 07:48 | <jwalden> | maybe that's not the word I wanted! |
| 07:48 | <MikeSmith> | heh |
| 07:48 | <hsivonen> | MikeSmith: how's Korea coping with IE7 and Vista? |
| 07:49 | <jwalden> | "evenly distributed", for lack of a better word |
| 07:49 | <hsivonen> | so I haven't deployed Saxon yet, because the build doesn't run an Linux even though it runs on Mac OS X |
| 07:50 | <hsivonen> | I wonder if Linux has a lower limit for the max number of command line parameters for a process than Mac OS X |
| 07:50 | <hsivonen> | the command for jarring Saxon fails on Linux |
| 07:51 | <othermaciej> | dbaron: there's more useless things than attribute nodes which take far more code |
| 07:51 | <MikeSmith> | hsivonen - dunno much about IE7 and Vista in Korea, but i remember there being complaints/anger in Japan about the fact they MS had/has not made available yet in Japan some system for enterprise/corporate sysadmins to push out automatic IE7 updates to users |
| 07:52 | <MikeSmith> | I think same situation in Korea about that update thingy |
| 07:52 | <othermaciej> | dbaron: if there is to be a cutoff point on DOM Core specs that matter, it would be somewhat nice to at least include all of DOM Core 2 |
| 07:52 | <othermaciej> | jwalden: are you sure about that? (example.org calling example.com) |
| 07:53 | <othermaciej> | jwalden: I would be highly surprised if postMessage didn't work cross-domain, since that is kind of the whole point |
| 07:53 | <MikeSmith> | hsivonen - Debian Linux packagers might be able to help solve that |
| 07:53 | <othermaciej> | jwalden: indeed, DOMWindow.idl says: |
| 07:53 | <othermaciej> | [DoNotCheckDomainSecurity, Custom] void postMessage(in DOMString message); |
| 07:53 | <jwalden> | Unsafe JavaScript attempt to access frame with URL http://localhost:8888/tests/dom/tests/mochitest/whatwg/test_postMessage.html from frame with URL http://example.org:8000/tests/dom/tests/mochitest/whatwg/postMessage_helper.html. Domains, protocols and ports must match. |
| 07:54 | <othermaciej> | so if you have a test case where it doesn't work cross-domain, either it's a WebKit bug or your test case is buggy |
| 07:54 | <othermaciej> | can you post the test case somewhere? |
| 07:54 | <jwalden> | othermaciej: see the whatwg post |
| 07:55 | <jwalden> | that's from test_postMessage.html |
| 07:55 | <othermaciej> | jwalden: sounds like running it is hard |
| 07:55 | <othermaciej> | jwalden: thanks for making tests though |
| 07:55 | <jwalden> | sure |
| 07:56 | <jwalden> | I don't think it'd have gotten in without as many tests as it had |
| 07:56 | <jwalden> | as for the "hard" part, just requires the right test-harness work :-) |
| 07:57 | <othermaciej> | jwalden: we have tests for cross-domain postMessage in our regression tests and they appear to be passing |
| 07:57 | <jwalden> | yeah, I saw them; I don't know what's up, to be honest, but I was definitely seeing failures |
| 07:57 | <jwalden> | this is 29807 |
| 07:57 | <othermaciej> | jwalden: so I think your test fails for some reason other than cross-domain access to postMessage not working in general |
| 07:58 | <jwalden> | hm |
| 07:59 | <jwalden> | so javascript:alert(window.otherCrossDomain) in test_postMessage.html is causing that error |
| 08:00 | <othermaciej> | jwalden: I don't see that in the test file? |
| 08:01 | <jwalden> | that's me running in the location bar |
| 08:01 | <jwalden> | I'm certainly accessing window.otherCrossDomain all over the place, tho |
| 08:01 | <jwalden> | or window.frames.otherCrossDomain, natch |
| 08:01 | <jwalden> | same thing |
| 08:02 | <hsivonen> | MikeSmith: a DD said that the limit is 128 KB. The command I tried to run is 150 KB. sigh |
| 08:02 | <othermaciej> | jwalden: I think we disallow toString on windows in other domains, so that's probably way |
| 08:02 | <othermaciej> | perhaps you are doing something else to the Window that WebKit disallows |
| 08:02 | <jwalden> | ah |
| 08:03 | <othermaciej> | you actually do window.frames.otherCrossDomain |
| 08:03 | <othermaciej> | which is slightly less evil |
| 08:03 | <othermaciej> | but maybe the === comparison is disallowed |
| 08:03 | <MikeSmith> | hsivonen - Xalan didn't require as many/as long arguments? |
| 08:03 | <othermaciej> | which I guess it shouldn't be |
| 08:03 | <hsivonen> | MikeSmith: I used Xalan without building it |
| 08:03 | <MikeSmith> | oh |
| 08:03 | <hsivonen> | MikeSmith: Saxon has too many classes to jar in one go |
| 08:04 | <jwalden> | also note not == since that can have messy side effects :-\ |
| 08:04 | jwalden | wishes == had been === |
| 08:04 | <jwalden> | when you're not careful, at least |
| 08:04 | <hsivonen> | MikeSmith: my build script names every class for jar and changes directory explicitly for each one |
| 08:04 | <hsivonen> | changing directory works around a design bug in jar |
| 08:04 | <jwalden> | so javascript:alert(window.frames.otherCrossDomain.postMessage) alerts undefined when run on test_postMessage.html |
| 08:04 | <hsivonen> | I guess I have to figure a new way to work around it |
| 08:06 | <othermaciej> | jwalden: can you get at close on that frame? |
| 08:06 | <MikeSmith> | hsivonen - seems like Java packagers from Debian or other Linux distros might have run into same problem before |
| 08:06 | <jwalden> | othermaciej: yes |
| 08:06 | <othermaciej> | jwalden: I can definitely get at "close" and "postMessage" both in windows in foreign domains |
| 08:06 | <MikeSmith> | but I guess it may be a case where there's not general solution to work around the limit |
| 08:07 | <hsivonen> | MikeSmith: they probably give a directory name to jar and let jar traverse it |
| 08:07 | <hsivonen> | I had a reason not to do that |
| 08:09 | <othermaciej> | jwalden: are you tests based on the WebKit layout tests for postMessage or totally independent? |
| 08:09 | <jwalden> | othermaciej: totally independent |
| 08:09 | <othermaciej> | (if the latter we should fold them into our regression tests) |
| 08:10 | <othermaciej> | (and also you should include ours probably) |
| 08:10 | <othermaciej> | (feature won't be very interoperable if we don't pass each other's tests) |
| 08:10 | <jwalden> | I'm pretty my tests subsume yours in functionality, but it could be done easily enough |
| 08:10 | <jwalden> | s/my/sure my/ |
| 08:11 | MikeSmith | takes a moment to read http://ejohn.org/blog/the-state-of-json/ |
| 08:11 | <hsivonen> | http://twitter.com/cwilso/statuses/656169372 |
| 08:11 | <othermaciej> | who is "OH"? |
| 08:12 | <MikeSmith> | "a way to access native JSON encoding and decoding from web pages... there should be something within the browser by the time the Firefox 3 betas wrap-up." |
| 08:12 | <hsivonen> | othermaciej: overheard |
| 08:13 | <jwalden> | MikeSmith: last I heard, that's unlikely -- worries about not enough vetting of the impl |
| 08:13 | <othermaciej> | Microsoft certainly knows how to motivate the web developer community |
| 08:13 | <jwalden> | hrm |
| 08:13 | jwalden | wonders whether jresig missed that memo |
| 08:14 | <jwalden> | (bug comment, really :-) ) |
| 08:14 | <MikeSmith> | jwalden - I see |
| 08:15 | <jwalden> | https://bugzilla.mozilla.org/show_bug.cgi?id=408838 |
| 08:16 | <MikeSmith> | jwalden - thanks |
| 08:16 | <jwalden> | no problem |
| 08:16 | <othermaciej> | jwalden: I could encourage you to at least try the tests once, for the same reason you encourage other implementors to try yours |
| 08:16 | <jwalden> | sure, I'll give it a shot |
| 08:21 | <hsivonen> | looks like jar can read its command line from a file to work around the OS limit... |
| 08:27 | <MikeSmith> | hsivonen - that's good news |
| 08:27 | <MikeSmith> | that'll work for your case, right? |
| 08:28 | <hsivonen> | MikeSmith: yes |
| 08:28 | <MikeSmith> | great |
| 09:16 | <hsivonen> | whew. Validator.nu now validates the old spec copy without choking: http://html5.validator.nu/?doc=http%3A%2F%2Fabout.validator.nu%2Fspec2.html |
| 09:17 | <hsivonen> | hmm. and looks like I need to fix about.validator.nu server config... |
| 09:27 | <zcorpan_> | http://files.myopera.com/MacDev_ed/svg/sign_danger_corrosive.svg |
| 09:27 | zcorpan_ | thinks that's a suitable reference rendering for acid3 :) |
| 09:45 | <othermaciej> | haha |
| 09:46 | <hsivonen> | that SVG file is what's corroding my copy of safari |
| 09:48 | <zcorpan_> | well it warned you now didn't it? :) |
| 09:48 | <hsivonen> | :-) |
| 09:49 | <hsivonen> | was it so that I need to set a timeout if I want to emulate hashChanged in current browsers? |
| 09:50 | <zcorpan_> | i think so, unless you're happy to assume that the hash will only change in response to click or keyboard events |
| 09:51 | <annevk> | what is window.otherCrossDomain ? |
| 09:52 | <hsivonen> | zcorpan_: is that a good assumption with alternative input methods, spatnav, etc.? |
| 09:53 | <hsivonen> | are <body onload='...> and window.onload different handlers or is there some legacy sameness going on? |
| 09:54 | <zcorpan_> | spatnav still emits keyboard events, but it's certainly not fool proof. e.g. the user might enter a hash in the address bar |
| 09:54 | <zcorpan_> | hsivonen: they should be the same, but i'm not sure if opera gets it right yet |
| 09:55 | <hsivonen> | I wonder if I should clean away the event handler attributes from the Validator.nu HTML output and install everything in script... |
| 09:55 | <zcorpan_> | using window.onload instead of <body onload> certainly works cross-browser |
| 09:55 | <zcorpan_> | using both doesn't :) |
| 09:56 | <hsivonen> | ok. I'll clean up my HTML |
| 09:57 | <zcorpan_> | sounds good, i guess you get a better mobileOK score then :) |
| 09:58 | <hsivonen> | heh. |
| 09:58 | <hsivonen> | the key parts of the scripted stuff work in Opera Mini even |
| 09:58 | <zcorpan_> | that's nice |
| 09:59 | <hsivonen> | I hope mini doesn't care about attributes vs. script-installed handlers |
| 10:03 | <othermaciej> | annevk: just a piece of jwalden's tests - hapens to be the name of a frame |
| 10:03 | <othermaciej> | annevk: it does not have deep meaning |
| 10:03 | <zcorpan_> | the group messages button works, which has script-installed handler, so i guess it should work |
| 10:04 | <hsivonen> | zcorpan_: ok |
| 10:04 | <hsivonen> | last I checked the part that didn't work in Mini was the textarea/fileupload mode popup |
| 10:05 | <hsivonen> | but then, that doesn't need to work in Mini |
| 10:05 | hsivonen | wants media queries in MicroB, S60 Browser and Opera Mobile |
| 10:08 | <annevk> | othermaciej, good, I was hoping it was that :) |
| 10:10 | <MacDome> | Hixie: I agree with roc... SMIL could be hell to implement :) But it also is moderately useful to the web |
| 10:10 | <MacDome> | it's more the SVG animation DOM which is a bitch |
| 10:11 | <MacDome> | the baseVal animVal problem |
| 10:11 | <hsivonen> | does Opera implement SMIL? |
| 10:11 | <annevk> | we implement SVG Animation |
| 10:12 | <annevk> | which reuses part of SMIL |
| 10:12 | <othermaciej> | I think people are using "SMIL" as a slightly imprecise shorthand for "SVG Animation" |
| 10:12 | <annevk> | we do not implement the 111 and growing namespace monster that is SMIL 2.1 |
| 10:12 | <zcorpan_> | annevk: they settled for a single namespace for smil3, though |
| 10:13 | <hsivonen> | fwiw, for HTML eyecandy, I think the Apple CSS animation proposal is way more elegant than the transition stuff from the SMIL group |
| 10:13 | <annevk> | that makes 112 |
| 10:13 | <annevk> | alarm number of Europe |
| 10:13 | <hsivonen> | :-) |
| 10:14 | <annevk> | i agree that the CSS animation stuff is nicer |
| 10:15 | <webben_> | SMIL isn't really intended for "eye candy": it's a content language. |
| 10:15 | <annevk> | unfortunately the CSS group won't work on it right away |
| 10:15 | <webben_> | (AFAIK) |
| 10:15 | <MacDome> | now we just need a nice way to apply the CSS animation to SVG :) |
| 10:15 | MacDome | should submit a test or two to get SMIL kicked from the test |
| 10:15 | <MacDome> | it's just so low on actual browser feature lists |
| 10:16 | <annevk> | othermaciej, btw, any simplification of the DOM that is possible is good imo, if we can remove attribute nodes that would be a win |
| 10:16 | <MacDome> | since no one in their right mind is trying to use it on the web right now |
| 10:16 | <webben_> | No. It's like with video. Easier to use Flash for complex presentations. |
| 10:16 | <jruderman> | implementing SMIL might hurt static svg perf |
| 10:16 | <webben_> | and there's Slidy for simple ones. |
| 10:16 | <jruderman> | assuming it requires sprinkling "if(animated)" all over |
| 10:17 | <annevk> | MacDome, might be chicken/egg problem |
| 10:17 | <othermaciej> | annevk: TreeWalker doesn't seem any more useful to me than attribute nodes... |
| 10:17 | <MacDome> | annevk: might |
| 10:17 | <annevk> | sure |
| 10:17 | <webben_> | So it's limited to people who want to make complex presentations in an open format. |
| 10:17 | <annevk> | (to both) |
| 10:17 | <MacDome> | jruderman: I don't think it's a bunch of branching |
| 10:17 | <annevk> | othermaciej, but if we can remove one why not do it? |
| 10:17 | <webben_> | (And the pool of people who care about that is small.) |
| 10:18 | <MacDome> | jruderman: it is a bunch of added complex code however |
| 10:18 | <othermaciej> | annevk: well, I'd put TreeWalker on the chopping block too |
| 10:18 | <othermaciej> | I'm not sure why attribute nodes are worse |
| 10:18 | <webben_> | (and I guess it has to compete with ODF) |
| 10:18 | MacDome | thinks that TreeWalker is on the list of "simple to actually implement so we should just get it out of the way and be done with it" |
| 10:18 | <annevk> | i'm fine with putting both on the chopping block, it just seems that dropping attribute nodes might be easier |
| 10:19 | <othermaciej> | just seems a little arbitrary |
| 10:19 | <annevk> | maybe it's because it's part of the Core DOM |
| 10:19 | <othermaciej> | Attr nodes are part of DOM 1 Core, TreeWalker is part of DOM2 Traversal, does any web content use it? |
| 10:19 | <annevk> | i also think that namespace events should be dropped from dom3events |
| 10:20 | <annevk> | for treewalker there are some use cases |
| 10:20 | <annevk> | for attr nodes there are none given that no implementation does entity nodes |
| 10:20 | <othermaciej> | TreeWalker is a bad API for traversing a DOM tree |
| 10:20 | <othermaciej> | I agree there are use cases for a good API for doing so |
| 10:21 | <annevk> | xhr is a bad api for network requests... |
| 10:21 | <othermaciej> | what I hate most out of DOM Events is mutation events |
| 10:21 | <othermaciej> | it's not just useless, it is actively harmful to code complexity and performance all over the DOM |
| 10:21 | <jruderman> | oh, yes, mutation events are evil |
| 10:21 | <othermaciej> | annevk: but XHR is used, unlike TreeWalker |
| 10:21 | <annevk> | is treewalker implemented everywhere? |
| 10:22 | <othermaciej> | surely not in IE |
| 10:22 | <annevk> | that's probably a good reason for not using it then :) |
| 10:22 | <othermaciej> | it is in WebKit and Mozilla |
| 10:22 | <othermaciej> | I'd assume Opera too |
| 10:22 | <jruderman> | othermaciej: did you see that gecko decided to stop firing mutation events during page load? |
| 10:22 | <othermaciej> | jruderman: even if they are caused by explicit mutation, not parsing? |
| 10:22 | <jruderman> | i think so, but i'm not sure |
| 10:22 | <othermaciej> | (we never did fire them as side effects of initial parsing) |
| 10:23 | <othermaciej> | we actually don't fire them at all if no listener is registered |
| 10:23 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=90983 |
| 10:23 | <othermaciej> | that reduces perf cost |
| 10:23 | <othermaciej> | but there's still a lot of code complexity to make basic DOM operations robust in the face of mutation event listeners possibly modifying the DOM |
| 10:23 | <jruderman> | we had that optimization too, and we were spending time looking to see if there were mutation listeners |
| 10:23 | <jruderman> | yes |
| 10:23 | <othermaciej> | (which no one ever really wants to do in a way that invalidates the DOM operation) |
| 10:23 | <jruderman> | we had a fair number of crashes due to bad assumptions in there |
| 10:24 | <othermaciej> | if DOM change notifications are actually useful, they should be batched |
| 10:24 | <othermaciej> | until the end of operations that ought to be atomic |
| 10:24 | <othermaciej> | our editing operations just skip mutation events entirely I think |
| 10:24 | <jruderman> | as opposed to some being required to be sent before the mutation actually happens? :P |
| 10:25 | <othermaciej> | the worst are the ones that happen in the middle |
| 10:25 | <othermaciej> | over half the code in our Node.replaceChild core implementation is to account for mutation events possibly doing something crazy |
| 10:29 | <annevk> | heh, that bug is filed by an Opera developer |
| 10:29 | <annevk> | s/is/was/ |
| 10:31 | <hsivonen> | is DOMContentLoaded going to be part of a spec? |
| 10:32 | <annevk> | it's part of HTML 5 |
| 10:32 | <hsivonen> | oh. :-) |
| 10:33 | <annevk> | Opera 9.2x now passes less than 50% of the Acid3 tests |
| 10:34 | <takkaria> | that Charles fella on whatwg doesn't seem to grok the video element |
| 10:35 | <othermaciej> | in Safari 3 it just says "JS ?" |
| 10:35 | <othermaciej> | is that intended? |
| 10:35 | <othermaciej> | (65/100 in WebKit trunk) |
| 10:37 | <annevk> | i don't think so |
| 10:37 | <harri> | he. khtml fell back to 65 after the recent changes, too. |
| 10:49 | <hsivonen> | does any browser support hashchanged yet? |
| 10:50 | <annevk> | neh |
| 10:50 | <hsivonen> | ok |
| 11:01 | <hsivonen> | Hmm. Validator.nu script initialization isn't good if show source is enabled and the doc is huge |
| 11:02 | <hsivonen> | I wonder if I should move the script element right after the form and make the form initialization code run immediately at that point... |
| 11:02 | <MacDome> | om_sleep: Safari 3 used to show like 46/100 |
| 11:02 | <MacDome> | insetad of JS ? |
| 11:04 | <hsivonen> | is there any harm, if I move the <script> element except it isn't as elegant? will it break XHTML loading in legacy browsers, for example? |
| 11:06 | <annevk> | xhtml in gecko had issues with <script> |
| 11:06 | <hsivonen> | :-( |
| 11:07 | <hsivonen> | annevk: do you recall what kind of issues? |
| 11:08 | <annevk> | vague memory tells me the script executed directly but the DOM wasn't build up so stuff failed |
| 11:08 | <hsivonen> | annevk: ok. that can be coded for |
| 11:08 | <annevk> | i wouldn't worry aout it though and simply assume incremental XML parsers |
| 11:08 | <annevk> | i'm sure content already relies on that (at leasts tests :)) |
| 11:10 | <hsivonen> | now I need to learn to do cross-browser stylesheet manipulation... |
| 11:11 | <annevk> | it surprises me that 10% of the Web is in standards mode |
| 11:12 | <hsivonen> | hmm. alternatively, I could just do some dirty className toggling. |
| 11:12 | <hsivonen> | that might be easier and even force style resolution and layout reflow in legacy UAs |
| 11:14 | <hsivonen> | annevk: can you recommend a good CSSOM tutorial? |
| 11:17 | <annevk> | no :( |
| 11:18 | <hsivonen> | in terms of perf and compat, should I modify the main stylesheet in DOM or should I create a <style> element and do dynamic styles there? |
| 11:26 | <hsivonen> | how do I create an object that implements CSSStyleSheet? |
| 11:37 | <hsivonen> | hmm. looks like manipulating the textContent of a <style> element is much easier than dealing with the CSSOM... |
| 11:51 | <annevk> | you can do document.styleSheets[0].insertRule("", -1) or something like that |
| 11:52 | <annevk> | but manipulating textContent of <style> seems fine |
| 14:30 | <hsivonen> | annevk: manipulating the textContent of <style> works in Gecko and WebKit. fails in opera... |
| 14:31 | zcorpan | notes that his changes to the wiki HTML page have stayed |
| 14:31 | <hsivonen> | hmm. misdianosed |
| 14:31 | <hsivonen> | hmm. textContent manipulation works in Opera after all |
| 14:32 | <hsivonen> | does assigning to innerText of <style> work in IE? |
| 14:42 | <zcorpan> | no |
| 14:43 | <zcorpan> | but see http://status.whatwg.org/annotate-web-apps.js for how to make it work in ie (search for an3err) |
| 14:44 | <hsivonen> | zcorpan: so appendChild with a text node works cross-browser? |
| 14:45 | <zcorpan> | not in ie |
| 14:45 | <zcorpan> | but the catch block works in ie |
| 14:45 | <hsivonen> | if(an3err.number == -0x7FFF0001) style.styleSheet.cssText |
| 14:45 | <hsivonen> | that bit ah |
| 14:46 | <hsivonen> | zcorpan: thanks |
| 14:47 | <zcorpan> | welcome, though i didn't write that piece of code... don't remember who it was though |
| 14:48 | <Philip`> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011474.html ? |
| 14:48 | <hsivonen> | does the line style.type = "text/css"; // required in html4... |
| 14:48 | <hsivonen> | have any actual effec anywhere? |
| 14:48 | <zcorpan> | no |
| 14:48 | <hsivonen> | ok |
| 14:49 | <zcorpan> | i didn't want to invalidate the spec :) |
| 14:49 | <zcorpan> | Philip`: yes |
| 14:51 | <zcorpan> | (the fix was in trunk but not published at that point) |
| 15:12 | <hsivonen> | what's the expected way of detecting whether hashchanged is supported? |
| 15:12 | <annevk> | "The following line is used in a number of the tests. It is done using document.write() to sidestep complaints of validity." why not use <object>? |
| 15:12 | <annevk> | i guess there mightbe more issues |
| 15:13 | <annevk> | if(window.onhaschanged) maybe |
| 15:13 | <annevk> | with proper spelling |
| 15:15 | <hsivonen> | oh. I didn't expect it to have non-false truthiness until set |
| 15:16 | <Philip`> | if (window.onhaschanged !== undefined) maybe? |
| 15:16 | <hsivonen> | annevk: it appears that unset event handlers are undefined |
| 15:16 | <Philip`> | s//h/ |
| 15:16 | <annevk> | what Philip` said should work |
| 15:16 | <Philip`> | Oh, Opera 9.2 says window.onload === null, Firefox 2 says undefined |
| 15:16 | <hsivonen> | Philip`: that kind of test doesn't detect support for window.onload |
| 15:16 | <annevk> | hsivonen, they are null |
| 15:17 | <annevk> | oh, Firefox :( |
| 15:17 | <hsivonen> | annevk: undefined in firefox 3 |
| 15:17 | <annevk> | does anyone still use that? |
| 15:17 | <Philip`> | IE6 says null |
| 15:18 | <annevk> | HTML5 says null |
| 15:18 | <annevk> | hmm, what does HTML4 say |
| 15:18 | <annevk> | we should add this to Acid3 |
| 15:18 | <hsivonen> | well then. I guess it is time to search bugzilla |
| 15:19 | <annevk> | oh, I guess these type of event handlers are not defined anywhere |
| 15:19 | <hsivonen> | specs++ |
| 15:19 | <annevk> | HTML5 has them fortunately |
| 15:19 | <annevk> | but that's a bit late for Acid3 |
| 15:21 | <annevk> | lol http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3 |
| 15:21 | <annevk> | "Note. Authors of HTML documents are advised that changes are likely to occur in the realm of intrinsic events (e.g., how scripts are bound to events). Research in this realm is carried on by members of the W3C Document Object Model Working Group (see the W3C Web Site at http://www.w3.org/ for more information)." |
| 15:21 | <annevk> | and how much better it became... |
| 15:22 | <hsivonen> | hmm. looks like this bug hasn't been filed yet |
| 15:22 | hsivonen | files |
| 15:25 | <zcorpan> | annevk: both object and iframe are tested |
| 15:26 | <hsivonen> | hmm. window.onload is undefined in Opera 9.50 beta, too |
| 15:26 | <annevk> | grmbl |
| 15:28 | <hsivonen> | but null indeed in Opera 9.20 |
| 15:31 | <hsivonen> | annevk: I can't find a HTML5 justification for event handelers on the window object getting initialized to null |
| 15:31 | <hsivonen> | oops. found it |
| 15:32 | <annevk> | 4.3.6 |
| 15:39 | <hsivonen> | filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=414853 |
| 15:51 | <Philip`> | Oh, IE6 has window.onload === null but window.onanythingelse === undefined for all anythingelses that I've tried |
| 15:52 | <Philip`> | and Opera 9.2 seems to do it for onload and nothing else too |
| 15:52 | <annevk> | hmm |
| 15:53 | <annevk> | there's a use case for changing the behavior, but how useful that would be given deployed stuff... |
| 15:54 | <annevk> | and given that you can use "typeof window.onload" as well |
| 15:55 | <Philip`> | (Ah, IE6 does onunload === null too) |
| 15:55 | <annevk> | oh wait, typeof also only works for certain stuff |
| 15:55 | <annevk> | bah |
| 15:55 | <Philip`> | and Opera 9.2 does it on onunload too |
| 15:56 | <hsivonen> | Hixie: see above. should the spec or Gecko to be considered erroneous wrt. event handler initialization |
| 15:56 | <hsivonen> | ? |
| 16:14 | <hsivonen> | hmm. why is google reporting my doctype page as http://hsivonen.iki.fi/DOCTYPE/ ? |
| 16:14 | <hsivonen> | where did it get the upper case from? |
| 16:16 | <annevk> | your server is case-insensitive? |
| 16:16 | <gsnedders> | annevk: it's settable at an Apache level, IIRC |
| 16:16 | <hsivonen> | annevk: yeah, but there are many more lower-case links pointing to the page |
| 16:16 | <hsivonen> | gsnedders: it is backed by HFS+ |
| 16:17 | <annevk> | hmm, I think that information might come from this tagging thing Google has going on |
| 16:17 | <annevk> | Google Base? |
| 16:17 | <hsivonen> | I guess I have to take counter-measures now |
| 16:17 | <annevk> | the summary for my weblog says "Weblog on working for Opera Software, web standards, mark-up and style." for instance which appears exactly nowhere on my site |
| 16:18 | <hsivonen> | otherwise links will break if/when I switch to an Ubuntu server |
| 16:18 | <annevk> | if you switch you can enable mod_speling |
| 16:18 | <gsnedders> | hsivonen: you can just set Apache to be case-insensitive on a case-sensitive fs |
| 16:19 | <Philip`> | annevk: That's the same description as on Google Directory / Open Directory |
| 16:19 | <Philip`> | so I think they get the text from there |
| 16:21 | <takkaria> | annevk: that's probably how your site is described in dmoz.org |
| 16:21 | <hsivonen> | I set a permanent redirect to /doctype/ |
| 16:23 | <hsivonen> | looks like Google penalized my doctype article for the recent major clarifying edits :-( |
| 16:24 | <hsivonen> | still on the first result page, though |
| 16:54 | <mpt> | http://www.dmoz.org/Computers/Internet/Web_Design_and_Development/Weblogs/ |
| 16:55 | <mpt> | The same reason Wikipedia articles often show up in Google results with a summary beginning "Hyperlinked encyclopedia article..." -- because dmoz.org editors have a fetish for describing Wikipedia as "hyperlinked" |
| 16:57 | <Camaban> | <META NAME="ROBOTS" CONTENT="NOODP"> will stop that |
| 17:00 | annevk | finds http://www.mattcutts.com/blog/google-supports-meta-noodp-tag/ |
| 17:01 | <annevk> | i don't think i'll add that element |
| 17:05 | <Camaban> | heh, bit of matt cutts subtle spin there, if you've got a less than ideal odp description, it's useful |
| 17:06 | <Camaban> | looks like yours is useful enough though :) |
| 18:56 | <hsivonen> | I changed the way the Validator.nu UI script interacts with DOM loading |
| 18:56 | <hsivonen> | please let me know if I broke something in some browser |
| 18:56 | <hsivonen> | I tested Firefox 3, Safari 3 and Opera 9.50 |
| 19:01 | <SadEagle> | looks just spiffy in konq4. |
| 19:02 | <hsivonen> | good |
| 19:02 | <SadEagle> | what's the 'group messages' button is supposed to be about? |
| 19:02 | <SadEagle> | FF2 looks fine, I guess. |
| 19:03 | <hsivonen> | SadEagle: if there are messages with multiple instances, it groups them |
| 19:03 | <SadEagle> | hmm, then we don't disable the button somehow |
| 19:07 | <SadEagle> | hsivonen: where would the group button be disabled? |
| 19:07 | <hsivonen> | SadEagle: http://html5.validator.nu/?doc=http%3A%2F%2Fhsivonen.iki.fi%2Ftest%2Fmoz%2Felaboration-demo.xhtml |
| 19:08 | <SadEagle> | I mean code-wise. hrmbl, work better in 3.5.9-pre :-) |
| 19:09 | <hsivonen> | oh. :-) |
| 19:09 | <hsivonen> | line 328 in |
| 19:09 | <hsivonen> | http://about.validator.nu/script.js |
| 19:11 | <SadEagle> | OK, that ought to work :-) |
| 19:12 | <SadEagle> | (what the heck?) |
| 19:13 | <hsivonen> | the only marginally special thing is that the button is not inserted into the document tree at that point |
| 19:33 | <SadEagle> | hsivonen: that's fun. it actually makes it disabled. It just doesn't look it |
| 19:33 | <hsivonen> | SadEagle: nice. :-) |
| 19:36 | <SadEagle> | o |
| 20:04 | <zcorpan_> | hsivonen: seems like boot() is run thrice |
| 20:04 | <hsivonen> | zcorpan_: hmm. it should run only twice |
| 20:05 | <zcorpan_> | hsivonen: you still have <body onload> |
| 20:05 | <hsivonen> | oh. |
| 20:05 | <hsivonen> | thanks |
| 20:06 | <zcorpan_> | why should it run twice? |
| 20:07 | <hsivonen> | zcorpan_: once after the form and another time when the load is complete in case the first time failed legacy Gecko in XHTML mode |
| 20:07 | <zcorpan_> | ok |
| 22:20 | <zcorpan_> | http://timepedia.blogspot.com/2008/01/chronoscope-demo-in-flash-whatwg-canvas.html |
| 22:20 | <zcorpan_> | "Text rendering is my biggest complaint about WHATWG Canvas, so it was a no-brainer to include it." |
| 22:21 | <Hixie> | i don't understand how to do text rendering on canvas, given that we can't guarentee fonts, and therefore the text would have radically different metrics on different platforms |
| 22:22 | <othermaciej> | web fonts! |
| 22:22 | <SadEagle> | heh. |
| 22:22 | <SadEagle> | I've seen different metrics with different freetype revisions |
| 22:23 | <Hixie> | one solution maybe is to give a rect instead of a point, and have the text fit the rect |
| 22:23 | <Hixie> | but then you can't make multiple lines the same font-size |
| 22:27 | <Philip`> | Why is it a problem if text has different metrics on different platforms? (I would expect 12px sans-serif on one platform is not going to be radically different to 12px sans-serif on a different platform, because normal fonts aren't that crazy, and it'll be as portable as tightly-sized CSS layouts are) |
| 22:29 | <zcorpan_> | yeah, i would think most authors are happy with slight differences. they get differences anyway if they want text on canvas today since they have to overlay divs or something |
| 22:29 | <zcorpan_> | and if they're not happy with it then there are web fonts :) |
| 22:31 | <Philip`> | (Firefox's canvas text implementation is annoying because even CSS-px-sized fonts change when you alter the browser's text size setting, so font sizes ought to be specified in canvas coordinate space units instead) |
| 22:33 | <SadEagle> | does it offer metrics info? |
| 22:34 | <Philip`> | You can get the width of a string, and that's it |
| 22:34 | <Philip`> | ( http://developer.mozilla.org/en/docs/Drawing_text_using_a_canvas ) |
| 22:35 | <Philip`> | so it's kind of useless if you e.g. want to know the line separation so you can write multiple lines, or if you e.g. want to know the bounding box so you can save the text onto a temporary canvas or something |
| 22:36 | <SadEagle> | part of the issue with text, though, is that the full APIs are hardly trivial. |
| 22:36 | <SadEagle> | especially if you want to do stuff like linebreaking right with BiDi |
| 22:37 | <Philip`> | But when there's no API at all, people do things like have a bitmap of all the ASCII characters, which is much worse that just having BiDi problems |
| 22:37 | <Philip`> | s/that/than/ |
| 22:38 | <SadEagle> | yeah, but any real/official API has to get it right, IMHO |
| 22:39 | <Philip`> | Hasn't anybody already solved the problem of text drawing APIs, so we could just copy from them? |
| 22:40 | <Philip`> | It's not like it's something that nobody has ever wanted to do before |
| 22:40 | <Hixie> | looking at that moz api -- using the 'font' shorthand's syntax seems like a good technique, but i don't know how to combine that with using coordinte space units |
| 22:41 | <othermaciej> | Hixie: could do it like svg |
| 22:42 | <othermaciej> | "px" == "user unit", other units are fixed multiples |
| 22:42 | <Hixie> | yeah, that might work |
| 22:42 | <Hixie> | and obviously the mozMeasureText would have to be a getBoundingBox-style api |
| 22:43 | <Hixie> | maybe getTextMetrics("string") -> object with height, width, baseline offset |
| 22:47 | <Philip`> | (My particular desire for text metrics was so I could implement X3D text rendering, by drawing onto a temporary canvas and then loading that as an OpenGL texture and drawing it on a 3D quad, so it really needs to know the bounding box of the rendered string) |
| 22:52 | <hsivonen> | Hixie: oops. schema bug. thanks |
| 23:26 | <kig> | canvas text, draw elements on canvas |
| 23:26 | <kig> | or not, heck do i know |
| 23:28 | <kig> | point being that browsers already do all the weird text stuff, so there's no reason to re-invent the wheel |
| 23:29 | <Philip`> | kig: Drawing arbitrary HTML elements onto the canvas, so you can e.g. draw a <p> with some CSSed text in it? |
| 23:29 | <kig> | yes |
| 23:29 | <Hixie> | that becomes complicated with things like iframes and plugins |
| 23:30 | <Hixie> | not to mention determining exactly what is rendered |
| 23:30 | <Philip`> | How would it know how wide an area to wrap text and render into? |
| 23:30 | <kig> | use the box model for the rendered element |
| 23:31 | <Philip`> | since presumably you'd be drawing an HTML fragment that's not part of the document, since you don't want your canvas text elements to be displayed in the page too |
| 23:32 | <SadEagle> | might as well just position the elements over the canvas then :-) |
| 23:33 | <kig> | if you could change their composite op, use them as clip and draw on top of them, sure |
| 23:34 | <kig> | but i don't know. just string + font metrics would suffice for rewrite-the-world stuff |
| 23:35 | <Philip`> | You'd want to be able to transform the elements too |
| 23:35 | <SadEagle> | using as clip already requires stuff outside normal CSSed text, since you have to convert things to path. |
| 23:35 | <kig> | "justification? tex.js! text along path? arc-length reparametrized path interpolation is easy!" |
| 23:36 | <Philip`> | and for 3D canvas you'd want to do perspective transforms, which really doesn't seem like something that CSS should support itself |
| 23:36 | <zcorpan_> | http://www.google.com/search?q=http%3A%2F%2Fminghong.f2g.net%2F |
| 23:37 | <zcorpan_> | i wonder if google supports prefixed xhtml |
| 23:38 | <kig> | i'd assume that transform matrices are orthogonal to text. |
| 23:39 | <zcorpan_> | i don't follow |
| 23:39 | <kig> | 02:41 < Philip`> and for 3D canvas you'd want to do perspective transforms, which really doesn't seem like something that CSS should support itself |
| 23:40 | <zcorpan_> | ah. i thought it was a reply to me... |
| 23:40 | <kig> | need sleep -> zzz |
| 23:40 | zcorpan_ | too |
| 23:44 | annevk | can't sleep; has to get up in four hours :( |
