- From: Shelby Moore <shelby@coolpage.com>
- Date: Fri, 20 Dec 2002 13:03:02 -0600
- To: Ray Whitme <rayw@netscape.com>
- Cc: www-dom@w3.org
I have few minutes from hotel dialup... Before I address your specific points below, I'd like to attempt to go straight to a solution. I agree with having layers of markup where the topmost layer is the most abstract. See example where I advised separating my proposed XEvents style sheets from the XHTML markup in response to someone who wanted to combine them: http://lists.w3.org/Archives/Public/www-html/2002Dec/0097.html It appears my proposal for XEvents style sheets: http://hades.mn.aptest.com/cgi-bin/voyager-issues?selectid=6204 Is a generalization of the way Interaction Events in XForms are separated from the topmost layer of abstract markup: http://www.w3.org/TR/2002/CR-xforms-20021112/slice4.html#rpm-interaction 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. 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. 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). 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. 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. 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. 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. 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. 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. 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. 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?? 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. >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. 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). 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. 2. One be able to ask the questions that have answers about actual presented style. Else the model isn't useful for controlling style. 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. >>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. 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?". >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 is how HTML was designed, I think you mean "should have been designed" :) Sure you agree XHTML is attempt to fix/improve abstraction. > 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. > 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. 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. >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. > It is indeed a blind activity Sorry but that is not reality. > often done for the Blind Yes I am also BLIND in one eye. > and by the >Blind. Yes I am also BLIND in one eye. > 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. > >If you want both control and ubiquity, get used to disappointment. Depends definition of "control". I want "control" as defined above > HTML >is, IMO, popular, because it adapts. Partially agreed. I will not digress but the rest would be irrelevant to this discussion. > 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. AGREED 100000%!!!! >Pages which focus on a specific presentation, typically fail to work >well, and I avoid them. AGREED 100000%!!!! >>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. I meant purge from future standards direction such as XHTML, etc.. I understand you will continue to maintain legacy standards. >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. That is what I meant also. >>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. And there STILL IS a strong correspondence between presentation layer state (events) and the abstract Object model. I think it is impossible to escape that correspondence and do any programming of interaction. I agree with the modularization of layers, per my comments at top of this email. >>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. Let's discuss this on the phone. This is too complex to address in email. I am 100% confident that I can convince you. I now understand your issues well enough to know how to convince you. I just can't do it in email. >>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. You did not address my point in terms of use cases. We should discuss this on phone. >>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. DOM HTML defines all these things in markup because they are necessary. It is okay to modularize them from the object model layer, but they must exist at some layer. >>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. CSS does not consider the View. >>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? 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. >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. >>>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. 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. If you instead define this layer at the Segment level with no correlation to object model, then you will REALLY undermine the object model. It is really difficult to explain myself in this linear format of email. My mind is operating in a very parallel way considering trying to consider all aspects including adoption rates, etc. You can't design in a vacuum. >>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? 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?? > And >then presentation state? Some presentation state has to exposed in some input layer. The only question is who is going to set the standard. > 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. Of course separated from XHTML object markup, but correlated by reference. > >Each thing belongs in the appropriate layer. To merge all the layers >does not make markup pure at all. AGREED 10000%!!!! >>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. You can set the selection state for example from DOM HTML. > To the best of my knowledge, they only exist >in the widget of the presentation. Which is exposed in DOM HTML and DOM CSS-OM. > 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. 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. > >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. One man's "convenience methods" is another man's model. That was precisely my point in using virtual methods. And also my point about being careful about we expose. And part of my justification for correspondence properties... etc... on phone we can discuss... > That does not make it part of markup in any sense of the word. Could you please define markup?? Because I think "abstract" is always relative. >The very fact of introducing Javascript into markup makes it quite >impure, If you mean that HTML is not modularized (can not be removed from) scripting, then I AGREE 100000%!!!! That is another of my goals here... > 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). Agreed. > >A pure markup is only declarative. Declares some properties of presentation?? Pureness is relative. Is 1 part per million pure? Not if it can kill you :) > 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. >At some level, you have to always get your hands dirty with actual >programming. YES!!!!!!!!!! > 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. > 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. -Shelby Moore
Received on Friday, 20 December 2002 14:03:47 UTC