Re: Exposing the critical ACTUAL style values?

Shelby Moore wrote:

>Tangentially, in Bert Bos's article about correct way to make standards, he
>emphasized that non-redundancy is important.  I think someone should be
>looking more generally at the concept of separating the presentation state
>layer (style actual values, events, etc) from the topmost layer of markup.
>It is not desireable to have a separate overlapping model in XForms and
>another model for events in general.
>  
>
Styles and events as they are defined in the model today, are quite a 
distance away from the presentation.  This is good for abstraction, but 
bad for actual information, and the closer you want to get to the 
presentation "actual style values", the less it works.

>Now three critical points I think we can agree on?
>
>1. FACT: the more abstract something is, the less useful it is in the real
>world.  All abstraction has to be comprised to achieve implementation.
>Thus NOTHING is purely abstract.  It is all relative.  So the useful
>questions are not ABSOLUTE.  They are based upon PRIORITIES.  These
>priorities should be controlled by the demand for applications (uses) of
>the technology.  Eistein proved this.
>  
>
I disagree.  the more abstract it is, the more reusable it is.

All abtract meaning has to be mapped to concrete meaning.  If you were 
meaning "compromised", I disagree.  The layers can be sufficiently 
isolated that a particular concrete mapping does not compromise the 
abstraction.  This is the point of CSS.  The browser can ignore it and 
use XSL or an aural presentation that you may not have provided CSS 
values for instead.

This is a little bit like taking abstract mathematics that can describe 
a wide variety of things and applying it and binding it into a concrete 
situation.

>2. The lesser abstract layers of input to presentation (such as CSS,
>Events, Selection, etc) are absolutely required by the general market today
>in many (if not most) cases.  There is simply no way to make the kind of
>applications that the world demands today, without actually specifying some
>specifics beyond the most abstract.  I agree with efforts to abstract the
>objects (XHTML) from the more presentation specific layers (such as CSS,
>Events, Selection, etc).
>  
>
I agree that they are good to have as long as they are done as standards 
with reasonable expectation of availability.  I have argued strongly 
against efforts to eliminate them.  I do believe that they exist for 
special cases, and the more that special cases can become abstract 
representations with specific implementations, the better off everyone 
is and the less you need the less-abstract layers.  It is good to have, 
for example, an event system representing semantic events so that the 
application can layer the semantics away from the concrete hard-wiring 
to events of a specific type of device.  We do not have that today.  I 
still would not eliminate the device-specific events, but give a better 
alternative.

>3. FACT: all these layers as a union set, become a standard for "markup" as
>a union set.  A user agent would not be required to implement all layers,
>but then again such a user agent might not be popular either.  The modular
>layers enable specialized user agents,  but they don't exclude popular user
>agents that implement the union set.
>
I take strong issue with your use of the word markup.  Markup is the 
content and structure supplied in the markup language.  It is far less 
than the browser, the Document Object Model, etc.  It is typically the 
most-abstract part.  It mostly excludes CSS, Javascript, etc.  It is 
exactly what it says.  Markup.  The structuring of content using tags. 
 It typically has little to do with programming, although the tags may 
contain programming or references to functions, but this is quite an 
impure approach and is not markup.

>  The popular applications that world
>demands require that the author have some control over presentation, and
>not be abstractly "blind".  While it is desireable to have a more pure
>abstract layer (XHTML DOM) which can be considered separately from the
>lower lesser abstract layers (such as CSS, Events, Selection, etc), this
>should deny of the FACT that the lower layers will be very popular, due to
>the demand for applications that do more than just specify an abstract
>model.  Because as you agree, the bottom line is that someone has to get
>"hands dirty" and "actually program" behaviors.
>  
>
Yes.  But the more it can be done without explicit links between markup, 
presentation, and program, the more reusable the content and the 
programs are.  This is a core principle of markup languages.

>And when authoring middle layers, the author will thus design with a lower
>(more specific) level of abstraction.  Thus the author will be less
>"blind".  Thus one needs to be very careful about what layers they
>standardize, so the higher layers of abstraction are not undermined by
>brittle (too specific) lower layers or merely by popular demand of lower
>layers.
>  
>
Most very competent authors will never touch the lower levels of 
abstraction in any way.  I have written a number of competent Web 
applications which do no special event processing and contain no 
Javascript.  It is a different sort of application which needs to step 
outside of those bounds.

A good author who does need access to the middle layers will use the 
middle layer to build new abstractions which can be understood at a 
higher level for device independence and also can be reused much more 
easily than if it were hard-wired to the document.  XBL in Mozilla, for 
example, allows the author to design new types of markup for doing 
different tasks without compromising the abstract level of the document, 
even though it introduces new abstractions that are not part of the 
standard set.

These first two things are still compromised by natural limits in every 
architecture and standard, but it should still be a priority to add 
abstractions where appropriate.  When an author has reached the limits 
of the abstraction, then he may directly incorporate lower layer 
information into the document, which is generally not really declarative 
markup, but rather programming.

CSS is a good layer to standardize because it keeps you away from the 
actual presentation and it's properties (until, that is, you start to 
talk about the actual values computed by the presentation).

>Back to original question of this thread, so how do we best expose the
>kinds of presentation layer state that HTML started and that the world demands?
>
>Once again if you look at XForms, XHTML style sheets, etc.. you see there
>is always a 1:1 correspondence (by reference attachment) of the
>presentation style and programming to the XHTML abstract objects.
>  
>
XForms has a section which describes the UI in very abstract terms, not 
that you will even typically know what sort of widget will be presented 
to the user to obtain the desired input, let alone what the presentation 
of it will look like.  You can override this, but the point was not to 
override it unless there is a reason to make your application more 
fragile and dependent on assumptions and less able to be reused, on a 
cell phone display, for example.

XForms has completely seperated the content out of the abstract UI part 
I just described, even though the UI part is much more abstract than 
other widget markup, characterizing only the type of input, not the type 
of presentation.

I agree that there is a 1:1 correspondance of style inputs with the 
XHTML abstract objects.  That is nothing but hints to the presentation, 
which may use multiple widgets, break up and present in a wide variety 
of ways.  So CSS works well as input to the presentation, but not so 
well as output from the presentation (actual values).

>My proposal from very beginning was to leverage the expertise of these
>other standards (XForms, CSS (or XSL), etc).  Thus when reading current
>state from presentation layer, we should attempt to standardize on
>properties which have a strong correlation to these existing input
>standards.  Of course there are some questions that can't be answered
>because there is no strong correlation, and these are also the less useful
>questions from the stand point of designing applications using the union
>set of "markup".  Do not implement those unimportant questions, or wait and
>implement them later at a lower layer.  As you point out, if someone wants
>to create applications where they can be more specific than the union set
>of "markup", then they shouldn't be using this union set.
>  
>
I already explained that the correspondance of the CSS to the abstract 
input of the presentation is real, but on output, it is not.  There is 
no "union set of markup" to the best of my knowledge.  XML is a markup 
language.  CSS is not.  Javascript is not.

If you want to ask for them back as CSS and just ignore the cases that 
can crop up for any style property that it may not be reasonable to get 
it as output from the presentation, then it would be more reasonable to 
do this as part of the CSS module, not the DOM module.

I would also not designate such a module "Views and Formatting" because 
it does not have the proper associations to be a general mechanism.  It 
is a mechanism that may work sometimes, but any browser would have to 
feel free to not support it due to the proprietary nature of the model 
of the presentation.

It is also unclear which of the CSS properties are so semantic in nature 
that it is unreasonable for the presentation to be answering questions 
about them.  I am not so familiar with the actual CSS properties to 
speak authoratatively on the rest of this thought, but there might well 
be half a dozen input CSS attributes that affect the choice of an actual 
font for any given segment.  The presentation, from those, at best, only 
computes the font segment by segment, and then only for a specific style 
of browser.

>You see my keen observation is that most applications can be programmed
>using the existing union set (with improvements).  It would be much better
>for the world if applications where at least abstracted to the level of the
>current union set, than rewritten from scratch (brittle) as they are now.
>  
>

