Re: Exposing the critical ACTUAL style values?

Shelby Moore wrote:

>I did not get off on vacation today as planned.  Maybe tomorrow.
>
>  
>
>>In the HTML DOM, there are certain presentation properties exposed 
>>directly on objects.
>>    
>>
>
>Just to be clear, you are reaffirming there is a precedent for exposing the
>presentation state directly on markup objects, i.e. a 1:1 correlation
>between markup (DOM) objects and presentation objects.
>  
>
If you restate it as I stated it, I will confirm it.  There is much 
precedent in the DOM HTML-specific module for many different things that 
are not likely to become a more generic mechanism applicable to DOM.

>>Please define "transformed state" before I can tell you whether I agree 
>>with you or not.
>>    
>>
>
>I am thinking more abstractly than a specific case or layer.  The
>definition is "any transformed state DERIVED from the DOM markup state".
>  
>
For me, the CSS layers are not necessarily part of the presentation. 
 They serve as inputs to the presentation, much as content does, but 
less abstractly.

>You did not reply yet to my other 2 previous posts, so it is difficult for
>me to know now, where we are in our understanding of each other's views.
>  
>
I may reply.  I think having several huge messages in parallel breaks 
down the attempt at communication.  It is a simple matter of bandwidth 
and interdependencies.

>I will try to elaborate any way.
>
>First of all, I see our fundamental disagreement is on whether transformed
>states can and/or should have 1:1 correspondence with the DOM state.
>Thanks for making the strong point that they can not have 1:1
>correspondence in all situations, and the correspondence may be reliant on
>other variables (i.e. a multi-variant correspondence, e.g. time, etc. as you
>pointed out).  However, it is my assertion that the 1:1 correspondence,
>even though partial, is a very useful model for the purposes of dynamic web
>pages (e.g. applications).  Without 1:1 correspondence, then I do not know
>what kind of model one would get to try to related two disparate abstract
>state models.  I will now show why this 1:1 correspondence is CRUCIAL to
>MOST web authoring.
>  
>
That might or might not be true, depending upon how you define the 
"transformed states".

In architectures I have built in the past, cascading styles is a middle 
layer that exists clearly between content and presentation.

Components could be dropped arbitrarily into the back end as black boxes 
which attach to input style information.  Such components do not 
transform styles.  They merely use them as input arguments which may or 
may not influence the presentation.  If the box has to use a variety of 
fonts to accomplish the rendering, the concept of "actual font" is 
extremely misleading.  If you are going to constrain it to a single 
actual font to accomplish it's job, it is unreasonable.  To ask a 
question about fonts, you need to be able to ask about segments for 
which a particular font can actually be said to be the font of that segment.

Forcing the parts of the presentation to speak style language as output, 
where it is not likely to correspond to it's internal structure is 
problematic.

>Let's consider the analogy in mathematics.  If we have a given state, given
>by a matrix of values, and we transform it to a new state, then our
>transform matrix controls several important mathematical properties, such
>as whether there is an inverse, whether the transform is linear,
>associative, communitive, etc..
>  
>
Text formatting is not at all matrix-like, nor does it necessarily 
represent it's values in terms of CSS or place the results into nice 
1:1-corresponding boxes.

The more useful mathematical thing to compare it to would be a fractal, 
where you find the closer you get to the real presentation, the less 
well-behaved it seems and the less it's properties seem have a 1:1 
correspondence with input.

CSS defines some starting hints for the presentation, nothing more.

>Your assertion is that the transform from DOM markup state to (for example)
>presentation state, is a sufficiently complex transform that the
>correlation between the elements of the two states can not (or should not)
>be correlated at the element level.  However, my assertion is that HTML and
>CSS has (and must) sufficiently consider the possible ways of presentation,
>such that the correlation is predictable enough for 1:1 correlation.  For
>example, this week when I suggested sentence style, the CSS list replied
>that the presentation algorithm for sentences must be known before we can
>consider the new feature.  Because if the correlation between markup state
>and presentation state were not predictable, then authoring web pages would
>be a "blind" activity.  By "blind", I mean the author would have no
>predictable notion of how his page is being presented.  I can assure you
>the market will never accept an abstraction of XHTML to the level that
>presentation is unpredictable.
>  
>
This is how HTML was designed, and is still of key importance. 
 Well-written HTML adapts quickly to a variety of very different 
