Re: Exposing the critical ACTUAL style values?

Let me also answer a few of your specific questions below.  I separated
these from the previous response so the fundamental discussion about
abstraction is not muddled with details.

>I certainly have no reluctance to use virtual methods.  Perhaps I 
>misunderstood basically what you mean by "using virtual methods".  I 
>wrote a long response, but I deleted it because I may have misunderstood 
>your meaning of "Using Virtual Methods".  Were you referring to:
>
>1.  My reluctance to make Node castable to XPath and Segments.
>
>This has very solid technical reasons, that have to do with modularity, 
>non 1:1 mappings between content and presentation, the limitations of 
>C++ and Java, etc.


Yes.

I agree C++ (and I'll take your word on Java) have some limitations with
virtual methods with shared libraries, but afaik this can be worked around
(COM, etc), and my understanding is the future will have a elegant
solution, whether it be open source C#, open source .Net, etc..  Also it
seems to me one could deal with the problem in other ways.

Obviously the 1:1 mapping is central to my abstraction which are still
debating.

Afaik, modularity is not reduced with requesting a new interface to an
object ("cast").  Give me one example, and I bet I will tell you how
modularity is maintained.  For example, the Node is an object.  The DOM is
tree.  The Node modularity has not been decreased by tree container.
Requesting a new interface on a treeable object to evaluate it's path
within a tree is not any less modular than passing the object to a path
evaluator object.  Since the path is apparently heavily dependent on DOM
any way, then I think if you separate them, then you are writing a new
implementatoin of path evaluator, thus you can write a new interface for
your new thingy to evaluate paths on.


>2.  The use of generic accessors with string arguments instead of 
>specific accessors.
>
>This only has to do with satisfying some critics who didn't want a 
>potentially-infinite set of interfaces.  I am just as happy to create 
>distinct interfaces to handle these things and instead of having strings 
>have IDL.


I am also equally happy to use string access instead or specific access.
They are really the same thing.  I think specific fits better with the way
DOM properties are normally accessed thru scripting.  String accessors
would make strange looking code.   I think using strings for programming
syntax makes it more dificult to detect user strings (with syntax
highlighting).  Conceptually, extensibly, etc.  there is no difference
between the two.



>>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.
>>  
>>
>Does it rely on extensive formatting to determine where text lands, what 
>fonts, etc, or is it more like a final form or Graphics layout, where 
>there is a strict 1:1 correspondance between presentation and content?


More like a final form.  You can input a content position and get back a
presentation coordinate pair, or vice versa.  I have the specific
calculations at low level, but I don't expose them outside the class.  I do
expose the rendered lines breaks though.


>>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.
>>  
>>
>I know a great deal about transforming content into presentation, but 
>this statement says nothing useful to me.  Which content transformations 
>would you expose, and how would you expose them 1:1?  Perhaps you are 
>only talking about actual computed style values, not things like 
>position, hit tests, physical events, etc.


ACTUAL values with "caveats", which thus include position.

HitTesting could be a View property (separate from the 1:1 properties) or
HitTesting could be a simpler function that walks the 1:1 positions.

Events are another animal :)  I have proposed that CSS and XML Events
coordinated, or new CES Events sheets module created.  I think need to
think more about events.


>The values I am concerned with in the presentation have no corresponding 
>single content object that could be cast to obtain it.


An important example?


>>For DHTML, the DOM transformation to the rendered view is very often what
>>is needed.  
>>
>There is no "DOM transformation" to the rendered view, other than 
>proprietary ones that have been created.
>  DOM defines how to access the 
>content, which either has no view or has a view that is created in a 
>very proprietary way.

Agreed, that is why I want a standard.


>  That is the strength of the markup language -- it 
>is independent of the view.

Agreed, but obviously the markup is transformed into presentation.  The
question I think we are debating is whether it is not worthwhile to try to
maintain a strong correlation between the two.


>>One is typically needing to know what the position, z-index, or
>>state of content node is within the rendered view.
>>
>Such a question is often not answerable.  In some cases, there may be no 
>position in the geometric coordinate sense.