>Again please refer to my crucial point #1 above.
>
>The problem I had with the existing Segment model of the proposed dormant
>DOM Views and Formatting is that it has no correlation to the existing
>union set.  You were proposing a new lower layer when we must first
>prioritize exposing the correlating layer to the existing union set.
>  
>
That is because you are asking for outputs from a proprietary 
presentation model.  Picking up CSS values as inputs makes sense, but 
picking them up as outputs often, and perhaps usually, is not reasonable.

>We should go thru the properities of CSS, XEvents, etc one-by-one and
>decide which ones can be reasonably answered by the presentation layer.
>
For whose implementation?  Different implementations will have differing 
abilities to answer these.

>What good does it do to ask where the characters or line segments are, if
>we don't know what objects of the DOM (elements) those correspond to??
>  
>
You certainly missed something in the model.  We clearly know which DOM 
elements they correspond to.  If it starts at a character offset within 
a text node, we also know the offset where the change occurred that made 
this segment's properties different from those of the previous segment, 
either in position, because it wrapped, or in font, due to some 
presentation issue, etc.

>From the authoring perspective (which is the target of Views and
>Formatting), the correlation to the union set of markup is what would make
>the new standard useful.  I think this is why there was no support for the
>original Views and Formatting standard.  It served no popular purpose as
>modeled.
>  
>
There is a clear correlation to the markup.  It may not be 1:1.  Some 
markup may not be presented at all, while other markup may be presented 
multiple times or be broken into different coherent segments.

>The implemetation difficulty of user agents should not come at the cost of
>making a model that is useless to the author.  I agree that some styles may
>be difficult to relate to their actual presented state, in which case,
>these are "one way" (input only) styles and are not useful to ask questions
>about (they are write only).
>  
>
That is why I object to your supposed simplification, which is no 
simplification if it cannot answer the questions posed from the 
proprietary presentation at hand.

>I have 2 main design distinctions from proposed Segment model:
>
>1. That one be able to ask questions about objects of the DOM.  Else the
>model isn't useful.
>  
>
I find much wrong with this statement.  DOM is whatever modules happen 
to be supported by a browser.  The existing proposal clearly permits the 
questions to be asked using DOM.

I think this will NEVER be a part of the core DOM, any more than the 
HTML DOM is, because there are many DOM uses that have no presentation 
and should not be burdened with the standard.  From what you have said, 
it sounds to me like what you want is some extension to the optional CSS 
model for asking simplistic questions about the presentation that may or 
may not be answerable by the particular implementation.

This will be easily available to the user.  It will also do little to 
expose the presentation.

>2. One be able to ask the questions that have answers about actual
>presented style.  Else the model isn't useful for controlling style.
>  
>
As long as you don't demand answers where the questions have no 
reasonable answers.

I do not understand what you are asking "for controlling style".   I 
have heard of no request for controlling these features.

>3. Etc.  In every case, there must be a correspondence between the
>questions with answers, and the layer used as input to the presentation
>state.  I think we standardize on existing input standards BEFORE creating
>new lower level ones.
>  
>
As long as you don't demand that the correspondance be predictable, it 
sounds OK.  You cannot demand answers from a presentation in which the 
questions have no reasonable single answer.

>I am not proposing to expose the lowest level details of text formatting.
>One should use PDF or another mechanism is they need that.  I am simply
>proposing to be able to ask questions such as, "where is this markup
>character on screen?" or "where is the selected character in markup?" or
>even perhaps "what font size was actually used?".
>  
>
That is something you cannot possibly ask in terms of DOM nodes.  You 
must find the segment below the DOM node that corresponds to the 
character.  That is also where you are likely to find a better answer to 
the question "what font is being used" than trying to ask it of an 
entire node.

This is not a reasonable question to ask in terms of CSS properties.  It 
is exactly the low-level details of text formatting, where each 
character got placed.  There is no 1:1 correspondance between characters 
and DOM nodes.

>>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.
>>    
>>
>
>
>That was my point.  The analogy shows which properties are well behaved
>enough to model in the presentation layer.
>  
>
This specific text example shows the opposite.

>>This is how HTML was designed,
>>    
>>
>
>I think you mean "should have been designed" :)  Sure you agree XHTML is
>attempt to fix/improve abstraction.
>  
>
Just because it has had lots of things introduced into it that may be 
used to hurt the abstraction, does not mean it was not designed to do 
this.  XHTML banishes a few things, but anyone determined enough can use 
it wrong and desstroy the abstractions, much as the user of a word 
processor might destroy the paragraph abstraction by inserting hard 
returns every time his cursor reaches the left margin.