situations.  CSS has been used to separate presentation attributes out 
of the content and markup because of the high likelihood that it should 
be ignored or applied in very different ways.

The presentation today of HTML and XHTML is unpredictable, as it should 
be.  It is indeed a blind activity often done for the Blind and by the 
Blind.  If you want complete control over the presentation, use SVG, 
PDF, etc.

If you want both control and ubiquity, get used to disappointment.  HTML 
is, IMO, popular, because it adapts.  I dislike many of the 
characteristics of PDF, and reject it unless it is absolutely necessary 
because it decides that the control over presentation is more important 
than many important issues such as, the ability to search, the ability 
to read it as a continuous text, adapting to the size of the window and 
user selections of fonts, adapting to the needs of people with 
disabilities, etc.

Pages which focus on a specific presentation, typically fail to work 
well, and I avoid them.

>>The more specific the DOM APIs for dealing only with a specific markup 
>>language, the less problem there is defining where 1:1 correspondences 
>>are likely to always exist.  The HTML DOM is almost always used to 
>>present in a legacy-browser-type fashion, and hence in the HTML DOM, we 
>>know much more about the likely presentation than in the core or XML DOM 
>>modules.
>>    
>>
>
>I figured your response would be that this is a legacy issue that W3C wants
>to purge in future.
>  
>
I do not understand what lead you to that conclusion.  That is clearly 
not what I said, and I don't think it is what "W3C wants" if it were 
possible for W3C to have such a single voice.  W3C would have just done 
a big disservice by releasing the DOM HTML 2 if that were the case.

DOM HTML works reasonably in legacy HTML browsers -- new and old.  Where 
it starts to break down, it will be obvious that something else is required.

>However, has the W3C considered what the replacement model would be for
>HTML forms programming??
>  
>
They have certainly already considered what the forward-looking model 
is.  It is called XForms.  It does a much better job of separating XML 
content from presentation.  I had nothing whatsoever to do with it's 
development, but I can only commend the Web Applications experts who 
understood the advantages of separating content from presentation.

>I think you are going to ultimately come to the conclusion that 1:1
>correspondence is necessary to make a reasonable programming model for the
>presentation.  Otherwise, if you completely abstract the presentation, then
>how does the program know which element is the last name of the form??
>  
>
I do not understand the question.  You are going to have to describe 
more carefully the use case here that you think is a problem with 
content which has been insulated from presentation.

[...]

>However, if you completely abstract the presentation from the markup, then
>there is no reasonable way to correlate the two for the purposes of
>programming the behavior.  In the end, a button in markup has to be a
>button in presentation.  There has to be a 1:1 correspondence.  It is so
>obvious to me.  What I am missing that is causing you to resist my
>assertion that 1:1 is not optional??
>  
>
It is done every day in model-view-controller architectures.  The 
program controls the model, the controller controls how the model is 
mapped to the presentation, and the presentation takes these things as 
input, but is not directly manipulated by the application.

Roughly speaking:

DOM is the model.
CSS is the controller.
Proprietary presentation is the view.

>>>Again I do not think specialized interfaces for modifying the transformed
>>>state are to be encouraged.  Where ever possible it is logically very
>>>important that one try to use markup to set state.
>>>      
>>>
>>Again, please define "the transformed state".  I don't believe it has 
>>ever been defined before, so it is hard to determine which layer you are 
>>targeting and whether it is standard enough to be exposed.
>>    
>>
>The author (for writing chances to a) a web document should only be
>targeting one layer and that is markup.  If you expose a transformed
>DERIVED state for writing, then you will have subverted markup and created
>a new markup language by default.
>  
>
We have repeatedly referred to many things that the application should 
be targeting which are clearly not markup not markup, such as focus, 
selection, current form values, and so on.  The few presentation methods 
that have been added to DOM HTML are also clearly not markup.  If we 
don't need them, we can eliminate these features in DOM HTML.  Abstract 
markup generally has nothing to say about this.


