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/