Re: Exposing the critical ACTUAL style values?

At 08:08 PM 12/15/2002 -0800, Ray Whitmer wrote:
>I lead the effort to try to produce such a standard for what I believe 
>you are requesting.  Unfortunately, it did not have the backing of 
>enough participants besides myself (not any that I can remember towards 
>the end).

Ray thanks for your reply.  I just read (11pm CST) in more detail your DOM
Views and Formatting draft spec, which IS the general concept of what I am
requesting:

http://www.w3.org/TR/DOM-Level-3-Views/views-formatting.html

I wonder if one reason this spec did not garnish more interest is because
the spec may require a lot of work to implement.  I think there may be a
much easier way to get the necessary generality.  More on simplication below...

Wondering if another possible reason may be that the 2 main browsers
entities have their own proprietary application frameworks to protect.  I
see a new book, Creating Applications with Mozilla
(http://www.oreilly.com/catalog/mozilla/), about the Mozilla framework
(XUL, etc) was published recently by O'Reilly.

The problem is why do we need XUL when we already have XHTML and CSS (and
EMCAScript and other language bindings), or more specifically IMO we do NOT
need a another new proprietary front end.  What we need is simply the W3C
standards API for the backend (rendered layout/view), since we already have
W3C standards for the front end (the content, style, and scripting).  In
short, I am saying we've been down (and still stuck in) the proprietary
road with IE WebBrowser API.  Whose to say that Mozilla XUL will transport
to other vendors, if Mozilla is unwilling (or unfunded) to make some needed
feature or bug fix.  I understand Mozilla is open source but very few know
the source well enough to make changes in reasonable time.  Why should be
we jump to a _PROPRIETARY_ framework from an open source project with
dubious marketshare, runtime reuse, staff/funds, when we are already using
a _PROPRIETARY_ solution from market leader IE?  It is not compelling risk
as an investment.

Whereas, I think if the DOM Views and Formatting spec was simplified for
implementation, then we could hope that Mozilla, KDE, and Opera would
implement it on top of the existing DOM support for XHTML and CSS.  Since
the primary objective of this spec is for an application framework, then it
really doesn't matter if IE supports it initially.  A wealth of
applications is all that is eventually necessary to force implementation.
I am confident one of the major browsers will want to target the "W3C
standard application framework" market, or someone will start a new open
source project for it.

I applaud you for leading this spec, and I think your general abstract
object model is clever.  However, I think it is redundant to implement
partially because it requires basically a redundant implementation of the
DOM as Segment types.  I understand the View is to be abstractly orthogonal
to the DOM and CSS, because a View will have properties, methods, and
events which do not map one-to-one to the content specification.  However,
I do not see why it can't be so, while still leveraging the existing DOM,
CSS, and scripting specifications and implemenations.  

Specifically I suggest that the View's Segment properties for any object be
exposed by cast and method call of any node of DOM.  The eliminates the
Match model.  Matching can be performed with scripting on the DOM and thus
could be left for future spec if necessary at all.

Then all that remains is to define a Properties and Actions model for
Segment.  You have the critical visual media Properties enumerated already.
 However, I think somehow leveraging CSS properties might simplify
implementation and specification.  I understand there isn't a one-to-one
mapping, so only exclusions, differences, and caveats need to be specified
to leverage and track the CSS as orthogonal specification.  For example,
reuse the CSS box model properties for visual layout, and state
differences, e.g. that coordinates and lengths are always resolved to
ACTUAL values, regardless of the display property of the node.  It seems to
me, although this may not be perfect (nothing ever is), it is far advanced
with minimum effort because the CSS has to consider carefully the backend
implementations and media types.

We need also Methods, e.g. AddToSelection(), SetFocus(), HitTestChildren(),
etc.  HitTestChildren() for example could correctly use the layout engine's
knowledge about transparency and non-rectangular (or even non-visual) node
shapes, instead of a less powerful rectange Match.

So for example:

View v = (View)((DocumentView)document).getDefaultView();
Segment q = (Segment)node.getViewSegment( v );
// Now manipulate Properties and Actions of Segment

If you agree with me that the compelling use case for first release is
application frameworks, then my above suggestion eliminates the following
major RED highlighted issues from top of your current draft:

Issue VF-Issue-2
Issue VF-Issue-3
Issue VF-Issue-5

As the beginnings of an application framework, we also need some way for
the content side scripting to communicate with the owner of the backend in
both directions.  In IE, window.external is overloaded.  Some similar
standard mechanism is needed.

For example, until we have such a standard, we can't consider making a Unix
port of Cool Page, our very popular (for novices) web page creation tool.
For one, our Plugin API leverages the IE WebBrowser control and
window.external DOM extension.  And until we decide it is commercially
worthwhile to make a leap to next level in our application framework, we
really can't implement many W3C standards due to technical limitations of
our framework.  3Dize, Inc. (i.e. coolpage.com) does not have the
economy-of-scale of Macromedia (Dreamweaver) or Microsoft (FrontPage), to
roll our own framework.  Or if we do, then we need to make sure others will
help us amortize that investment.  We would have to leverage standards and
contribute to open source.  Our only other reasonable option is to dig a
deeper hole by investing more in proprietary frameworks.  We are at a
crossroad, and I think the W3C is also.

That is how important I think this issue is.  I think without it, the
entire W3C effort will be undermined, because where the applications go, so
goes the market share.

Others have thought that the distribution controls the market share.  Maybe
before the instant distribution of the internet (I am also CEO of
DownloadFAST.com)


>It is an important issue, but until a lot of member companies take 
>interest in the work that was done and left due to lack of interest, I 
>do not see how it would move forwards.

I think with a clearer focus on application framework, then someone (maybe
myself and collegues) will pick it up as open source, if all the majors
refuse.  Either by contributing to an existing open source project
(Mozilla, KDE, etc), or starting a new one.

Any one else interested in a W3C standard application framework?


>Any outside companies or organizations are certainly free to work 
>towards a standard either using the initial draft (very unproven and 
>incomplete) or their own.

Sure but what is the barrier to getting W3C to sanction an at least more
mature draft??


>I agree with you 100%, but there isn't a lot that can be done until we 
>have a group of companies interested in it.

You've got two (DownloadFAST.com, Inc and 3Dize, Inc. (coolpage.com)).
Specifically what do you need??

Thanks,
Shelby Moore

Received on Monday, 16 December 2002 02:35:33 UTC