Re: CSS WG - Pulling Back the Curtains

On Fri, Mar 28, 2008 at 10:42 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Friday 2008-03-28 09:54 -0700, Garrett Smith wrote:
>  > It is painfully frustrating to observe and do nothing. They're now
>  > talking about some silly filters proposal, yet I can't even get:-
>  >
>  > document.defaultView.getComputedStyle(el, '').getPropertyValue('margin')
>  >
>  > To work in any browser.
>

It appears that you have replaced the reply-to field with MY email address. Why?


>  For what it's worth, if you want issues like this to be addressed,
>  you'll have much better chances if you raise them in an appropriate
>  thread.
>

It is easy to ignore a mail message. It is not easy to ignore failing
tests. Now if the test were written such that:-

var actual = document.defaultView.getComputedStyle(
document.getElementById("testNode") ).getPropertyValue( "margin" );
StringAssert.isEmpty( actual, "margin was not the empty string, but
should have been." );

- Debate would no doubt resolve towards an answer. What is it going to
be, emptry string, or a useful value? The test case cannot be written
without knowing the expected value.

Failing, red, testcases are harder to ignore.

The specs lack automated test suites. Examples don't cut it. There
really isn't a good testing framework for this. I'm aware of JSUnit
(hate it), Selenium (not appropriate). YUI Test is pretty good, but it
relies on YUI, which uses browser detection, so I can't recommend it.

These need to be accessible to users (page authors), not just
implementors. What they'll accomplish is flexibility, instant
verification of any change, and feedback and community involvement.
Automated unit tests have the power of thoroughness that is lacking
with acid tests.

>  (In this particular case, it doesn't work because 'margin' is a
>  shorthand property.  While 'margin' is doable, shorthands aren't
>  doable in general, and a rule that they all just don't work here has
>  some advantages.)
>

It's possible. Return either one or four values. It's that simple. It
would also avoid problems like "auto", which to me, is a useless value
-

parseInt("auto") => NaN -

The value "auto" still requires the browser to compute the measurement
I want to get.

Again, a unit test showing an expected value would address the
problem. Not an example, a test. The test should be released with the
spec.

Garrett


>
>  -David
>
>  --
>  L. David Baron                                 http://dbaron.org/
>  Mozilla Corporation                       http://www.mozilla.com/
>

Received on Friday, 28 March 2008 18:20:02 UTC