Re: Exposing the critical ACTUAL style values?

Ray,

Your points in 2nd email are worded more forcefully, so please do not take
it personally if I respond with equal force to make my points.  Our goal is
same.  Quickly this needs to efficiently lead to workable path forward,
else I am sure we will both tire quickly (since only the 2 of us so far).


> It was my opinion at the time that the model 
>advocated would actually be quite trivial to wrap around existing 
> implementations

Also consider the other compelling use for first release would probably be
to provide standard api for DHTML.  Actually one could argue this should be
the only first case.  In this case, much more than a lot of code depends on
reading the Offset* properties from the node.  So backward compatibility
was another possible motivation for re-using the DOM and existing
scripting, versus making a new matching specification for enumerating
properties of those nodes of the DOM.  Basically KISS.

My goal is in the real world of commercial success, to always reuse
existing work where possible, and typically to rewrite bad designs before
digging deeper hole.  Which is related to why I am here at this cross
roads.  Which is why I am surprised that you frown on virtual methods.  I
have never been involved with a failed commercial project.  Every major
project I have touched has lead in it's market.  From WordUp with > 15%
market share on AtariST, to what became Corel Painter (the world's first
natural media painting app), to Cool Page (our current popular product for
novices which is at a cross roads).  How many programmers have hit 3 major
homeruns in commercial (mass market) programs?

DIGRESS: I am even quite astute (or you may say lucky) at picking the
winners at the early adopter stage (after my mistakes in youth on AtariST).
 For example, I adopted PHP and MySQL in 1999.  I adopted MFC and Win32 way
back before I can remember.  I adopted CSS positioning for Cool Page at the
earliest possible time and found a way to make it work CONSISTENTLY on
NS4.x+ and IE4+.  I am preparing to shock the world with a whole new
paradigm for layout editing.  Etc..


>I have implemented good presentations of markup content,

Cool Page has a simple one (does not use the browser to render content),
but I would not say it is good or general.  But it efficiently does the
limited job it was designed for being not dependent on browser or
proprietary apis.


> and there is 
>seldom a direct mapping from the content to the type of values that are 
>needed from a view.

It depends on the goal.  It wouldn't hurt to expose the content
transformations as a first step, since conceptually (deciding what to
expose and what not to) it is the most obvious and leverage existing work
on what is important.

For DHTML, the DOM transformation to the rendered view is very often what
is needed.  One is typically needing to know what the position, z-index, or
state of content node is within the rendered view.  Even for using the
browser as the rendering agent for Cool Page, I think the one-to-one
mapping addresses many of the needs, which could be supplemented as
necessary.  For example, if Cool Page wanted to know what color the link is
currently rendered as (to show user current color for editing), then the
ACTUAL style value is what is needed.  Similarly for z-index, position,
selection state (not CSS yet?), etc..


>  I don't think this is a real obstacle.  Matching or 
>QIing is little difference.  With appropriate conveniences, they should 
>be nearly indistinguishable from the user's perspective.


I do not (yet) see a compelling reason to reimplement the DOM for each
special case module.  That seems to me to fly in the face of OO paradigm--
which espouses maximum reuse.

It is disruptive.  It is also likely impacts on backward compatibility (or
at least ease of forward migration).

The Match interface could come later if a compelling need is demonstrated
after at least covering the basics in the least disruptive manner possible.
 Is there a compelling case of future generality that is lost by starting
with reuse of the DOM??



>>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.
>>  
>>
>This denies the nature of the formatting problem.  There is no 1:1 
>correspondence between these.


Actually I was probably going to suggest dropping the Formatting from the
module.  What is the compelling case of first release use for Formatting?
And what do you mean by "Formatting"?  Isn't all formatting done by editing
the content?


> How do you get the properties of a line? 

Agreed this is an important special case not in content.  Cool Page's
presentation class creates an array of line properties.  But I am not sure
this is very necessary for first release.  For first release, the browser
could handle line issues internally with normal unattended user interaction
(such as cursor to end of line or beginning of line), and expose only
current selection and importance issues.  With a HitTestChildren(), which
could take either a point, rect, polygon, etc, then you can deduce these
metrics in a slow way for interim, although I not advocating that use.

