Re: Exposing the critical ACTUAL style values?

Apologies for a second response, I decided I should say more.

Shelby Moore wrote:

>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.  
>  
>
I have implemented good presentations of markup content, and there is 
seldom a direct mapping from the content to the type of values that are 
needed from a view.  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.

>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.  How do you get the properties of a line? 
 How about of a column?  How about of a character?

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?

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

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

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.  Casting the content to get the view is unreasonable.

If you want to make it simpler for the user, then by all means do so. 
 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.

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

>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.
>  
>
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.

>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. 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.  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.

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.
[...]

>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
>  
>
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.

[...]

>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.
>  
>
I agree personally that  the W3C efforts to make content and 
applications that can be viewed by any browser is being undermined in a 
variety of ways.

Unfortunately, work done at W3C is determined by the interests of those 
who pay the membership fees and show up at the working group meetings, 
not by the users who benefit from something like interoperability that 
may be lost through inaction.

>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?
>  
>
In the DOM WG I will work on what I am permitted to work on by the 
charter of the working group.  Today, that is what is currently being 
actively developed for DOPM Level 3.

>>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??
>  
>
There is presently no draft that has been sanctioned at all because the 
existing draft was not approved by the membership nor taken through the 
various reviews required.  It is known to be very deficient and has as 
little authority as any note submitted by a random W3C member.

>>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??
>  
>
A significantly-larger number of W3C Members (or members joined together 
by some organization or created group with a web visibility) committing 
resources.  My organization will also probably be harder to commit to 
the activity than we were then, due only to tightness of resources, but 
I think we might pull it off.  How about representatives of three 
browser companies and three experienced application vendors and an 
agreed-upon forum as a magic starting point?  That is way above what we 
had in the DOM WG.  I am not saying that this would necessarily be 
sufficient to restart the activity at W3C (I do not know), but such a 
group could surely do something somewhere.

Ray Whitmer
rayw@netscape.com

Received on Monday, 16 December 2002 13:50:56 UTC