05:05 | <jwalden> | Hixie: another idea for a test -- make sure that the CSS float property can be accessed through the DOM by the property name "cssFloat"; I've heard rumors IE only supports styleFloat |
05:50 | <Hixie> | jwalden: thanks |
05:50 | <jwalden> | np |
05:51 | <Hixie> | if you have any firefox or safari bugs, those are even more valuable... the test is already a mess in IE, we don't really need to add more IE bugs :-) |
05:51 | <Hixie> | but i'll try this one |
05:52 | <jwalden> | I know; I should skim through the list of bugs I'm CCed on and see if there are any that have been around awhile |
05:53 | <jwalden> | Hixie: btw, your use of text-shadow is nice, and I wish Gecko supported it, but (I'd hope!) you're not going to be able to get accurate rendering with it, unless you're just checking that it gets DOMified |
06:01 | <Hixie> | why? |
06:07 | <jwalden> | Hixie: surely CSS wouldn't prescribe exact rendering for text-shadow, would it? |
06:31 | <Hixie> | jwalden_: in the extreme case of there not being a blur radius, sure |
06:32 | gavin | finds it rather odd that jwalden_ and Hixie are having two separate conversations in two different channels on two different networks |
06:56 | <jwalden> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=98694 might be reasonable |
06:57 | <Hixie> | can't test :hover from script |
07:05 | <jwalden> | ah, point |
07:15 | <othermaciej> | you could require the mouse to be in the window and ensure that the feature which should be in :hover covers the whole page and then use getComputedStyle |
07:15 | <othermaciej> | (:hover on a column, yuck) |
07:17 | <othermaciej> | that one's not clearly justified by standards I don't think |
07:17 | <othermaciej> | even if it were testable |
07:17 | <Hixie> | i don't want to require much of reporters at all :-) |
07:21 | <jwalden> | Hixie: <https://bugzilla.mozilla.org/show_bug.cgi?id=312354> might fit a bill |
07:32 | <Hixie> | 26 tests to go |
07:32 | <Hixie> | jwalden: looking |
07:33 | <Hixie> | jwalden: E4X isn't old enough |
07:34 | <jwalden> | Hixie: don't need E4X, just something that will do the conversion -- |var c = node.textContent = {toString: function() { return "string"; }};| would do the trick -- is c a string or an object? |
07:34 | <jwalden> | or at least that's how I understand it |
07:34 | <Hixie> | oh |
07:34 | Hixie | looks closer |
07:37 | <Hixie> | typeof(window.name = 6) retrns number for me |
07:37 | <Hixie> | as does typeof(document.documentElement.id = 6) |
07:38 | <Hixie> | and typeof(document.documentElement.id = {toString: function() { return "string"; }}) returns object |
07:38 | <Hixie> | i can't reproduce this bug |
07:38 | <jwalden> | hm |
07:39 | <Hixie> | (without e4x) |
07:40 | <jwalden> | Hixie: see comment 3, or try javascript:var re = /x/g; var y; y = re.lastIndex = "7"; typeof y |
07:40 | <jwalden> | it's only a problem when it chains, I think |
07:41 | <Hixie> | var x; typeof(x = document.documentElement.id = {toString: function() { return "string"; }}) still says object |
07:41 | <Hixie> | but your example does fail |
07:41 | <Hixie> | weird |
07:51 | <Hixie> | thanks for that one |
07:51 | <Hixie> | added it |
07:53 | <jwalden> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=385166 is an HTTP compliance one |
07:54 | <Hixie> | not clear that that's a bug |
07:54 | <Hixie> | since HTTP doesn't define error handling |
07:54 | <Hixie> | find bugs is hard :-/ |
07:54 | <Hixie> | finding bugs, even |
07:54 | <Hixie> | or rather, finding usable bugs for an acid test |
07:55 | <jwalden> | except that treating something with the wrong content-type as text/css is clearly wrong, isn't it? |
07:55 | <Hixie> | it's not clear that it has the wrong content-type |
07:55 | <Hixie> | it may have no content-type |
07:56 | <Hixie> | according to http, behaviour is undefined |
08:17 | <jwalden> | <https://bugzilla.mozilla.org/show_bug.cgi?id=398681>, <https://bugzilla.mozilla.org/show_bug.cgi?id=398682>, <https://bugzilla.mozilla.org/show_bug.cgi?id=398686>, <https://bugzilla.mozilla.org/show_bug.cgi?id=398820> for more possibilities (didn't look beyond the summaries, tho) |
08:25 | <om_sleep> | table layout is not very well specified |
08:25 | <jwalden> | and with that I've run through the list of open bugs I'm CCed on |
08:25 | <jwalden> | yeah |
08:25 | <othermaciej> | so not likely to be good fodder for an acid test |
08:26 | <jwalden> | I also was sorta trying to find bugs where the situation hit is one you might reasonably see in a web page, or where the tested functionality is generally useful |
08:26 | <jwalden> | so much of this is edge-case functionality that's not especially useful |
08:26 | <jwalden> | or has easy workarounds |
08:27 | <jwalden> | or similar |
11:06 | <Hixie> | i love when working groups are asked to define error handling and their response is "defining error handling is hard" as if that means they shouldn't do it |
11:10 | <jwalden> | Hixie: btw, totally understandable if you don't want to do it, but if you could throw some testing in the document.createElement(badness) test for createElementNS(badness) that'd be awesome and would save us a little effort ;-) |
11:21 | <Hixie> | jwalden: come again? |
11:23 | <jwalden> | Hixie: it would be convenient to have something like test 22 (maybe just more added to it) which tested createElementNS, possibly for things that only it would have problems handling (qname = "xml:foo" with wrong ns comes to mind as one, for example) |
11:23 | <jwalden> | since I doubt our impl of that is fully correct either |
11:24 | <Hixie> | oh i see |
11:24 | <Hixie> | will do |
11:24 | <Hixie> | sure thing |
11:24 | <Hixie> | bed time now though |
11:24 | <Hixie> | nn |
11:24 | jwalden | should really do that too |
11:31 | <hsivonen> | zcorpan: xml-stylesheet PIs recorded as a feature request |
12:51 | <jwalden> | Hixie: I don't think the |assert(!s.MIN_VALUE, "attribute is a Number");| means what you think it means in test 54; you want typeof == "number", I think |
12:53 | <jwalden> | Hixie: |s.match| is a function because |typeof s == "string"|, but the MIN_VALUE property only exists on the Number ctor |
12:54 | <jwalden> | Hixie: also, the messages in those two asserts seem to have inverted logic |
16:11 | <zcorpan> | Hixie: ping |
16:36 | <hsivonen> | Hixie: regarding plain text form submission and almost arbitrary cross-domain POST: the hazard can be neutralized by servers not accepting text/plain POSTs, right? |
19:48 | <gsnedders> | Lachy: I have no MS-DOS 5 installed :( |
20:57 | <Hixie> | jwalden: i thnk you misread them |
20:57 | <Hixie> | hsivonen: yes |
20:57 | <Hixie> | zcpong |
20:58 | <jwalden> | Hixie: how so? |
20:59 | <Hixie> | jwalden: the assert message is the error message shown when the assert expression is false |
20:59 | <Hixie> | assert(!s.MIN_VALUE, "attribute is a Number"); |
20:59 | <jwalden> | oh |
20:59 | <Hixie> | the expression is only false when s.MIN_VALUE is present, thus when it is a Number |
21:00 | jwalden | prefers messages of the form "should be" for unambiguity |
21:01 | <jwalden> | Hixie: except that MIN_VALUE isn't on any object in JS but Number (not numbers, not Number instances), so the test is over-permissive -- !s.toFixed would be better |
21:02 | <jwalden> | toPrecision, &c. |
21:04 | <Hixie> | it caught the error in the browser is was trying to catch the error in :-) |
21:04 | <hsivonen> | Hixie: what was "yes" in response to? |
21:04 | <Hixie> | 17:42 < hsivonen> Hixie: regarding plain text form submission and almost arbitrary cross-domain POST: the hazard can be neutralized by servers not accepting text/plain POSTs, right? |
21:09 | <jwalden> | zounds |
21:14 | <hsivonen> | Hixie: ok. so in that case, the threat of scripted form POST isn't at all the same as the thread of cross-domain XHR POST without access-control pre-flight |
21:14 | <Hixie> | hsivonen: few servers if any check the content-type header. |
21:29 | <hsivonen> | http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080107/ |