In any case, I think this is best exposed as an extension to DOM-- a
extended interface for nodes to get more detail information about inline or
replaced sub-content.


> How about of a column?

CSS3 has Columns.  I think they are working on words.  And I had a long
debate yesterday about sentences.

>  How about of a character?

Some form of HitTest() plus a CursorEvaluator which can return properties
at the cursor perhaps.  I think exposing non-CSS (non-content) things in
chunks (in context) is more OO than a global Segment properties
enumeration.  Incremental design always wins if OO is used properly.  An OO
is incremental design.


>If you ask for the segment of a "bold" tag, what does this mean if the 
>bold starts on one line and finishes on the next?

What ever CSS properties are allowed on <B>.  From the content, we know it
is immutable in content.  What additional properties could we need in
compelling first use case?


>If you ask for the segment of a paragraph, what does this mean when it 
>starts in one column and finishes in another column?

I think you are asking about nodes which are not of much interest in the
View from the perspective of first compelling use applications.  As more is
learned, additional properties can be added to the extended interface of
the DOM.

I am just advocating building on the DOM and CSS, then extending and
caveats from that foundation.

It makes sense to me that if the applications are basically trying to sync
what is happening on content side (where they edit) with the actual state
and actions in the view, then the 1-to-1 mapping is the most obvious
logical first step.


>A character has no corresponding DOM object, so how do you get the 
>position and size of it?

First you need to identify the character.  So I say this is block level
node.CharAtOffset(), which could be result of a HitTest().

Then query it's interface (class) for properties.  This is OO.  A flat
enumation model of Segment types and properties is not.


>The presentation of browsers of the future will only get more complex 
>and less direct between content and presentation, and it is also quite 
>likely to want multiple different views of the same content at the same 
>time.


Agreed, which is why we both had the document.getDefaultView() in our 2
examples of psuedo-code.  I assume we would also want
document.getViewByName() etc.

>Casting the content to get the view is unreasonable.

Casting the document to get View?  You were doing that also.

I am casting the content to get an extended interface on the content which
can take a View and return new properties.  Why is that unreasonable?

There is nothing stopping you from also exposing the SAME code in method(s)
of View which takes a Node pointer.

The point is that these are properties of the transformed (rendered)
content, so why not expose them as a transformed interface of the DOM?  Of
course there are some properties which are exclusively View properties,
such as View's position, size, scoll, etc..


>If you want to make it simpler for the user, then by all means do so. 


If someone wanted all methods to be in View, so that it is not possible to
do node.Property, then I have no major qualms with that.  I just think it
is more intuitive to stick with the DOM hierarchy.
node.TransformedProperty is like saying give me x View's transformation of
the DOM.  In fact, the extended interface does not need to be polled on
each node, just once on the document (without error checking):

View* v = (View*)document.GetxView();
ViewTransformedDOM* vtdom = ((View*)document.getInterface( "View"
)).getViewTransformation( v );
Node* n = vtdom.getElementById( ... );
n.TransformProperty (i.e. n.ActualCSSValue)


> But I would not claim it is easier for the browser implementer to 
>answer unanswerable questions than to expose a simple wrapper which 
>corresponds to internal frames, lines, etc. that every reasonable 
>implementation has to have internally.  Once we have refined the model, 
>it will not be difficult from an implementation standpoint.

First you assume there will be lines.  CSS does not guarantee you will get
lines in your View.

And you are defining NEW things which have not been calculated to be
exposed.  Whereas, with the 1-to-1 DOM mapping, the implementation already
calculated the ACTUAL style values on each node.

And above I postulate that many of these news things may be unnecessary in
first release.  And you have to be careful about exposing too deeply and
lock yourself into future.  At least with exposing 1-to-1 you know you are
exposing things that have to be maintained for existing standards.  It is
no brainer to me.  And there is the issue of flat enumeration not being OO,
etc.


>We could discuss making sure finding the segments is simple for the user.

IMO, the Segments should be the Nodes, at least initially.  Segments could
be added later if demand is clearly demonstrated.

