W3C home > Mailing lists > Public > www-style@w3.org > April 2008

Re: [cssom-view] small update

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 11 Apr 2008 13:52:53 -0700
Message-ID: <c9e12660804111352p1c2f7d75x87ec24d3bef6bcb4@mail.gmail.com>
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: Www-style <www-style@w3.org>

On Fri, Apr 11, 2008 at 12:50 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>
> > It is a direct response to your statement, just above it. Your
> > sentence that updates won't always migrate until they're updated
> >
>
>  What Anne actually said, complete with what he quoted:
>
>
>   > people are still using legacy systems.
>   > 40% of "my" site's visitors are still using IE 6
>   > and another 40% IE 7, and anyone using IE 6 will
>   > not upgrade to IE 8+ any time soon. Any attempt to
>   > standardize quirks mode must take into account IE's
>   > existing behaviour and not assume that IE can "fix"
>   > anything.
>
>   This problem is not exactly unique to what we are discussing
>   here. Updates to CSS (and other Web specifications) in
>   general will not always migrate to such environments until
>   they are updated.
>
>  I guess you got confused as to the antecedent of "they".  I thought given
> the context it pretty clearly meant "such environments", and not "updates to
> CSS".
>
>  In other words, we can spec whatever we want, but users won't have UAs that
> can do it until such UAs ship and users update to them.  This applies to
> clarifications of existing things, additional features, everything.
>

What users will have is a suite of tests that define exactly what the
spec does.

The problem here is the assumption that Microsoft will implement the
bad ideas, or ideas based on bugs, and in so doing, will break
millions of pages.

The solution is to think of a practical solution.

It's certainly possible to write tests for new features.

Existing features that don't work consistently, don't fulfill use
cases, or are buggy can be tested. The problems can be shown in tests.
Making a spec out of buggy features is dumb. Waste of time.

>
>
> > Most of these issues haven't been mentioned yet.
> >
>
>  I get some of this as a UA implementor.  "There's a bug on this page, but I
> won't tell you what it is."  To be honest, the only sane response is to not
> try to mind-read and instead focus on other tasks where there is enough
> information to make progress.
>

No, Boris, what you "get" is some frustration that you want to point
at me. This is not a "bug." I'm not "filing" anything. Do not get
confused here - my point is that CSSOM Views should be scrapped and
rewritten. I do not appreciate being misrepresented, Boris.


>  In other words, just mention the issues if you have them.  One mail per
> issue, ideally, so there is no confusion and issues don't get lost.

I started with offsetTop and the discussion fell apart.

The only sane approach would be not to waste time discussing a
specification that is mostly bad and instead be proactive and produce
a specification that might actually be useful. That is the point, or
"issue".

I think Microsoft should step up and be proactive in tackling this
issue. I've got my proposed ideas here on my local drive.

Garrett

>
>  -Boris
>
Received on Friday, 11 April 2008 20:53:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT