Re: [cssom-view] New WD "CSSOM View Module"

On Tue, Feb 26, 2008 at 6:27 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 26 Feb 2008 23:09:08 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
>  wrote:
>
> > <!DOCTYPE html>
>  > quirks mode.
>  >
>  > Where are the tests in CSS1Compat mode?
>
>  That DOCTYPE does not trigger quirks mode.
>
Right. Thanks for the clarification.

The tests are CSS1Compat, but the spec seems to be based on quirks mode.

CSSOM offsetXXX need to be removed  from the CSSOM spec.

No browser implements the spec as written. The browsers are "locked
in" - 100% compliant change among browsers is unlikely.

Even if the browsers could change, the spec has a few serious flaws.

>  > What's needed is an automated test. I've already gotten started on
>  > one, but I want to host it not on my site, but somewhere with a
>  > repository so tests can be CRUD'd by multiple users.
>
>  Maybe start a Google code project?
>
I'm sensing some sarcasm in this, as if you read my blog and wanted to
make a comment.

But to take it seriously.
  Pro: Would allow SVN access for myself and w3c members.
  Con: If not be used by w3c members, would take my time and have no
benefit to w3c.

A peer-reviewed, automated test would reveal a lot more about how
[property_x] is implemented in various browsers. It would provide a
better overview about how each browser handles different cases. This
would make comparison easier by revealing more data at one time. It
would provide a quick overview of all failure/success expectations and
results.l It would be easier to maintain. It would seem to avoid
confusion and lead to a better spec.

Does the w3c generally use Google Code? I have not seen this before. I
see that the demo pages that you've made are being hosted on w3c, not
Google Code.

>  >>  Yes, this specification tries to find a middle ground.
>  >
>  > As a result, it is broken/useless.
>
>  I think I disagree. There may be some areas that are in need of
>  clarification (and I've made some edits earlier to that effect), but other
>  parts are already being used by implementors.

The reason it has broken the web is that parts of the CSSOM spec are
being used by implementors.
http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=oD8&q=offsetTop&btnG=Search&lr=

You're in the top 10. People are reading and linking.

The problems caused can be seen in every popular javascript library.
These libraries painfully struggle (and fail in all but the simplest
cases) to find the precise coordinates of [any_element] in
[insert_browser_name_here]. Most of these scripts use browser
detection which prevents browsers from changing or fixing bugs.

The spec has resulted in contrasting implementations of offsetXXX.

This puts unfair burden on web developers. The burden is not small. I
know this personally because I've grappled with this problem for days
longer than I care to admit.

I think it's safe to say that CSSOM has broken the web.

>  >> I'm not sure what
>  >>  you mean with contradicting CSS 2.1. Where does that happen?
>  >
>  > The part that contradicts CSS2.1 the CSSOM spec says:
>  > "If any of the following holds true return null and stop this algorithm:
>  > ...
>  > " A is the HTML body element."
>  >
>  > CSS2.1, 10.1 Definition of "containing block"
>  > "... if the element's position is 'relative' or 'static', the
>  > containing block is formed by the content edge of the nearest
>  > block-level, table cell or inline-block ancestor box."
>  >
>  > It is contradictory because:
>  > A positioned element forms an offsetParent. If body has position
>  > static, it is not a positioned element. How can BODY be an
>  > offsetParent?
>
>  I don't see why offsetParent needs to be the containing block.

Here's why offsetParent needs to be a containing block:

An offsetParent P of A needs to be a containing block in order to
determine A's offsetXXX layout coordintes respective to it's
containing block. In fact, it is already part of the CSSOM spec for
offsetParent, which states ---

"...
Return the nearest ancestor element of A for which at least one of the
following is true...
* The computed value of the position property is not static.
* It is the HTML body element.
..."
---

CSSOM seems to treat BODY as if it were a containing block, because
right after that

"It is the HTML body element."

This makes it impossible to determine the position of an element
relative to its containing block, when the element's parent is BODY
and it's containing block is HTML. CSSOM prevents determining the
coords of the BODY element.

The browsers have different implementations - from each other and from
the spec. Should all the browsers change? Won't that break existing
scripts? Should the spec change? Would that be fair to any browser?

Or should CSSOM offsetXXX properties should be removed from the spec
and replaced with something new?

Garrett

>  --
>
>
> Anne van Kesteren
>  <http://annevankesteren.nl/>
>  <http://www.opera.com/>
>

Received on Wednesday, 27 February 2008 23:16:41 UTC