>I agree that reuse here would be desirable if it makes sense.  But even 
>being 95% the same does not automatically mean that it is warranted.  I 
>see this determination as details, not really important to this level of 
>our discussion, but CSS is, I believe, not generally a description 
>language for describing actual values.

I mostly agree, except that at least if we expose a 1-to-1 mapping, it is
safer because:

1. CSS is a standard so those values are calculated any way (better chance
our standard gets and stays supported and bug-free...bugzilla :)

2. Less to spec and make mistakes on

3. A one-to-one mapping is what DHTML needs

4. Less chance of exposing too deeply apis which become impossible to
maintain in future (in theory CSS has been designed with great care for future)

Etc (per my comments above)



>>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.
>>  
>>
>Clearly the match algorithm should be as flexible as possible.


It can't Match only children or sub-content of a Node.  It could be
extended to do that though.  I am just saying it is a dangerously broad,
unnecessary, and flat enumeration.  It requires a re-work (non-reuse) to
define new Properties and object model.  It gains some unknown capabilities
at cost of some other known capabilities.




> If you 
>are referring to the fact that it permits a rectangle to be hit-tested, 
>not just a point, that does not seem less-powerful.

My mistake.  Obviously either can take any shape for hit testing and match
using layout knowledge.


>  It is not clear to 
>me that you have interpreted it correctly (but I am not sure I even 
>remember it correctly), that it had that limitation.  If so, it should 
>be corrected.


Again my mistake regardless.


>I would favor a medium-specific HitTestChildren method as a convenience 
>routine that invoked the generic match test in a specific way likely to 
>be useful to the user of the visual medium without denying the power 
>that convenience methods hide in the interest of simplicity for the user 
>of a specific type of media.


Your interest seems to be in a very general and new abstract way of looking
at the rendered content.

Whereas my pragmatic focus in on how to get the basic data we need to edit
content (DHTML and applications) based on the transformed state.  It seems
like we have an immediate problem that should have been address 2 - 3 years
ago, and no interest.  We don't have the luxury of inventing totally new
things.

I'd rather expose the DOM and CSS, then extend from there as more is learned.


>>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
>>  
>>
>I did not see you address issue 5 at all (perhaps you did not understand 
>it), nor were the others addressed conclusively to my satisfaction.  But 
>these are truly details, compared to the caring that has to happen by 
>enough interested parties.


#5 disappears because Segment becomes a Node and there is one-to-one
mapping to DOM and CSS (with caveats).

#3 is reusing values computed from CSS.  The browser better know what color
it is displaying :)

#2 disappears because of using DOM model

See how quickly reuse eliminates the nasty design issues of a new abstract
metaphor?

It is very difficult to teach people to actually use the 80/20 rule.  Or to
use it wisely.

[snip] answered previously

Unfortunately, I am getting the sense that W3C is not the right place to
take up this matter.  It looks like I will stuck with writing my own
proprietary one.  It has always been faster for me to implement than talk
and politic.  But I am here to see if there is any serious interest at W3C
for a non-proprietary Views api.

If I am talking about writing my own (minimal to start) brower (or reusing
poritions of/extending an existing one), then you are looking at at least a
man-year or roughly $300K commitment on my part.  And most likely I would
find it easier and faster to write from scratch than learn for example
Mozilla and be frustrated with their design and personalities.

Any way, I still have an open-mind at this point. And perhaps IE will win,
and I will leverage it for another year or so (Cool Page v4) and then
retire instead.

If anything, I hope my feedback has been shocking to you, given you are the
DOM Lead.  I hope I have laid some questions about fundamental design which
will be useful forward.




Kind Regards,
Shelby Moore III

CEO 3Dize, Inc. (coolpage.com)
CEO DownloadFAST.com, Inc.
sole programmer of Cool Page* (1998-), Art-O-Matic* (1996-8), WordUp*
(1986-90), TurboJet (1988)
contributing programmer to DownloadFAST.com* (2001-2), Corel Painter*
(1993-5), Corel ArtDabbler, EOS PhotoModeler (1996), FONTZ! (1988)

shelby@coolpage.com

* denotes major involvement in massive multi-year R&D projects with
millions of characters (1000s of pages) of code

Received on Tuesday, 17 December 2002 04:31:19 UTC