>>and is still of key importance. 
>>Well-written HTML adapts quickly to a variety of very different 
>>situations.
>>    
>>
>
>
>And doesn't solve but a very small fraction of the applications demand by
>the web.  That is why we are having this discussion.  So as to standardize
>the demanded apis before proprietary ones undermine.
>  
>
I woulod say it solves 80 percent of what is needed on the web.  That is 
not a small fraction.  That still does not minimize the need for a 
solution to the advanced requirements, but the best solution will always 
be advancing the abstraction, rather than compromising it.

>> 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.
>>    
>>
>
>This is not the way CSS is being used,  because this is not what is being
>demanded.  You aren't operating in an academic vacuum.  You have to make
>standards that actually are what the millions of people in the world need
>to use.
>
>CSS is swappable (modular) and that is being honored because it is built
>into the specification.  But also realize that people are relying on the
>functionality not being ignored in many (if not most) cases.  Not just the
>author, but the reader wants it that way.
>  
>
Says the author, but not this reader.  Usually specific CSS hurts more 
than it helps, in my experience.  Just like some web authors feel that 
everything has to be in nested frames and lots of other things that make 
things worse for the user.  The author has no idea the resolution of the 
screen I will be using, and the more assumptions he makes about these 
things, the less likely I will bother with his content.

>I agree with designing for maximum modularity and will continue to advance
>that cause.  But realize your standards will also be used to fit the
>demands of the market place if they can, else they will not be used.
>  
>
They already fit a large part of that market place.  We clearly need to 
provide extended capabilities for the percentage of the cases that go 
beyond.

>>The presentation today of HTML and XHTML is unpredictable, as it should 
>>be.
>>    
>>
>
>That is not entirely true for HTML.  Many (if not most) every author of a
>web page, looks at the presentation output to finalize the design.
>  
>
I have worked with large very experienced teams of web authors doing 
very significant applications that extensively used Javascript and 
widgets to produce very native-looking applications.  No advanced Web 
author looks at a presentation in a browser and thinks that this is "the 
presentation".  Rather, he looks at it in several browsers, with 
different screen resolutions, window sizes, and font selections, and 
makes sure it looks reasonable in a wide variety of cases.  It is 
difficult to go beyond the simple abstractions and still have it look 
good in those cases, but there are rules that are learned.

>Yes I am also BLIND in one eye.
>  
>
So, do you make sure your web pages work well for users of screen 
readers?  Major corporations cannot afford to do otherwise.

>> If you want complete control over the presentation, use SVG, 
>>PDF, etc.
>>    
>>
>
>BUT I DO NOT WANT COMPLETE CONTROL.  That is the whole point.  I only want
>corresponding control to W3C standards.
>
>I only want control over W3C standards (CSS, XHTML, XEvents,...)
>
>Right now, there is no W3C standard way for me to program these with
>behaviors.  That is the whole point of this thread.
>  
>
I think there is already complete control over these things 
programmatically.  Views and formatting goes beyond that to allow you to 
ask for the details of how the content was presented in the presentation.

[...somewhere here I cut a bunch out that was not advancing the dialog]

>CSS does not consider the View.
>  
>
Exactly.  It is not appropriate for that.

>>I am sorry, where did you find me, either in concrete specification or 
>>otherwise, advocating transformed state write interfaces?
>>    
>>
>
>
>It is implicit in the Segment model, else the model is useless.  Remember
>our whole disagreement has been about whether markup and Segments can be
>strongly correlated.
>  
>
Your statements here seem very wrong to me.

Nowhere in the segment model was the power given to modify the segments.

And I never said there was not a strong correlation between the segment 
model.  Otherwise, the segment model would be worthless.  There is no 
1:1 model, but there is a strong correlation that the proprietary 
presentation model will know how to traverse to accomplish requested 
match operations.

>>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.
>>    
>>
>
>
>They replace (undermine) existing W3C standards which could accomplish same
>thing if we finish the Views and Formatting spec.
>  
>
I disagree entirely.  They permit a higher level of abstraction, which 
is better where it can be successfully applied than the lower level of 
Views and Formatting, for all the reasons we have discussed repeatedly here.