I agree with you that we need to discuss some examples.  Could you give me
case other than time?

If you are referring to alternative media such as aural, then I think CSS
would not define position for such a Node.


>  In other cases, there may 
>be any number of different positions and z indexes, depending upon how 
>the text is formatted, in how many views it is visible, and so on.  You 
>did not answer the questions in my last response about what that really 
>means in common cases where there is no 1:1 correspondance.

I think I finally did.  See previous response to this one.

Give me an example where you think ACTUAL transformed CSS values falls on
it's face in a very important way in the presentation space?


>That is why it is useful to have:
>
>1.  A model that can really give the correct answer, which is not 1:1. 
> An impossible model does not help the implementer to implement.

Which important question?

Which correct answer?

What can I use that answer for that is useful in popular needs?


>2.  Simplifications that keep the simple cases simple.  This obviously 
>needed work in the proposal, and making more-specific APIs instead of a 
>generic API with strings is one possible good course to follow.

I do not think the strings API is any more generic.  It is just a syntax
difference.  One way is a member of object class, the other is a method call.



>>  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 cannot judge with respect to Cool Page, because I do not know how 
>indirectly it's content model is related to it's presentation.

The goal should hopefully be to be as indirect as it can and still get the
job done.


>I agree that the call should be very simple and intuitive to do simple 
>things, just not that it is anywhere close to 1:1 if you expect to 
>expose information on the view and formatting.


Important compelling first use case examples?  (per your own issues list)


>Perhaps what you really want is actual style values instead of a views 
>and formatting model (which is clearly where your original message's 
>title came from).


Yes but by definition these require View (and Format) context.


>>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??
>>  
>>
>I do not understand your comment about reimplementing DOM or not getting 
>maximum reuse by the decisions that were made.


You are declaring new segment types instead of 1:1 mapping with DOM.
People already specify content in DOM.  They need some strong correlation,
more than they need some great abstraction.  The market proves that already.


>If the model is too simple, it is, itself, disruptive,


Agree.  But do not that my idea too simple unless I see compelling examples
otherwise.

> by requiring the 
>implementation to answer questions that cannot be reasonably answered.

I continue to disagree with this concept until I see compelling examples.


>It is not a views and formatting model if it does not permit the obvious 
>disassociation to be properly represented.

Disagree.  There are different ways to abstract the View and Format
(layout).  If your statement were true, then we better expose every pixel.
(that is too forceful of a statement...apologies in advance...but I want to
make a strong point)


>I can easily accept the position that what you want is actual style 
>values, which often DO have a direct association,

Agree.

> unlike a formatted 
>view.


Do not understand your concept of the distinction?

>  But please do not ask for the position of an element in the 
>presentation unless you want a potentially-compound answer.

Again compelling examples that do have CSS properties or property that
would be needed that isn't in CSS??



>>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?
>>  
>>
>Not in any text-based non-final form I am aware of.  Formatting is an 
>integral part of the display process.  The HTML does not store where 
>soft line breaks occur, nor which fonts are used, etc.
>
>Certainly you can have this sort of 1:1 correspondance in final form 
>such as PDF or SVG.
>
>HTML is designed such that it adapts automatically to the constraints of 
>the display device.  If the user resizes the window of a particular 
>view, not only does the position at which an element is presented in 
>that specific view change, but it changes in compound fragments.


You misunderstood me.  See what I wrote in previous response to this one.

Of course I understand the difference between markup and presentation.  It
is kind of depressing you would think that of me, but I will let it slide
:-)  I know Cool Page has a weakness in this area, but I am going to file
for a patent soon on a way to solve it's weaknesses :-)  Please do not
assume such ignorance on my part of the core values of W3C.


>>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.
>>  
>>
>I am not comfortable answering the question "what is the position of 
>this element" without the possibility of answering in-compound,


What else besides time of question?

Received on Tuesday, 17 December 2002 17:46:09 UTC