| 01:58 | <zcorpan> | Hixie: can't you write valid html? :) http://tech.gtaero.net/2008/01/depressing-validation-results.html |
| 02:01 | <Philip`> | Validity is just a guideline :-) |
| 02:07 | <othermaciej> | I wonder why Apple's homepage fails to validate |
| 02:10 | zcorpan | runs apple.com through v.nu |
| 02:13 | <zcorpan> | Error: Stray / in tag. The /> syntax is not permitted in HTML4. (HTML4-only error) |
| 02:13 | <zcorpan> | Error: Bad value search for attribute type on element input. |
| 02:13 | <zcorpan> | Error: Required attributes missing on element script. |
| 02:13 | <zcorpan> | Error: Duplicate attribute id. |
| 02:17 | <zcorpan> | apart from duplicate id, those are not errors per html5, but validating as html5 yields many more other errors |
| 05:55 | <Hixie> | zcorpan: fixed (except for the error that's actually an error in the html4 spec) |
| 06:15 | <G0k> | hixie: any thoughts on my server-sent events proposal? |
| 06:36 | <Hixie> | i haven't looked at server-sent events recently |
| 06:37 | <Hixie> | however all feedback sent to the list ends up in the server-sent events folder and will be dealt with in due course |
| 06:37 | <G0k> | heh oki |
| 07:36 | <Hixie> | 29 tests to go |
| 07:37 | <Hixie> | I'm looking for tests that fail in one of the top four browsers that cover any of the following subject areas but which are justifiable using only specifications that were in REC in 2004 or earlier: |
| 07:38 | <Hixie> | HTTP, URI, data:, NodeIterator, TreeWalker, Range, DOM Core, DOM Events, DOM Views, DOM Style, Selectors, HTML4, DOM2HTML, DOM manipulation, accessors, tables, forms, JavaScript, XHTML |
| 07:38 | <Hixie> | ...and which can be demonstrated purely from script |
| 07:38 | <Hixie> | i.e. that don't depend on rendering |
| 07:44 | <jruderman> | does IE still refuse to render application/xhtml+xml ? |
| 07:44 | MacDome | bets there are lots of JS errors in svg usage :) |
| 07:46 | <Hixie> | i'm trying to avoid entering svg |
| 07:46 | <othermaciej> | do you have any http ones? |
| 07:46 | <othermaciej> | there's gotta be something good |
| 07:46 | <Hixie> | jruderman: yeah, they have no xhtml support. already have a basic test for that though. |
| 07:47 | <othermaciej> | or URI |
| 07:47 | <Hixie> | othermaciej: some simple ones, but i want to avoid anything that needs too much fancy server side config |
| 07:47 | <othermaciej> | yeah |
| 07:47 | <Hixie> | othermaciej: i'm all ears if you know of anything to test |
| 07:47 | <Hixie> | othermaciej: i just can't find any more justifiable bugs! :-) |
| 07:48 | <othermaciej> | I dunno, it's hard to even think of techniques for testing |
| 07:48 | <Hixie> | well i'm really just looking for bugs |
| 07:48 | <Hixie> | i can come up with testing techniques |
| 07:50 | <jwalden> | Hixie: are there tests for things like |window.alert instanceof Function| and |window.alert.apply(null, ["stuff works!"])| ? I'm guessing yes but have to ask :-) |
| 07:53 | <Hixie> | "window" isn't justifiable using only specifications that were in REC in 2004 or earlier |
| 07:53 | <Hixie> | nor is anything relating to how DOM functions are exposed in JS, really |
| 07:56 | <jwalden> | sigh |
| 08:07 | <Lachy> | Hixie, can you test for constants like Node.ELEMENT_NODE? IE lacks support for them |
| 08:10 | MacDome | notes that IE already fails basically every test anyway :) |
| 08:10 | <MacDome> | if they passed Acid3 test as-is I'd be happy :) |
| 08:11 | MacDome | notes that Safari 3.0.4 gets 60% while TOT gets 77% |
| 08:12 | <Lachy> | What's TOT? |
| 08:12 | <MacDome> | I lied, 61% |
| 08:12 | <MacDome> | top-of-tree/tip-of-tree, aka HEAD, aka the latest sources. TOT is an appleism |
| 08:13 | <Lachy> | ok, you mean the latest webkit? |
| 08:13 | <MacDome> | opera 9.5b1 gets 67%, FF3b2 gets 71% |
| 08:13 | <MacDome> | Lachy: yes, the latest webkit |
| 08:13 | <MacDome> | although a new nightly hasn't been built yet |
| 08:13 | <MacDome> | I bet the most recent nightly gets like 75%, there have been a couple fixes tonight |
| 08:14 | <MacDome> | of course, hixie hasn't finished making the test yet, so there are still 30+ chances for failure |
| 08:14 | <MacDome> | so it' more like 40-something % |
| 08:15 | <Hixie> | Lachy: yeah that's already tested |
| 08:15 | <Hixie> | MacDome: safari screws up the rendering way more than, say, mozilla |
| 08:15 | <MacDome> | Hixie: it does render differently than your test expects, yes. |
| 08:15 | <Hixie> | :-) |
| 08:16 | <MacDome> | Hixie: I don't know all of the things which are being tested in the CSS parts yet |
| 08:16 | <MacDome> | Hixie: like what's that red square? |
| 08:16 | <Hixie> | the one with the cat? |
| 08:16 | <Hixie> | that's testing the <object> handling that acid2 failed to test, and which safari therefore failed to get right when fixing acid2 |
| 08:18 | <Lachy> | cool, internal builds of Opera do slightly better than 9.5b1 |
| 08:19 | <jwalden> | Hixie: which part of object handling, incidentally? |
| 08:19 | <Hixie> | processing of Content-Type headers, iirc |
| 08:20 | <jwalden> | haha, exactly the bug I mentioned in a recent whatwg email :-) |
| 08:21 | <jwalden> | and filed, incidentally, as <http://bugs.webkit.org/show_bug.cgi?id=16690>; |
| 08:23 | <Lachy> | Hixie, how stable are the existing tests in acid 3? If I start extracting them and making individual test cases from them, are they likely to change in the future? |
| 08:25 | <zcorpan> | Lachy: does it matter, so long as the tests are correct? :) |
| 08:25 | <Hixie> | Lachy: very likely to change, but that doesn't matter, if you find bugs feel free to file them, they don't become less important |
| 08:25 | <MacDome> | Hixie: so we're supposed to ignore it due to the 404? http://bugs.webkit.org/show_bug.cgi?id=16760 |
| 08:26 | <Hixie> | i don't know if that's the bug, but yes, 404s should cause fallback |
| 08:26 | <Hixie> | but that shouldn't be the bug |
| 08:26 | <Hixie> | acid2 tested for that too |
| 08:28 | <zcorpan> | Hixie: testing <link rel=stylesheet href=not-css> will introduce yet another difference between quirks mode and standards mode... |
| 08:29 | <Hixie> | that's already a difference in firefox |
| 08:29 | <zcorpan> | true |
| 08:29 | zcorpan | doesn't like differences though |
| 08:29 | <Hixie> | and it's important not to treat non-css files as css |
| 08:30 | <Hixie> | otherwise how will we introduce a new stylesheet language? or differentiate css from xslt? |
| 08:30 | <zcorpan> | you honor type="" |
| 08:31 | <zcorpan> | and let absense of type="" mean "text/css" |
| 08:31 | <Hixie> | what if you don't know in advance? |
| 08:32 | <zcorpan> | with xml-stylesheet, i've specced that absense of type="" means text/css. that's what browsers do. i guess <link> could work the same... |
| 08:34 | <zcorpan> | (i.e., to use xslt you have to specify type="" in the PI, or it doesn't work) |
| 08:36 | <zcorpan> | (xml-stylesheet currently requires the resource to be dropped if content-type doesn't match what was expected, like in firefox, but i might change that) |
| 08:38 | <Hixie> | but what if you don't know what the remote resourc's type is? |
| 08:39 | <Hixie> | we need some sort of mechanism for distinguishing remote content's type, whether that be content-type or sniffing or something else |
| 08:40 | <zcorpan> | with <link>, you would always know the type if the type defaults to text/css |
| 08:40 | <zcorpan> | no? |
| 08:41 | <Hixie> | no i mean say i have a URI that points to a stylesheet resource |
| 08:41 | <Hixie> | but nobody knows whether that resource is CSS or XSLT |
| 08:41 | <Hixie> | as it changes from day to day |
| 08:41 | <zcorpan> | ah |
| 08:41 | <Hixie> | what do i put in my markup? |
| 08:41 | <zcorpan> | if you load it in the top-level browsing context then you honor content-type |
| 08:42 | <Hixie> | not that helpful for a stylesheet |
| 08:42 | <Lachy> | why would an author link to a resource that randomly changes between CSS and XSLT? |
| 08:43 | <zcorpan> | oh, now i see the scenario. seems like a non-real-world scenario though |
| 08:43 | <Hixie> | it's not realistic today |
| 08:43 | <Hixie> | but what about in 100 years when we have a new stylesheet language that's insanely better than css? |
| 08:44 | <zcorpan> | you specify <link type="text/inherently-better-than-css" |
| 08:44 | <zcorpan> | s/inherently/insanely/ |
| 08:44 | <Lachy> | you mean when the CSS working groups takes the XHTML2-approach to spec development? |
| 08:44 | <Hixie> | but you don't know if it's css or ibtcss |
| 08:44 | <Hixie> | some designers will use css, some won't |
| 08:44 | <Lachy> | by starting over instead of just making CSS better? |
| 08:45 | <Hixie> | and also, you don't want to require that ibtcss have this extra attribute, when the server can tell the client what the type is |
| 08:45 | <Hixie> | Lachy: occasionally, languages come along that are better enough that they really are worth boiling the oceans for |
| 08:45 | <zcorpan> | Hixie: that's already the case with XSLT and xml-stylesheet, though |
| 08:46 | <Hixie> | zcorpan: and that's a problem we should solve, rather than making it worse |
| 08:46 | <zcorpan> | i don't see requiring an attribute as a big problem |
| 08:47 | <zcorpan> | when we also have the requirement to work with mislabeled content |
| 08:47 | <zcorpan> | (well, at least in quirks mode) |
| 08:47 | <Hixie> | we can avoid that requirement in standards mode |
| 08:49 | <zcorpan> | should i change xml-stylesheet to not default to text/css when type="" is absent? |
| 08:50 | <Hixie> | i would make the type="" attribute entirely advisory, just like with <link> |
| 08:50 | <Hixie> | and make the server have the final say |
| 08:50 | <Hixie> | just like http requires |
| 08:50 | <zcorpan> | also, type="text/xml" and type="application/xml" means xslt in browsers (except ie) |
| 08:51 | <Hixie> | well, if the type is xml, the browser should parse it as xml, and if the namespace is xslt, then treat it as xslt |
| 08:51 | <zcorpan> | yeah |
| 08:53 | zcorpan | revamps xml-stylesheet |
| 09:28 | <othermaciej> | so is there anything in the Gears image manipulation API proposal that should be in Canvas? |
| 09:32 | <othermaciej> | (it doesn't look like it can do anything that canvas can't do, actually) |
| 09:33 | <annevk_zeist> | yeah |
| 09:33 | <annevk_zeist> | maybe they implement it on top of <canvas>? |
| 09:34 | <othermaciej> | no idea |
| 09:34 | <Hixie> | afk |
| 09:35 | <annevk_zeist> | seems they also want to implement postMessage() from the WHATWG |
| 09:35 | <othermaciej> | I suggested that they just make it match the <canvas> API |
| 09:36 | MacDome | met one of the gears dudes the other day |
| 09:36 | MacDome | can't even remember his name, sadly |
| 09:37 | <othermaciej> | I don't really understand what Google really wants out of Gears |
| 09:38 | <othermaciej> | sometimes they seem to begrudge the idea that browsers would implement the same functionality natively |
| 09:38 | <othermaciej> | and seem uninterested in working with standards |
| 09:38 | <othermaciej> | but I figure we need to implement equivalent functionality in WebKit anyway |
| 09:38 | <annevk_zeist> | they did contribute to the HTML5 stuff a lot on the WHATWG list... |
| 09:38 | <othermaciej> | since Gears for Safari is not in a usable state right now and will probably always be behind |
| 09:39 | <othermaciej> | yes, they did help once stuff started getting added to the spec |
| 09:39 | <othermaciej> | which was good |
| 09:39 | <MacDome> | othermaciej: I would expect that gears is most useful for Google for IE |
| 09:39 | MacDome | doesn't know though |
| 09:40 | <MacDome> | othermaciej: as IE doesn't have any gears functionality natively |
| 09:40 | <MacDome> | gears is much less exciting for Safari or FF |
| 09:40 | <MacDome> | IMO |
| 09:42 | <othermaciej> | it's certainly true that IE is less likely to add useful functionality needed for web apps in the near term |
| 09:43 | <othermaciej> | but I would think they might want to make feature requests to browser vendors who are interested in working with them (individually, cause I know they have the channels, or collectively via WHATWG) rather than just slap it all in a browser extension |
| 09:46 | MacDome | shrugs |
| 09:46 | <MacDome> | I would guess that for some of those things it's easier to implement, try it out, and iterate |
| 09:46 | <MacDome> | since certainly some of those things need iteration |
| 09:46 | <MacDome> | feedback from app developers, etc. |
| 09:46 | <MacDome> | and writing your own, does make that an easier process |
| 09:50 | <zcorpan> | http://simon.html5.org/specs/xml-stylesheet5#processing updated |
| 09:52 | <hsivonen> | zcorpan: Re: xml-stylesheet: Validator.nu does not check any PI contents. Should it? |
| 09:52 | <annevk_zeist> | yes |
| 09:53 | <hsivonen> | annevk_zeist: which ones and to which specs? |
| 09:53 | <annevk_zeist> | http://simon.html5.org/specs/xml-stylesheet5 ? |
| 09:54 | <hsivonen> | annevk_zeist: any other? access-control perhaps? |
| 09:54 | <annevk_zeist> | access-control and xbl should probably wait until there are more implementations |
| 09:55 | <hsivonen> | ok |
| 09:55 | <annevk_zeist> | I would expect those to use the same tokenization rules as simon uses for xml-stylesheet btw |
| 09:55 | <hsivonen> | xml-stylesheet5 doesn't look like a stable spec... |
| 09:56 | <annevk_zeist> | maybe it's better to wait then |
| 11:38 | <kig> | http://glimr.rubyforge.org/cake/cakenu.png well, that got out of hand. the svg renders at 15fps though so all i need is a lot of caching and only redrawing changed parts :| |
| 12:00 | <MacDome> | kig? |
| 12:00 | <kig> | doing webdesign |
| 12:00 | <MacDome> | kig: if you have an SVG which performs poorly, I'd like to know about it so we can make it much better :) |
| 12:00 | <kig> | by mixing svg, canvas and html |
| 12:01 | <kig> | (or, planning to) |
| 12:02 | <MacDome> | kig: well, please file a bug if Safari's SVG implementation doesn't blow you away speed-wise :) |
| 12:02 | <MacDome> | we haven't done much profiling, but we'd love to make slow SVGs faster :) |
| 12:03 | kig | renders svgs on canvas ... |
| 12:03 | <kig> | but yeah, i'll check if the svg renders correctly on safari, sec |
| 12:12 | <kig> | nice, 30fps on safari |
| 12:13 | <kig> | but no gaussian blur filter (not that firefox has one either) |
| 12:17 | <kig> | and svg hasn't got much in the way of blend modes |
| 12:17 | <kig> | (even in the spec) |
| 12:22 | gsnedders | wonders how quickly Hixie will reply to email |
| 12:26 | <kig> | though svg 1.2 draft has all the good stuff |
| 12:39 | <MacDome> | kig: if you have features you want from SVG 1.2, you should file bugs :) |
| 12:39 | <MacDome> | kig: however... we mostly think SVG 1.2 is totally wacko |
| 12:39 | <MacDome> | and are ignoring it for now |
| 12:39 | <kig> | yes, that |
| 12:40 | <MacDome> | kig: every time I sit down to hack on webkit, I check the list of SVG bugs :) Rob often scans through them as well and picks of easy ones |
| 12:40 | <kig> | it has everything! including all the things it shouldn't have! |
| 12:40 | <MacDome> | like my favorite: Socket :) |
| 12:44 | <kig> | http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html <- comp-op would be nice, i haven't read the other things |
| 12:45 | <kig> | around 1/3 down |
| 12:45 | <kig> | heck, those'd be nice to have in canvas too |
| 12:46 | <MacDome> | kig: just file a bug asking for http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html#comp-op-prop supportr |
| 12:46 | <MacDome> | kig: we could probably do that pretty easily. |
| 12:46 | <kig> | yeah, i think CG already has all of those |
| 12:47 | <kig> | core image stuff or whatwasit |
| 12:47 | <othermaciej> | I'm not sure it has color-dodge or color-burn |
| 12:47 | <othermaciej> | I'm not even sure what those are |
| 12:48 | <othermaciej> | oh, that's not the 1.2 Tiny draft |
| 12:48 | <othermaciej> | that's an old draft of 1.2 Full |
| 12:48 | <MacDome> | yeah |
| 12:49 | kig | never really understood the purpose of the porter-duff ops |
| 12:49 | <MacDome> | looks like it was dropped from tiny |
| 12:49 | <MacDome> | kig: I doubt we'd implement something out of an old draft of full |
| 12:49 | <MacDome> | unless there were folks actually gonna use it |
| 12:49 | <kig> | yes, i understand |