Even where Views and Formatting can be applied, it's use can be better 
abstracted by employing XBL, etc.  That of course assumes that these 
were standards.  Where they have not been adopted by W3C, their greatest 
value is limited to emulating things that are standards, such as XForms 
UI (where I anticipate it will be useful).

>I am advocating a standard layer for these things that can be used from
>markup, just as HTML programming does.  If you do not do this, then XUL and
>other propriietary standards will undermine other W3C layers.
>  
>
That is also what the Views and Formatting module would have standardized.

>If you instead define this layer at the Segment level with no correlation
>to object model, then you will REALLY undermine the object model.
>  
>
There is clearly correlation, and in some cases segments might not come 
into play at all where there was no need to address specific parts of 
the display -- for example getting raw display input events...

The intent is that you can map either direction, to get the elements 
being presented by a segment or the segments used to present an element.

>I mean the union set of all the input layers to presentation.  I call this
>"markup".  Do you have a single word name for it??
>  
>
I would be explicit and call it markup, scripting, and styles.

[...]

>Sometimes such as selection state of a <SELECT>.  But in cases, such as
>style, the values may not be updated.  We need to be able to read the
>values in some form which is strongly correlated.
>  
>
I have never disagreed with this.  That is why segments were defined as 
they were, the only way to strongly correlate a proprietary presentation 
with the markup it is presenting.

>Could you please define markup??
>  
>
Markup is typically the content and structure of the markup language.

I seldom include CSS or Javascript in markup, because it can be easily 
seperated, is best seperated, does not rely on markup syntax, and 
belongs to different layers than the content model.

>Because I think "abstract" is always relative.
>  
>
Clearly that is true, just as one man's model is another man's view.

[...]

>> 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.
>>    
>>
>
>
>I need to look at it more before I can comment.  I will just say my initial
>impression is a very narrow solution which I think is better solved generally.
>  
>
It is certainly a specific solution, but one that can be used generally 
and much more abstractly than embedding specific calls to views and 
formatting.  It is good, but it does not answser the questions that we 
need Views and Formatting to answer.

>>But abstract toolkits try to keep the high layers more 
>>declarative and pluggable than down-and-dirty procedural.
>>    
>>
>
>
>And they fail because they aren't general and thus one resorts to actual
>programming.  Better to build a set of general building blocks, than to try
>to hide and end up with BRITTLE mixed breed.  I have 19 years experience
>with huge commercial programs.
>  
>
They succeed because they are general and abstract.  They fail because 
any system is incomplete.  If they did not address most of the common 
use cases, they would be a failure, which they are clearly not.

I think many of us have many years of experience with huge commercial 
programs.  I have also produced large, large, widely adopted, commercial 
client and server products at a number of well-known company which 
pioneered their fields.  Significantly more than 19 years at it and lots 
of extensive, successful architectures.

>> 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.
>>    
>>
>
>That is not mutually exclusive with what I am proposing.  The layers are
>still there for people who don't want to make their applications hinge on a
>layer.
>
>But if you don't provide the layers, then someone else will.
>  
>
I agree with this.  That is why I advanced the specification.  You 
perhaps envision a slightly different layer, but it may not be so 
different from what was proposed as you may think, once you have solved 
more of the problems generally, as would be required for a general 
mechanism, not that I thought that the draft was anywhere near 
completion, but I have yet to see a concrete proposal that looks 
convincingly better or simpler at solving the problems.  You have not 
told me how to get all of these characteristics of a presented character 
from the node.  Getting a segment of the presented character seems 
reasonable, and even giving it a more-concrete class than segment 
(avoiding all the strings) is fine.  But a DOM Node does not correspond 
to a character.

Simpler is great, but the existing draft can also be studied and made as 
simple as is useful.  There would be much adaptation as such a 
specification were further developed.  I do not know if I am still in a 
position to advance such a standard at all, I must say.  Many web 
applications work just fine without this sort of access to the view. 
 But I will discuss it's merits.

Ray Whitmer
rayw@netscape.com

Received on Friday, 20 December 2002 19:10:49 UTC