- From: Shelby Moore <shelby@coolpage.com>
- Date: Sat, 21 Dec 2002 00:57:23 -0600
- To: Ray Whitmer <rayw@netscape.com>
- Cc: www-dom@w3.org
Ray, Thanks for phone conversation tonight. In 20 minutes, we were able to clear up what would have taken us many hours in email. Here is the conclusion I have at the end of this email: "I think our first task is to improve the existing WD to include more examples, and to make some suggested convenience methods to show the correlations that might be possible. I'd be willing to do this work, if you approve." Let me clarify a few of your points based on our new understanding below, for our benefit and any one who might read this thread. >>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. [...] >I disagree. the more abstract it is, the more reusable it is. >All abstract meaning has to be mapped to concrete meaning. We both agree about benefits of good abstract design. I was merely relating that specificity has to match the specifics required by the application (use). We agree to use appropriate layers to maintain the principles of modular design, etc. http://dictionary.reference.com/search?q=abstract "Considered apart from concrete existence: an abstract concept" > The layers can be sufficiently >isolated that a particular concrete mapping does not compromise the >abstraction. Agreed. We also agree different layers have different levels of specificity and thus difference levels of abstraction. That was my only point. > 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. Agreed CSS is swappable. CSS is more abstract than presentation but less abstract than DOM. Which you also agree per your previous emails. [...] >>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. I am also in favor of abstraction layers. I understand you favor a goal where everything will be ultimately (as much as possible) be expressed semantically (by meaning). I also agree with the goal to the extent that I am not relying on another non-portable, proprietary abstraction layer. A problem with semantic abstraction is that you can NEVER predict every application. So if you start with the goal of ONLY allowing semantic abstraction, then you are doomed from the start to be underminded by a vast majority of applications that use some form of proprietary method to get around the semantic limitations. The world is simply too complex to build semantic abstractions for everything. However, I think we also agreed on the phone that exposing basic building blocks (such as Views and Formatting model) to enable people to author (program) infinite variations is applicable. Especially if people build new abstraction standards on top of these standards, rather write abstractions in proprietary ways. Of course it is possible to use bad authoring techniques with any layer, but hopefully authors will build on top of the abstraction layer appropriate for their application. We must assume they will, because authoring at highest level of abstraction is usually much more efficient. > 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 both I think agree that layers are a way of exposing different degrees of abstraction in modular way. I am in favor of that, because it is the best way to isolate the dependencies, so that author uses the maximum level of abstraction that befits the requirements of the application. > We do not have that today. I >still would not eliminate the device-specific events, but give a better >alternative. So instead of onmouseover(), you would want what? I am unclear as to specific examples of how much more abstract you can make event semantics? But in any case, I am in favor of an abstraction layer for events, as long as we can still get down to specifics, if we need to. >>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. I agree with the goal of removing the scripting and style from the static content markup. I think I used "markup" because there is apparently no other term to represent the suite (union) of standards at W3C for authoring a web page. Isn't CSS also a markup language for style? I think it would be better if "markup" applied generally to mean any declarative language. And use "content markup" to represent the XHTML abstract object model. Obviously scripting is not markup, because it is not only declarative. AFAIR, I never mentioned scripting in my use of the word "markup" in the context above. >> 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. I never disagreed with the modularization of layers. You may have misinterpreted my desire to use a virtual method to get interfaces for other layers on the DOM. This does not mean that the DOM model has been combined with the other layer. It is just a convenient OO way of getting at layers, from the perspective of the DOM model. When you want a new layer, you call getInterface() to get that layer. It is equivalent to have a separate call method you call and input the DOM node as a parameter. I assume you noticed that mapping other layers on to the DOM is not as general since the other layer may not have a 1:1 correspondence with DOM Nodes. However, I nevertheless see it as an intuitive way to deal with a large class of applications. This would not be mutually exclusive to exposing other mappings by having a more general interface to a layer. Any way, I am not particularly in love with my suggestion on using getInterface(). I just though it would allow for some consistency and readable code structure in many scenarios. I felt one could divert to general way only when needed. This is just two ways to call the same method in cases where one is questioning the other layer about a DOM Node (even if the answer may be compound or null set). >>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. There are a lot competent authors who use CSS. In fact, W3C CSS group uses CSS on it own web pages. I agreed with most of what you said on the phone, but we did not touch this issue on phone. I must disagree with you on this point. > 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. I have also written a clever, very complex CSS based TreeMenu which uses only a few simple lines of Javascript. It leverages CSS and hierarchy abstraction instead of scripting: http://coolpagehelp.com (in left frame) However, there are many (most) classes of applications that need custom programming. If that were not true, then VisualBasic would not be the world's #1 programming language. I am *NOT* touting benefits of VisualBasic. I am just stating that the purest abstract view does not appear to be in touch with the reality of the complexity of the world. Something like XUL with standards and built on top of standards (more on that later) will go a long way, but I think what I said above about semantic limitations will always apply for some applications. >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. We agree on building abstraction layers. We agree that Views and Formatting is necessary and that hopefully good authors will build abstraction layers on top of it. By exposing the presentation to a larger group (everyone) and by making it a standard, we can expect semantic abstractions to advance at a more rapid pace and to be more transportable (all dependencies in the View and Formatting layer instead of proprietary C++ hardcoded in UA). > 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, Yes but my point is that with the proper W3C standard api for View, then we could build these abstraction layers on top of that and use W3C standard markup. I will go into more detail on this, after I have studied XUL and XBL in detail. >even though it introduces new abstractions that are not part of the >standard set. Yes we agree that is the problem with XUL and XBL. And until I review the details, I can not yet 100% agree with you that making XUL and XBL standards will completely solve the problem. If we make them standards, and they are built on top of other layers at W3C, then I can agree. But I need to study the specifics of their design before I can make an absolute assertion on this issue. Will do... >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. Yes that is essentially same as what I wrote in my points. > When an author has reached the limits >of the abstraction, then he may directly incorporate lower layer >information into the document, Yes, and it is best that the lower layer also be a standard and not a proprietary api. And best he semantically abstract the lower layer for his application and use the semantic representation for instances, so that lower level dependencies are in one class. In essense we are simply restating the principles of good OO design. > which is generally not really declarative >markup, but rather programming. Agreed. >CSS is a good layer to standardize because it keeps you away from the >actual presentation and it's properties Agreed. > (until, that is, you start to >talk about the actual values computed by the presentation). We agree this is where many presentation properties may not have an inverse into style or DOM space, etc. But the most important ones may. We now agree to prioritize these types of properties even if there isn't an exact 1:1 correspondence to CSS (or XSL or...) in every case. >>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. Agreed, I read that XForms section and alluded to it in my previous email that you were responding to here. >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. Agreed, I read that section also. >I agree that there is a 1:1 correspondance of style inputs with the >XHTML abstract objects. And also Events with XForms. >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). We discussed this on phone and IMO we agreed that while the presentation properties do not correlate to CSS properties in every case, that we should make some reasoned attempt to expose the minimum presentation properties which correlate meaningfully to DOM, CSS, etc, depending on the presentation model. >>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. Ditto above. > There is >no "union set of markup" to the best of my knowledge. XML is a markup >language. CSS is not. Javascript is not. CSS is declarative language. Why is it not a markup language? Even the content markup can be swapped or ignored by the UA. Agreed scripting is not purely declarative. >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. But the issue is more general than just CSS. We also have events, selection, focus, etc and other layers that have to be output. Any way, we agreed on phone to handle as mentioned a few paragraphs above. >I would also not designate such a module "Views and Formatting" because >it does not have the proper associations to be a general mechanism. I am sure you agree a model has to incorporate the View to deal with scrolling, selection, etc. These are per View state. > 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. As we agreed on phone, I am just suggesting we expose the questions which do have presentation state answers and which are useful, and to make every effort to insure we expose in way that is most correlated with the possible inputs to the presentation. I think I misused (or you misterpreted my use of) the phrase "1:1 correlation". What I meant is there are certain obvious mappings which have strong correspondence (such as coordinates and dimensions) and even though they can be returned "in compound", there will be in some cases external transformations to return these to a 1:1 correspondence. One example I gave on the phone is where the presentation properties for "character runs" for a block level node returns multiple answers (segments) for the bounding boxes. One could then intersect or take union of these bounding boxes to get a 1:1 answer. We both agreed that such transformation models not be part of any initial model of the presentation layer (Views and Formatting). >>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. Apparently my misunderstanding was that I did not realize that Segments could be requested for DOM Nodes, and then those Segments could be further processed to obtain strong correlation answers for the input models. In essense, that is what I was asking for. I now visualize the strong correlations. > >>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. I think we possibly agreed on phone that different presentation models which expose different Segment models (types) and these will determine which input layers they map reasonably well to. I think we agree to make it a goal that the mappings leverage knowledge base in the CSS standard (and any other standard that has put a lot of work into abstracting presentation details, i.e. style, events, selection) to some reasonable degree. >>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. Yes I did miss that in original model. And that was a major component of our misunderstanding. > 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. I think we need to give this mapping more thought. Perhaps we can do better than "trial and error" approach to finding the mappings? Perhaps we can expose the sub-content as well as the DOM Nodes, in the matching specification, if not already. [...] > >>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. I think you DO agree with me. You agree the model can query for segment(s) properties that correlate to DOM Nodes. > DOM is whatever modules happen >to be supported by a browser. The existing proposal clearly permits the >questions to be asked using DOM. So you do agree then. >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. I wasn't clear on this. I think this was meant for another context which is no longer valid in our discussion. > 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. Already covered in this response. >>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. We agreed on the phone, as already covered in this response. >I do not understand what you are asking "for controlling style". I >have heard of no request for controlling these features. You've never seen a DHTML web page?? > >>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. <joke>Isn't that what you want-- unpredictable markup?<joke> Seriously though, IMO we agree there are very important classes where presentation properties can be interpreted in ways that have reasonable strong correspondence to many of the important inputs. Those are the correspondences we should prioritize, beginning with the bounding boxes (or time period, etc) in View space. > You cannot demand answers from a presentation in which the >questions have no reasonable single answer. IMO, we agreed on the phone, that in many cases a single answer can be deduced from the Segments model, either by inspection or other algorithm such as Set mathematics (union, intersection, etc). >>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. We covered this point already. Remember I said query for segments of the nth character of a block level node. > 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. There is an echo in the email :-) We've agreed on this already. :-) It was only tonight that I understood that the Segment model could return "CSS-like" properties (such as bounding boxes) on DOM Nodes (and hopefully also sub-content of Node). >This is not a reasonable question to ask in terms of CSS properties. I was originally talking about reusing the CSS properties (names and general work done to date in abstracting presentation style) in a new context. Remember I said with caveats, exemptions, etc. Any way as discussed already in this reply, IMO we agreed on phone to select properties for segments taking into account any thing already learned by the CSS group to the extent we can. > 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. Node sub-content query. [...the math analogies are not worth discussing because we did not understand each others' basis] >>>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. This is why we have to be very careful which layers we expose. I think we agreed on phone to be conservative in exposing presentation properties. Inevitably, bad authoring can combine layers into "vegetable soup" which is no longer portable as declarative markup. > XHTML banishes a few things, but anyone determined enough can use >it wrong and desstroy the abstractions, Yes that is a shame. I would prefer very strict validation. I guess it was not possible and also have backward compatibility?? Could we not use a DTD or Schema validation to force better (orthogonal) authoring?? >>>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. Disagree as of TODAY in REAL world. I can get a statistic which shows that the non-pure HTML markup dominates the web pages on the web. I posted the statistic in www-css the other day. I can locate it, if you do not believe me. > 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. The presentation layer model will advance abstractions. For example probably in XBL, by allowing them to be build standard widgets on top of a standard instead of hard-coded in the UA. I will need to study XBL in detail to confirm or clarify this assertion. >>> 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. Most readers do not heavily modify the default style sheets. > Usually specific CSS hurts more >than it helps, in my experience. IMHO, CSS group would agree with this. I think the correct answer is "it depends on the application". I would agree there are many cases where it is used when it preferably should not be, but often this is because of need to work around popular UA that do really silly things. And there are applications where it is necessary. > 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. http://coolpagehelp.com Is this site better or worse with frames? (btw, that is one of my sites) > 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. He doesn't need to make this assumption. CSS has points and inch metrics. I realize these are not well implemented in UA, but that is besides the point of the model. >>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. Thanks. That is what I want to hear. So please help me work for a solution. >>>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. So you agree NOW that it is not 100% blind, and there is some reliance on 2D presentations cases for the best designers. Not to mention the other millions of average designers. We live in an imperfect world, but we should strive for better abstractin layering (modularization). >>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. Such as set ALT tags, etc. Yes we try and CP exposes these. We want to improve. I need the View model. I am going to get it with or without your support. So I strongly urge you to help me work towards a standards solution. >>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. No because I can not control something which I do not know what it's current state is. Yes a subset of write-only interfaces is exposed. We agree we need to expose presentation layer for reading, even if the correlation is not perfect. [...] >>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. > >No where in the segment model was the power given to modify the segments. Good. I thought there was no correlation of segments to Nodes. In that case, absence of a write model would make the read model useless. Now I understand there is a correlation to Nodes. >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 and I got hung up on "1:1 correlation". What I now understand you have in the model, is my definition of "1:1". Specifically that you can query for segments on a Node. You have a more strict interpretation of "1:1". You define it to be 1:1 only if 1 segment matches 1 node. I always thought of 1 set of things (what I called "multi-variant" before) matching 1 Node. Realize that I do not write standards specifications as a career, so I have a less strict and more abstract way of communicating. I leave the strict details for the last stage of my work on a particular project. >>>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. But much better the abstraction be written by me (and others) USING W3C STANDARDS, so I can transport it, than something proprietary to Netscape. I bet the XUL+XBL can be built on top of Views model and existing W3C modules, so it is easily transported to any UA. I will comment more on the feasibility of that later after I study XBL more. ,>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). Exactly it is a narrow standard, proprietary, and XBL can do no better. Better I build on top of a Views standard. Please do not debate this. Let me first investigate XBL more, then if I am wrong, I will come back here and note it. Else I will come back here and elaborate. >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. Exactly. Agreed. > >>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... I am not trying to get raw events. I have no current plans to use events at that level of device-dependent abstraction. I think any thing that is extremely device dependent (will vary on each operating system in otherwise same presentation model, e.g. 2D screen) is to be de-prioritized. We should get the highest abstraction layer of presentation done before moving lower. > >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. That sounds great. Let me study the model again to understand this. I assume "element" is same as Node or Node sub-content in this context. >>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. Agreed, except I think you should use "content markup" to be more explicit. >>Because I think "abstract" is always relative. >> >> >Clearly that is true, just as one man's model is another man's view. Thanks. Glad we agreed. >>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. I thought I did already. Let me try again. ((View*) document.getInterface( view )).getElementById( id ).getSubContentSegment( offset_into_node_content ); Or if you prefer: View *p = (View *)document.getView(); p.GetElementSubContentSegment( document.getElementById( id ), offset_into_node_content ); Both interfaces are equivalent. This is essentially a different way of exposing a case of your Match model. I am not decided yet which is best. Probably your more general interface. The most important things is the existing correlation of DOM to segments. And our apparent conceptual agreement on types of properties to expose. > 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. Already answered in this response. I think we agree on solution. > >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. They do it using IE's proprietary API. We need this standard. I think perhaps people are not clamoring for it, because the model is not well explained. I do not think most people understand the strong correlations. They prefer IE's easy correlations. I think our first task is to improve the existing WD to include more examples, and to make some suggested convenience methods to show the correlations that might be possible. I'd be willing to do this work, if you approve. -Shelby Moore
Received on Saturday, 21 December 2002 01:56:48 UTC