>This is also why you have no choice but to develop 1:1 correspondence
>interfaces for reading the transformed state.  My point is that CSS is
>working very hard on this, so leverage their work.
>  
>
Whatever CSS is doing, can be done entirely by the CSS group.  That is 
why they were given responsibility over that specification.

>It is ironic, because I sense (perhaps incorrectly) that you feel I am
>against the abstractness of markup, when in fact, I am trying to protect it
>from being compromised by transformed state (write) interfaces.
>  
>
I am sorry, where did you find me, either in concrete specification or 
otherwise, advocating transformed state write interfaces?

>In fact, now we come full circle to my original post, wherein I said I do
>not want to use a propreitary api such as the new stuff for building
>applications with Mozilla.  The problem with their approach is they are
>(akaik) exporting new interfaces for writing on the presentation.  That is
>very bad for W3C standards.
>  
>
You would have to cite specifics for me to have any opinion about your 
statement.  What I have seen of XUL, XBL, and so on does a very good job 
of managing the application at the content layer.

>>If it includes focus state, blur, current form field values, etc. then I 
>>disagree.
>>    
>>
>
>Then you will destroy the abstractness of markup.  You will then have
>authoring combining markup with other write apis to form a new vegetable
>soup of markup which is extremely brittle.
>  
>
Either you are now opposing the very HTML methods you seemed to be 
favoring at the beginning of your message, or I am just too confused 
about what you are saying at all.

>We need to keep markup pure and we need to insure that the things people
>want to do with web pages, can be done from the pureness of markup.  All
>writing of the state should come from markup.  The limits of markup
>determine the limits of state that can be written.  Of course we can expose
>non-1:1 transformed state for reading without any worries, but we should
>prioritize exposing the 1:1 properties first.
>  
>
Exposing them as markup?  You would reincorporate CSS into markup?  And 
then presentation state?  DOM has no say about what is in markup and 
what is not (that is up to the HTML WG) but fortunately, I doubt they 
agree with you that all of these things should be part of markup.

Each thing belongs in the appropriate layer.  To merge all the layers 
does not make markup pure at all.

>>If it is the actual computed style values, as obtained via the CSS 
>>module, then I agree, which is why you are permitted through that module 
>>to modify, not the end result, but the upstream result, if memory serves me.
>>    
>>
>
>Correct.  You have reaffirmed that one must write thru markup, not at
>transformed state.
>  
>
Not at all.  These current form values, for example, are nowhere 
represented in the markup.  To the best of my knowledge, they only exist 
in the widget of the presentation.  The markup content of a form field 
does not, to the best of my knowledge, ever change as a result of the 
user typing in a form.

If you want to get or modify them, you do it by poking around in the 
presentation, not in the markup.  DOM HTML has convenience methods that 
do this.  That does not make it part of markup in any sense of the word.

>I think we want the same goals for pureness of markup.  I am very curious
>as to what, if any, disagreement we still have.  I am very willing to be
>swayed by compelling technical points.  So far, I think my case for the
>necessity of 1:1 is very strong.
>
The very fact of introducing Javascript into markup makes it quite 
impure, and the more you introduce extended capabilities of programming 
the in-memory markup/content or the presentation that is derived from 
it, the less pure it gets (the less reusable, the less accessible, the 
less flexible, the less general).

A pure markup is only declarative.  XBL + XUL, in my limited experience, 
allow you to hide programming in a black box and keep your page as 
declarative as possible in terms of new properties on new widgets.

At some level, you have to always get your hands dirty with actual 
programming.  But abstract toolkits try to keep the high layers more 
declarative and pluggable than down-and-dirty procedural.  This is the 
same goal of pure markup, like HTML before all the programming was 
introduced:  to make it possible to reuse the content and markup in the 
widest-possible set of circumstances.

Ray Whitmer
rayw@netscape.com

Received on Thursday, 19 December 2002 14:26:21 UTC