| 00:16 | <jwalden> | Hixie: or, really, anything in <http://bugs.webkit.org/attachment.cgi?id=18427>;, but watch out for the ones where the printed message says that I think either can apply |
| 00:18 | <jwalden> | blah |
| 00:19 | <jwalden> | Hixie: createElementNS(null, ":div") can't be tested because ":div" is both an invalid XML name and an invalid QName, so either exception might be thrown |
| 00:19 | <jwalden> | given the spec's prose |
| 00:22 | <jwalden> | oh, blah |
| 00:22 | <jwalden> | I'm wrong about that in the XML 1.0 spec |
| 00:22 | <jwalden> | more blah |
| 00:23 | <jwalden> | it depends on the current XML version |
| 00:23 | <jwalden> | crazy, crazy mess |
| 00:25 | jwalden | wonders whose idiotic idea it was to not put namespaces in XML 1.0 if they wanted namespaces to happen compatibly |
| 00:36 | <anne-mac> | @media not all and (bogus) should not match I think |
| 00:36 | <anne-mac> | in fact, the entire rule should be ignored |
| 00:37 | <anne-mac> | having said that, this might not be clear in older versions of the media queries spec |
| 00:41 | <jwalden> | sigh |
| 00:51 | <othermaciej> | jwalden: which bit were you wrong about |
| 00:51 | <othermaciej> | ? |
| 00:51 | <othermaciej> | ;s |
| 00:51 | <othermaciej> | is ":div" actually a valid QName |
| 00:51 | <othermaciej> | or a valid XML name? |
| 00:51 | <jwalden> | not QName, but it's a valid XML name |
| 00:51 | jwalden | uploads the fixed test to the webkit bug |
| 00:52 | <jwalden> | at least in XML 1.0 |
| 05:32 | <Hixie> | MacDome_: the test is based on this sentence in the media queries spec: "Expressions involving unknown media features or unknown/illegal values are always false" |
| 05:32 | <Hixie> | MacDome_: where i'm interpreting "expression" to mean "media_que... oh. wait. that's wrong. |
| 05:32 | <Hixie> | hm. |
| 05:33 | Hixie | goes to fix the test |
| 05:37 | <Hixie> | yay, it found a new bug in webkit |
| 05:59 | <Hixie> | sayrer: the range tests were a bitch to write, the spec is so damned vague |
| 06:10 | <Hixie> | hey if anyone is around, i just updated the text at the bottom of acid3, what do you think? http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html |
| 06:14 | <jruderman> | it's covered by a red square with a cat in it |
| 06:14 | <jruderman> | i don't see how you can expect the animation to be smooth with the gc hack / "perf test" in the middle |
| 06:15 | <jruderman> | what changed in that text? just 100% --> 100/100? |
| 06:18 | <othermaciej> | the animation is pretty smooth in Safari |
| 06:18 | <othermaciej> | it does visibly pause very briefly around 20 though |
| 06:18 | <othermaciej> | I don't think it's fair to require other browsers to be as fast as Safari |
| 06:19 | <jruderman> | whether perf is adequate depends on the machine and is subjective. i don't think perf testing belongs in acid3. |
| 06:23 | <Hixie> | i think it's entirely fair to requires browsers to be as fast as safari, given what's in the perf test and what the Web is headed towards (big web apps that do DOM manipulation up the wazoo) |
| 06:23 | <Hixie> | the whole point of acid3 is to guide browsers towards being better for running big web apps |
| 06:24 | <Hixie> | jruderman: (btw the red cat is showing a bug in whatever browser you tested) |
| 06:25 | <jruderman> | safari 3. kinda annoying that it covers the instructions ;) |
| 06:26 | <Hixie> | :-) |
| 06:26 | <Hixie> | oh wow yeah, safari 3 covers them up more than the webkit trunk |
| 06:27 | <othermaciej> | Hixie: maybe after a few hardware generations they will have a chance |
| 06:28 | <Hixie> | actually they won't, the test increases the number of loops based on the current time :-P |
| 06:31 | <othermaciej> | exponentially? |
| 06:32 | <Hixie> | no, linearly |
| 06:33 | <Hixie> | it's not really CPU bound, i would imagine |
| 06:33 | <Hixie> | probably more memory-bound |
| 06:33 | <Hixie> | there's a lot of allocation in the loop |
| 06:34 | <othermaciej> | isn't it a lot of allocation of things that are immediately garbage |
| 06:34 | <othermaciej> | ? |
| 06:34 | <Hixie> | not immediately |
| 06:34 | <Hixie> | but yes, at the end of the loop |
| 06:36 | <Hixie> | it creates a date, and then converts that to a string using a lambda, and then creates a text node with that string's value, then creates an element with that text node as a child, then inserts that node into the document, does a regexp on it, sets a class with that element's textContent, and then finally removes it from the document and drops it on the floor |
| 06:37 | <Hixie> | so it's mostly shuffling data around memory, not intense computation. |
| 06:37 | <Hixie> | i thought i'd leave that to sunspider |
| 07:27 | <MacDome_> | Hixie? |
| 07:28 | <Hixie> | MacDome: yo |
| 07:28 | MacDome | thinks it's totally fair to ask browsers to be faster than Safari |
| 07:29 | <MacDome> | Hixie: new bug in WK? |
| 07:29 | MacDome | hurt his thuumb playing guitar tonight :( |
| 07:29 | <Hixie> | WK? |
| 07:29 | <Hixie> | new bug? |
| 07:29 | Hixie | confused |
| 07:31 | <MacDome> | webkit |
| 07:32 | <MacDome> | WK=WebKit, FF=Firefox, IE=Internet Explorer, WC=WebCore, SS=SunSpider, JSC=JavaScriptCore |
| 07:32 | <MacDome> | I think that's all the acronyms I use on a regular basis :) |
| 07:32 | <MacDome> | "<Hixie> yay, it found a new bug in webkit" |
| 07:33 | <Hixie> | oh |
| 07:33 | <Hixie> | heh |
| 07:33 | <Hixie> | that |
| 07:34 | <Hixie> | i fixed a bug, and was expecting webkit to totally pass the relevant subtest |
| 07:34 | <Hixie> | but then one of the next bits of that test still failed |
| 07:34 | <Hixie> | so i was happy |
| 07:37 | <MacDome> | sweeeet. no morning meetings! |
| 07:39 | <MacDome> | Hixie: if you'd liek to demonstrate brokeness in WebKIt, manipulate the DOM not using Range methods and watch the Range get out of sync :( |
| 07:39 | <Hixie> | already in the test |
| 07:39 | <MacDome> | k |
| 07:39 | <MacDome> | Hixie: I also found a few more Range edge cases in my testsing |
| 07:39 | <MacDome> | which I've not yet fixed, but plan to fil a bug on |
| 07:42 | <Hixie> | cool |
| 07:42 | <Hixie> | cc me :-) |
| 07:44 | MacDome | doesn't quite understand what's going wrong with the cursor test |
| 07:47 | <MacDome> | Hixie: why would this match? |
| 07:47 | <MacDome> | style.appendChild(doc.createTextNode('@media (bogus), all { #h { text-transform: uppercase; } }')); // matches |
| 07:47 | <MacDome> | shouldn't it fail to parse? |
| 07:47 | <Hixie> | why would it fail to parse? |
| 07:48 | <Hixie> | it's an expression with an unknown keyword, which evaluates to false, and a media query "all", which always evaluates to true |
| 07:48 | <MacDome> | but ( is not a valid keyword char |
| 07:49 | <MacDome> | Hixie: I mean... the spec isn't very clear. and I'm not sure what our impl is actually doing in that case, maybe @media (monchrome), all would be a better test |
| 07:49 | <MacDome> | since IMO that should also fail due to a misparse |
| 07:49 | <othermaciej> | Range is a crazy API |
| 07:50 | <MacDome> | Hixie: the grammar is quiet clear, the question is if ( and ) can be interpreted as part of a media_feature and thus be an "unknown media feature" and thus be false |
| 07:50 | <MacDome> | Hixie: if they can't be part of a media_feature, than it's a parse error, and is silently ignored |
| 07:50 | <Hixie> | "@media (monchrome), all" would be a very different test, since it would be testing something else on a monochrome UA |
| 07:50 | <MacDome> | IMO it's a parse error :) |
| 07:51 | <MacDome> | Hixie: well, the point there was that it's a valid keyword with extra parenthesis |
| 07:51 | <Hixie> | he spec very clearly says: "Expressions involving unknown media features or unknown/illegal values are always false" |
| 07:51 | <MacDome> | yeah, so the only part of that which applies here is "unknown media features" |
| 07:51 | <MacDome> | since "values" is on the other side of a colon |
| 07:51 | <MacDome> | so can ( ) be part of an "unknown media feature" ? |
| 07:52 | <Hixie> | oh i see, you're saying "(color)" is not valid because it doesn't have a media keyword first |
| 07:52 | <MacDome> | I kinda doubt it. the parser would reject them as being a different token |
| 07:52 | <hsivonen> | zcorpan: restored method="post" enctype="multipart/form-data" on the file upload form. sorry about that. |
| 07:52 | <Hixie> | hm, some parts of media queries say the media keyword is required and others don't |
| 07:52 | <MacDome> | Hixie: it's kinda like saying if @media ,,,,,,, , all { } should match |
| 07:52 | <MacDome> | saying that ",,,,,,," would be an "unknown media feature" |
| 07:53 | <MacDome> | which I would argue is rather a "parse error" |
| 07:53 | <Hixie> | we're arguing different things |
| 07:53 | <Hixie> | i had thought <media_type> was optional, as some of the examples imply it is |
| 07:53 | <MacDome> | Hixie: yes, @media (color) is equally invalid |
| 07:53 | <Hixie> | but it seems the examples are invalid |
| 07:54 | <MacDome> | the spec is quite clear on where parens are allowed |
| 07:54 | <MacDome> | even if stupidly clear |
| 07:54 | <MacDome> | equally so for the "not" keyword |
| 07:55 | <Hixie> | fixed subtest h |
| 07:55 | <Hixie> | fixed subtest l too |
| 07:56 | <jwalden> | Hixie: test 5 isn't done yet, right? |
| 07:57 | <Hixie> | how do you mean? |
| 07:58 | <jwalden> | Hixie: the line which compares against "!!!" -- I don't see how that could possibly be in the DOM at that point |
| 07:59 | <Hixie> | oops, crap, i forgot to fix the tests depending on !!! |
| 07:59 | <Hixie> | when i removed the !!! |
| 08:00 | <jwalden> | heh |
| 08:00 | MacDome | thinks hixie might have actually found a bug finally in kompo's code with test v |
| 08:00 | <MacDome> | so far Kompo's code has been BUG FREE :) |
| 08:01 | <jwalden> | just like all the code I've ever written, right? |
| 08:01 | <jwalden> | and all the code you've ever written |
| 08:01 | <jwalden> | :-P |
| 08:01 | <Hixie> | fixed test 5 |
| 08:01 | <MacDome> | jwalden: oh, my code is never bug free :) |
| 08:01 | <MacDome> | I just write a lot of it to make up for it |
| 08:01 | <MacDome> | and surround myself with people who seem to be good and cleaning up my messes |
| 08:01 | <Hixie> | MacDome: nope, sadly for me, webkit now passes the media queries test |
| 08:01 | <MacDome> | (and seem to enjoy it) |
| 08:01 | <MacDome> | Hixie: oh, was "v' wrong too? |
| 08:02 | <jwalden> | nobody's code is bug-free |
| 08:02 | <Hixie> | MacDome: yeah |
| 08:02 | <MacDome> | oh |
| 08:02 | <MacDome> | Hixie: blame Kompo |
| 08:02 | <jwalden> | 66->67 pass now in my build :-) |
| 08:02 | <Hixie> | there has to be SOME bug here |
| 08:02 | <Hixie> | :-P |
| 08:02 | <Hixie> | the real test i want to do involves shrinking the viewport dynamically |
| 08:02 | <MacDome> | Hixie: there are are a bunch which we don't implement |
| 08:03 | <MacDome> | color-index is one |
| 08:03 | <MacDome> | Hixie: there is a bug I filed on it |
| 08:03 | <Hixie> | oh |
| 08:03 | <Hixie> | well |
| 08:03 | <MacDome> | Hixie: but you're kinda venturing into the obscure now |
| 08:03 | <Hixie> | yes |
| 08:03 | <jwalden> | "now"? |
| 08:03 | MacDome | pulls Hixie back from the crazy weeds before he gets lost |
| 08:03 | <Hixie> | jwalden: ? |
| 08:04 | <jwalden> | Hixie: nothing other than the echoing of bz's sentiments, more or less |
| 08:04 | <MacDome> | woh. suddenly were back up to 73! |
| 08:04 | <MacDome> | 74 if I fix up my :div patch |
| 08:05 | <Hixie> | jwalden: which ones? |
| 08:05 | MacDome | wants to see Darin's patch land and fix all the iterator tests |
| 08:05 | <jwalden> | jwalden: that the tests are getting obscure in what's being tested |
| 08:06 | <jwalden> | I mean, I really don't know that ranges are used all that often, tbh |
| 08:06 | <jwalden> | or would be if browsers all implemented them correctly |
| 08:07 | <Hixie> | jwalden: DOM ranges are used a lot, actually, mostly for handing text selection |
| 08:07 | <Hixie> | handling |
| 08:08 | <Hixie> | people complain about them all the time |
| 08:08 | <Hixie> | that's how i came across the bugs that i tested in acid3 |
| 08:08 | <othermaciej> | ranges are used a fair amount |
| 08:08 | <othermaciej> | TreeWalker and NodeIterator, I think not so much |
| 08:08 | <jwalden> | huh |
| 08:09 | <MacDome> | jwalden: I would agree, I think Ranges are useful |
| 08:09 | <othermaciej> | execCommand is probably used more than either, but has not yet gotten to CR (or even WD yet) in standard form |
| 08:10 | MacDome | is very much in favor of fixing ranges |
| 08:10 | <Hixie> | TreeWalker and NodeIterator would be used a lot more if they actually worked and people knew about them. |
| 08:11 | <jwalden> | Hixie: in moz-land it's been pointed out to me that |var nullInRegexpArgumentResult = 0 < /script/.test('\0script') ? "failed" : "passed";| should correctly return "failed", because test() returns true |
| 08:44 | <Hixie> | i'm about to announce a competition to get more tests for acid3 |
| 08:44 | <Hixie> | http://www.hixie.ch/tests/evil/acid/003/competition/ |
| 08:44 | <Hixie> | can anyone proof-read the rules and see if i missed anythin? |
| 08:47 | <jwalden> | I'd not say 'returns "5"' if you don't want someone to submit something which returns the string "5" |
| 08:48 | <Philip`> | It would be helpful to give an example of how you indicate failure |
| 08:48 | <Philip`> | (like what kind of exception to throw) |
| 08:49 | <Philip`> | It's not really a competition if there's no prizes |
| 08:49 | <jwalden> | I assume Hixie's going to clean up submitted tests to report in the way all the others are reporting |
| 08:49 | <jwalden> | with just as good error messages, etc. |
| 08:50 | <Hixie> | he prize is your name in the source :-P |
| 08:51 | <Hixie> | (and thanks for the other suggestions; fixed) |
| 08:51 | <jwalden> | oh, Hixie: you should add an extra way to display test results that uses window.open with a data: URL, so you can reasonably see all the results without blowing away display of acid3 :-) |
| 08:52 | <Hixie> | yeah |
| 08:52 | <Hixie> | good idea |
| 08:52 | <Hixie> | will look into it |
| 08:53 | <Hixie> | oh oops, i missed off the paragraph saying the name would be in the source |
| 08:53 | <Hixie> | duh |
| 08:55 | <Hixie> | ok, blogged it |
| 08:57 | <MacDomeSleep> | Hixie: looks fine... but I'm sad that you require trunk builds to fail :( |
| 08:57 | MacDomeSleep | had hoped to get away with Safari 3 failing |
| 08:57 | <Hixie> | MacDomeSleep: heh |
| 08:58 | <MacDomeSleep> | I guess trunk builds failing means that it won't be a repeat of one of your existing tests |
| 09:01 | <Hixie> | :-) |
| 09:02 | <MacDomeSleep> | Hixie: you realize that you're deincentivizing us from fixing existing acid3 tests |
| 09:02 | <MacDomeSleep> | encouraging us to wait :) |
| 09:02 | <MacDomeSleep> | hyatt has at least decided to wait |
| 09:03 | <Hixie> | well, if you wait it'll certainly make _my_ life easier :-) |
| 09:03 | <MacDomeSleep> | really? |
| 09:03 | <MacDomeSleep> | why so? |
| 09:03 | <MacDomeSleep> | we're doing lots of work for you! |
| 09:03 | <Hixie> | won't have to keep coming up with new tests :-P |
| 09:03 | <MacDomeSleep> | we're debugging your darn test! |
| 09:03 | <Hixie> | yes, that actually is very helpful |
| 09:03 | <jwalden> | true 'dat |
| 09:03 | <MacDomeSleep> | Hixie: I'm suggesting you not come up with new ones :) |
| 09:03 | <MacDomeSleep> | it's OK if WebKit passes w/ 100% when you release :) |
| 09:04 | <MacDomeSleep> | so long as FF and Opera don't :) |
| 09:04 | <Hixie> | if i were you i would not let the acid3 test affect your priorities either one way or the other |
| 09:04 | <MacDomeSleep> | Hixie: well, I just do it for fun |
| 09:04 | <Hixie> | you should prioritise the bugs based on how important they are |
| 09:04 | <Hixie> | sure |
| 09:04 | <MacDomeSleep> | then again, that's pretty much all my webkit hacking |
| 09:04 | <MacDomeSleep> | my actual "priorities" lie elsewhere |
| 09:06 | <Hixie> | i just meant you as in the project as a whole |
| 09:08 | <Hixie> | bed time |
| 09:08 | <Hixie> | nn |
| 09:08 | <MacDomeSleep> | Hixie: German, French or Italian? |
| 09:08 | <MacDomeSleep> | for some definition of "german" :) |
| 09:35 | <Philip`> | Hixie: Maybe you could test something like http://tinyurl.com/38d3lj if you haven't already - unless something changed since I last looked, WebKit doesn't handle dynamic updates with sibling selectors |
| 09:36 | hsivonen | smiles at Hixie commit message for the subtitle |
| 09:36 | <hsivonen> | Hixie's even |
| 10:22 | <Lachy> | Hixie, why is the subtitle missing from the whatwg version of the spec? |
| 11:01 | <Dashiva> | Lachy: Probably because whatwg doesn't have the same process requirements as w3c |
| 11:01 | <Dashiva> | (to put it in a nice way) |
| 11:12 | <Lachy> | maybe, but we want people to understand that the specs are mostly identical (excluding the metadata at the top), and differences like that might send the wrong message. |
| 11:12 | <hsivonen> | I agree with Lachy |
| 11:26 | <Philip`> | Lachy: The subtitle is metadata at the top |
| 11:29 | <Philip`> | kig: With http://glimr.rubyforge.org/cake/canvas.html#ImageDataFill are you aware that the putImageData won't necessarily draw 640x120 canvas pixels (e.g. it might be drawn at half the intended size in some implementations)? |
| 11:31 | <Lachy> | Philip`, I was just referring to the the links to version history/other versions, copyright statement, etc. |
| 11:31 | <Philip`> | and the abstract? |
| 11:33 | <hsivonen> | is there a sure exec trick for self-restarting a CPython script regardless of what the interpreter and script paths are? |
| 11:33 | <Lachy> | yeah, everything down to the TOC. But, arguably, the abstract should be identical |
| 11:36 | <kig> | Philip`: . uh .. really? |
| 11:38 | <kig> | it's not quite fast enough to be of much use anyhow but screwing up blitting is pretty high on the "why do they even bother"-scale |
| 11:38 | <Philip`> | kig: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#getimagedata says "Note: The width and height (w and h) might be different than the sw and sh arguments to the function, e.g. if the canvas is backed by a high-resolution bitmap." |
| 11:39 | <Philip`> | and the example below says "The data returned by getImageData() is at the resolution of the canvas backing store, which is likely to not be one device pixel to each CSS pixel if the display used is a high resolution display. Thus, while one could create an ImageData object, one would net necessarily know what resolution the canvas expected (how many pixels the canvas wants to paint over one coordinate space unit pixel)." |
| 11:39 | <kig> | oh that |
| 11:39 | <Philip`> | The problem is that WebKit wants to implement it with that kind of scaling, and it seems like a big pain since it'll break everyone because nobody expects it |
| 11:40 | <kig> | i'm correcting for that in the mouse coords (discounting -webkit-transform) but haven't done anything with putImageData |
| 11:41 | <Philip`> | (so it'd be nice to have a better solution for this, where authors don't have to be so careful to not get it wrong and break Safari) |
| 11:42 | <kig> | get the real width and real height, scale |
| 11:42 | <Philip`> | kig: It's not about CSS scaling (or transforms) of the displayed canvas - it's about how many pixels the implementation stores for a <canvas width=100 height=100> |
| 11:43 | <kig> | ah |
| 11:43 | <kig> | search for pixel width & pixel height with one-pixel putImageData + getImageData -combos? |
| 11:45 | <Philip`> | I think you can't get the right numbers from one-pixel ImageDatas, since there might be 0.5 real-pixels per canvas-pixel, or might be 1.5, etc |
| 11:45 | <kig> | okay, so don't use ImageData |
| 11:45 | <kig> | problem solved, let's use gl canvas instead |
| 11:46 | <Philip`> | That makes the feature a bit useless, which isn't a great solution :-) |
| 11:47 | <Philip`> | It'd be nice if we could fix ImageData but I don't know how :-( |
| 11:48 | <kig> | ditch the "ha ha ha the real width of a canvas in pixels is UNKNOWABLE!", perhaps? |
| 11:50 | <Philip`> | kig: The objection to that is that people want to run e.g. Safari on OS X with a 400% UI scaling factor on a really-high-res display, and want the canvas to be implemented with 4x as many pixels per side so that it's still sharp and vector-like |
| 11:50 | <kig> | that doesn't stop you from knowing the width of the canvas in pixels |
| 11:51 | <kig> | canvas.getPixelWidth(), getPixelHeight() ? |
| 11:51 | <Philip`> | Ah, so you'd manually read canvas.realWidth or something? |
| 11:52 | <Philip`> | then I guess you'd use putImageData({ width: w*Math.round(canvas.realWidth/canvas.width), ... }) |
| 11:53 | <Philip`> | and also your array-filling code would take n^2 more time when the scaling factor increases, which sounds like great fun |
| 11:57 | <Philip`> | Maybe it'd be nearly as good to just use getImageData(x, y, w, h) first to get the .width and .height, then overwrite all the .data and put it back |
| 11:57 | <Philip`> | since the extra cost of creating a JS array of integers should be negligible compared to the cost of manipulating it with JS and then converting it back into a C array |
| 12:08 | kig | counted something like nine branches per pixel in firefox's canvas.putImageData |
| 12:10 | <kig> | for each component, errorcheck value, check if float or int, cast accordingly |
| 12:45 | <kig> | Philip`: why doing SVD to decompose transformation matrices into rotate+scale+rotate is a bad idea: http://glimr.rubyforge.org/cake/benchmark.html |
| 12:46 | <Philip`> | kig: Firefox needs to do more comparisons to clamp to 0-255, too |
| 12:47 | <Philip`> | kig: There's broken character encoding on benchmark.html :-p |
| 12:48 | <Philip`> | Also, that does look like a problem |
| 12:49 | <zcorpan> | Hixie: hmm, why w3c version only? i think more people "don't read" the whatwg version |
| 13:01 | <hsivonen> | Philip`: http://validator.nu/?doc=http%3A%2F%2Fphilip.html5.org%2Fdemos%2Fcanvas%2F3d%2Fx3d%2Ftest.xhtml&charset=&nsfilter=http%3A%2F%2Fwww.web3d.org%2Fspecifications%2Fx3d-namespace |
| 13:01 | <hsivonen> | enjoy the creeping featurism :-) |
| 13:07 | <Philip`> | hsivonen: Looks good :-) |
| 13:08 | <Philip`> | though could the "Namespace Filter" words be made non-breakingly-spaced, since there's plenty of horizontal room on the screen and it looks a little inconsistent when it's wrapped? |
| 13:10 | <zcorpan> | hsivonen: now we're talking :D |
| 13:12 | <Lachy> | Hixie, is the prize for the acid3 competition simply being attributed in the comments in the file? |
| 13:12 | <Philip`> | hsivonen: Would it be sensible to emit a warning/comment that there is some filtered-namespace content and it isn't being validated and so the document may not be valid? |
| 13:14 | <Philip`> | Also, it's not clear that this doesn't affect the text/html parser if you try to filter the HTML namespace |
| 13:17 | <Philip`> | hsivonen: Why is http://html5.validator.nu/?doc=http%3A%2F%2Fphilip.html5.org%2Ftests%2Fcanvas%2Fsuite%2Ftests%2Fresults.html (number of <col> != number of columns) an error? |
| 13:17 | <annevk> | for something that only needs a URI the UI of the validator is becoming increasingly complex |
| 13:18 | <Philip`> | annevk: Use http://html5.validator.nu/ if you want to avoid the complexity of XML :-) |
| 13:19 | <hsivonen> | Philip`: yeah, the length of "Namespace Filter" is a problem. I have to try out different options with that one |
| 13:20 | <hsivonen> | Philip`: presumably you'd put stuff in the filter field in order to suppress messages, so a warning wouldn't be very productive. Could be argued either way, though. |
| 13:21 | <hsivonen> | btw, there might be a bug with the automatic schema selection mechanism and the namespace filter. need to debug :-( |
| 13:21 | <zcorpan> | hsivonen: the encoding override emits a warning... i'd expect namespace override to emit a warning as well |
| 13:21 | <hsivonen> | Philip`: I can't recall if the col thing is based on HTML 4, WHATWG list email from Hixie or my own judgment |
| 13:22 | <zcorpan> | otherwise it's easy to fool people that a document validates when they're not paying attention to the URL |
| 13:22 | <hsivonen> | annevk: http://html5.validator.nu/ has simple UI. for the generic case, people want to be able to do stuff while others want simplicity. UI design is hard. |
| 13:23 | <Philip`> | People could put "Valid XHTML5!" buttons on their web page, linking to the validator with nsfilter=http://www.w3.org/1999/xhtml |
| 13:23 | <hsivonen> | annevk: in any case, you can paste a URI in the Document field and hit return and get sensible defaults |
| 13:23 | <hsivonen> | zcorpan, Philip`: ok, I'll add a warning |
| 13:24 | <hsivonen> | schema override doesn't warn though |
| 13:24 | <hsivonen> | by design |
| 13:24 | <zcorpan> | that's fine :) |
| 13:25 | <hsivonen> | annevk: not that on the HTML5 side, encoding override and ns filter are subtle :-) |
| 13:25 | <hsivonen> | s/not/note/ |
| 13:26 | <hsivonen> | Philip`: I think I'll add JavaScript for dimming the ns filter field when an HTML parser option is chosen. |
| 13:26 | <annevk> | hmm, I'd think html5.validator.nu should be on validator.nu and what's now on validator.nu should be on advanced or complex.validator.nu |
| 13:26 | <annevk> | but nevermind |
| 13:27 | <hsivonen> | Philip`: I don't know how to communicate the applicability when the parser choice is in the auto state |
| 13:27 | <hsivonen> | annevk: yeah, that has occurred to me |
| 13:27 | <hsivonen> | annevk: at least I should make links between them |
| 13:28 | <annevk> | in the end i'd want this validator to be on w3.org but that may be hard :) |
| 13:28 | <Philip`> | hsivonen: I'm not sure how much it matters since the only thing that would affect text/html is filtering http://blah/xhtml, and that's a silly thing to do |
| 13:28 | <hsivonen> | Philip`: actually, there's also the XML namespace |
| 13:29 | <hsivonen> | Philip`: since the implementation of lang is magic |
| 13:29 | <Philip`> | Ah |
| 13:29 | <Philip`> | Still doesn't sound like anyone would have a valid reason to filter namespaces from text/html, though |
| 13:30 | <hsivonen> | annevk: http://lists.w3.org/Archives/Public/public-qa-dev/2007Dec/0000.html |
| 13:32 | <hsivonen> | food before software fixes... |
| 13:32 | <annevk> | ah cool, discussion seems to continue as well |
| 13:56 | <annevk> | crap |
| 13:57 | annevk | only saw the first four e-mails of the <canvas> security stuff |
| 14:54 | <MikeSmith> | annevk (or anybody) - Can you find out when the first public release of Opera with XHR support was? |
| 14:54 | <MikeSmith> | If so, I would appreciate it. |
| 14:55 | <MikeSmith> | I guess it would have been a development/beta release of Opera 8 |
| 14:55 | <MikeSmith> | early 2005 or late 2004 |
| 14:55 | <annevk> | http://snapshot.opera.com/windows/w760p1.html |
| 14:56 | <Philip`> | MikeSmith: http://annevankesteren.nl/2005/04/opera-8 has relevant comments like "Opera 8 only supports enough of XMLHttpRequest to get gmail working correctly. They're only supporting it because of gmail." |
| 14:56 | <annevk> | (g opera xmlhttprequest changelog) |
| 14:58 | <annevk> | oh, I was still promoting xml:id back then |
| 14:59 | <hsivonen> | Opera 8 lacked quite a bit HTTP header manipulation stuff |
| 15:03 | <MikeSmith> | "2004-08: First public release of Opera with XHR support (v7.60 Technical Preview for Windows)" |
| 15:04 | <MikeSmith> | is probably good enough for me |
| 15:04 | <MikeSmith> | since elsewhere I already have: |
| 15:04 | <MikeSmith> | 2000-07: XMLHttpRequest support lands in Mozilla codebase |
| 15:04 | <MikeSmith> | (thanks to Gavin) |
| 15:05 | <MikeSmith> | http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/configure.in&rev=1.692 |
| 15:07 | <gavin> | "XMLHttpRequest support enabled by default in Mozilla codebase" might be more accurate |
| 15:07 | <gavin> | doesn't matter much to me, though :) |
| 15:08 | <Philip`> | When did IE get it? |
| 15:08 | <Philip`> | (or its equivalent) |
| 15:09 | <gsnedders> | Philip`: Trident V, IE7 |
| 15:10 | <Philip`> | (where by "equivalent" I mean the XMLHTTP ActiveX thing) |
| 15:10 | <Philip`> | Oh, apparently IE 5.0 |
| 15:11 | <Philip`> | which would be 1999-03 |
| 15:17 | <hsivonen> | eventually this compound document stuff is going to lead to one huge Web schema and checking that the content type matches the root element |
| 15:17 | <hsivonen> | Atom+XHTML5+SVG1.1+MathML2+XBL2 |
| 15:55 | <MikeSmith> | gsnedders - thanks, I reworded now with your phrasing |
| 15:55 | <MikeSmith> | oops |
| 15:55 | <MikeSmith> | make that, |
| 15:55 | <gsnedders> | reworded what? |
| 15:55 | <MikeSmith> | gavin - thanks, I reworded now with your phrasing |
| 15:55 | <gsnedders> | ah. not me. |
| 15:55 | <gsnedders> | that makes more sense :) |
| 15:55 | <MikeSmith> | gsnedders - thanks to you also, for various unspecified stuff |
| 15:56 | <gsnedders> | :D |
| 16:56 | <MikeSmith> | anybody remember when the first public draft of Web Apps 1.0 was posted? |
| 16:56 | <MikeSmith> | was there any announcement? |
| 16:56 | <annevk> | it's on hixie's site |
| 16:57 | <zcorpan> | WF2 came first... |
| 16:57 | <annevk> | http://www.hixie.ch/specs/html/apps/web-apps-1 |
| 16:57 | <annevk> | oh yeah, started all with http://lists.w3.org/Archives/Member/w3c-archive/2003Sep/att-0014/hfp.html |
| 16:59 | <MikeSmith> | annevk, zcorpan - thanks |
| 17:00 | <annevk> | working on an essey on "recent" web history? :) |
| 17:02 | <Philip`> | I think he's planning to go back in time and stop all these events to prevent the future destruction of human civilisation |
| 17:02 | <annevk> | that sounds more realistic indeed |
| 17:03 | <zcorpan> | i think i read through an early version of WF2 in 2004, probably on hixie's site, before i knew what whatwg was |
| 17:04 | <zcorpan> | when i realised that it wasn't implemented anywhere i thought "why the heck am i reading this?" :) |
| 17:06 | <zcorpan> | i don't remember how or why i was reading it, i was probably trying to learn about xhtml and stumbled upon hixie's blog |
| 17:06 | <Dashiva> | A common feeling |
| 17:06 | <gsnedders> | zcorpan: half the specs I read aren't implemented anywhere, or uniformly differently from the spec. |
| 17:08 | <Dashiva> | Fortran 2003 will rock your world (not implemented) |
| 17:09 | <Philip`> | http://gcc.gnu.org/wiki/Fortran2003 ? |
| 17:10 | <Philip`> | It doesn't appear to be not implemented... |
| 19:44 | <jwalden> | Hixie: another bug -- in test 90, |assert((/(1)\0(2)/.test("1\02")), "NUL in regexp didn't match correctly")| should correctly fail because "1\02" is a two-character string where the \02 is an octal escape |
| 20:08 | <zcorpan> | "character access by index "foo"[1] (part of the ECMAScript 4 spec)." -- http://ejohn.org/blog/acid3-tackles-ecmascript/ hmm, not in es3? |
| 20:09 | <gavin> | don't think so |
| 20:09 | <zcorpan> | then i would guess that acid3 can't test that... |
| 20:09 | <gavin> | although that example does work in a trunk firefox |
| 20:10 | <zcorpan> | yeah, it works everywhere except ie, iirc |
| 20:22 | <Hixie> | acid3 doesn't test that (anymore) |
| 20:22 | <Hixie> | jwalden: thanks, will fix |
| 20:23 | <zcorpan> | Hixie: ok |
| 20:28 | <zcorpan> | Hixie: have you thought about how to be able to run the test on opera mobile or iphone? |
| 20:28 | <zcorpan> | acid2 was no problem, but acid3 causes wrapping, i think |
| 20:29 | <Hixie> | Acid3 requires a browser with a width of 665 pixels minimum. |
| 20:30 | <Hixie> | in opera you'd have to switch to desktop mode |
| 20:30 | <Hixie> | i don't recall how wide iphone's viewport is |
| 20:51 | <othermaciej> | not 665 pixels |
| 20:51 | <othermaciej> | even in landscape |
| 20:52 | <aroben> | othermaciej: but the default viewport is 980px, I believe |
| 20:52 | <aroben> | *wide |
| 20:52 | <eseidel_> | wb dbaron |
| 20:53 | <othermaciej> | oh, the viewport |
| 20:57 | takkaria | bops the w3c and its member-only mailing lists |
| 21:17 | <eseidel> | Hixie: see my comments on http://bugs.webkit.org/show_bug.cgi?id=16797 when you get time |
| 21:17 | <zcorpan> | Hixie: in the reference rendering, opera wraps in the result div at the "/" because the parent has a width of 0 |
| 21:18 | <Hixie> | zcorpan: fixed |
| 21:18 | <zcorpan> | Hixie: thanks |
| 21:18 | <Hixie> | eseidel: oops |
| 21:19 | <eseidel> | Hixie: the "cursor: none;" getting treated as "cursor: crosshair;l" is *awesome* |
| 21:20 | <Hixie> | eseidel: fixed; can't seem to reproduce the none/crosshair issue though |
| 21:20 | <Hixie> | afk biab |
| 21:20 | <eseidel> | Hixie: I think it might be a regression in TOT |
| 21:20 | <Hixie> | k |
| 21:39 | <zcorpan> | "Junto a la definición de HTML 5 también se está haciendo lo mismo con XHTML 5 (Extensible HyperText Markup Language), que no es más que el mismo HTML pero cumpliendo con todas las características del XML y, por lo tanto, aún más estandarizado." -- http://www.frihost.com/forums/vt-87178.html |
| 21:40 | <zcorpan> | oh... so once a vocabulary is serialized as xml, it becomes even more standardized. that's great, then :) |
| 21:41 | <Philip`> | ("Together with the definition of HTML 5 is also doing the same with XHTML 5 (Extensible HyperText Markup Language), which is not More than the same HTML but complying with all the features of XML and therefore even more standardized.") |
| 21:42 | <annevk> | fun |
| 21:42 | <Dashiva> | "More standardized". Nice |
| 22:15 | <zcorpan> | hsivonen: why does validator.nu think that application/octet-stream is an xml mime type? (and non-html mime type) |
| 22:16 | <zcorpan> | (the net effect being that i can't validate extensionless html documents with file upload, even with the lax option set) |
| 22:24 | <zcorpan> | filtering http://www.w3.org/1999/xhtml makes xhtml documents invalid... which is probably a good thing :) |
| 22:37 | <zcorpan> | hsivonen: v.nu doesn't warn about filtered attributes |
| 23:34 | <Hixie> | vote it up :-) http://programming.reddit.com/info/65fdm/comments |
| 23:35 | <annevk> | so the three votes are arve, you and me? :) |
| 23:36 | <Hixie> | i guess :-) |
| 23:37 | gavin | doesn't have a reddit account |
| 23:39 | <annevk> | takes 10 seconds |
| 23:40 | kingryan | is number 5 :) |
| 23:44 | Lachy | registers a reddit account |
| 23:47 | Lachy | is number 9 |
| 23:48 | <hober> | I was 4 or 5 I think |
| 23:49 | <Lachy> | hober, you must have been 4, kingryan said he was 5 |
| 23:52 | <Philip`> | I will attempt to win by waiting until I can get the largest number |
| 23:52 | <Lachy> | Reddit's UI is really horrible. Where do I find the links to the comment pages for other posts? |
| 23:53 | <annevk> | the links that say "comment"? |
| 23:53 | annevk | thinks the UI is pretty obvious |
| 23:53 | <Hixie> | Philip`: you win by convincing other people to vote as well -- it's the count of how many people you can convince to vote for it |
| 23:54 | <Hixie> | Philip`: so far i think i'm up to about 5 |
| 23:54 | <Lachy> | oh, it's just hidden with non-obvious links in the same colour as other text |
| 23:55 | <Lachy> | I prefer Digg, it's so much better organised |
| 23:55 | <Hixie> | Lachy: feel free to vote for that blog entry on digg too :-) |
| 23:55 | <annevk> | i once got on digg, wasn't pretty |
| 23:55 | <gavin> | I thought I was 5 |
| 23:56 | <annevk> | i was one, hah |
| 23:57 | Lachy | twitters the URL. |