Subject: Re: [dom3core] getAttribute - msg#00034

Previous Message by Date: click to view message preview

Re: [dom3core] WRONG_DOCUMENT_ERR

On Dec 1, 2005, at 11:46 PM, Maciej Stachowiak wrote: Just because you know of browsers able to do this doesn't mean it is a good idea to allow it. The browsers able to do it add up to 98-99% of browser market share. When a web site is broken, users do not typically step back to read the spec, they file bug reports against the offending browser. Standards compliance is important to us. However, browsing the actual existing web is also important. Please, show me the numbers' source. Or are you just making up "hypothetical" numbers? When someone says "my code doesn't work in your browser, which you claim to be DOM-compliant", but it worked in Safari, I am much happier to tell them "that is because Safari is not DOM compliant" rather than telling them "that is because DOM isn't interoperable between two implementations in this feature, even though you complied with the standard". Do you actually have a browser, or is this a hypothetical? Have you heard of Firefox? I represented AOL / Netscape last on the DOM committee, and as with other issues, we spent lots of time talking to group members reaching a consensus. Johnny Stenback was there doing DOM work from Netscape as were others. Now, where does the 98-99% come from, without including Mozilla-based browsers? There are/were at the time several DOM implementations used for different purposes within the Mozilla product, for example, between HTML documents, XML data being sent via http requests, SOAP requests, etc. and possibly other fundamental types of documents that were not compatible to be inserted inside each other. I would suspect although I cannot claim for certain from memory that IE may have similar problems between different DOM implementations in the product. There was much emphasis at the time on being able to support diverse DOM implementations, both for browsers and for Java. That is why making exceptions optional in this sort of case is a bad idea, and we created alternative mechanisms to allow all implementations to handle the situation. If the alternative you're talking about is DOM Level 3 Core adoptNode, note that as specified it appears to be optional. The spec says "If supported" and says what applications should do when not supported. Therefore, it appears to have all the same problems that loosening the exception requirements on appendChild would, and the very same workaround to make apps that can work with both kinds of implementations (use importNode instead when it fails). Why is this behavior acceptable for adoptNode but not appendChild and the like? It is not the same, because it is an API that is clearly designed to be optionally supported, with alternative methods for situations where it might fail. There are also cases where the implementation is possible with an explicit adoption that it is not without an explicit adoption, for example to support the ownerDocument attribute for a node which is currently not attached in the child hierarchy of the document in question, which I remember was a concern of the group. Does your implementation properly implement the ownerDocument attribute? Just because there are no current tests you fail does not at all mean you have a compliant implementation. The test only demonstrates that someone implemented certain tested points of the standard. No test can ever prove compliance to this sort of standard and the test suite was never designed for tthat. It only proves non-compliance. What we have was the group consensus. Now, are you going to set up a working group to get the same participant companies back into the room because you couldn't make the prior meetings when the issue was on the table (good luck with the logistics), or is there little point to your complaints at this point? But more importanly, the alternative mechanism doesn't do anything to help implementations browse the existing web, and therefore is not an actual solution to the problem I posed. There is no standards-based solution to broken HTML or broken javascript, at W3C and I believe there never will be. If you need to support it, you have to figure it out yourself. The same sort of solution I mentioned previously with respect to the getAttribute might be tried in this case if one were looking to actually support the consensus-based W3C DOM solution. The possible approaches of browsers to broken DOM scripts does not seem that far removed from the approach of browsers to broken HTML which most support (and unfortunately often do nothing to guide web authors to clean up their HTML or Javascript, which would be quite easy). I could name any number of other features broken in IE, so should we continuously update the standard to reflect the bugs de jure, hurting anyone who followed the specification? While I would never rule out what might be appropriate in some particular situation, this seems inappropriate in these situations. I have authored a number of web sites myself and have lots of friends who have and have never come across either of these abuses of the standard, and there are any number of others you are leaving out if you wish to convert the DOM standard into an inherently-incomplete manual on the behavior of IE with no regard to the consensus. Ray Whitmer ray@xxxxxxxxxxxxxxxxx

Next Message by Date: click to view message preview

Re: [dom3core] getAttribute

On Dec 2, 2005, at 12:33 AM, Maciej Stachowiak wrote: On Dec 1, 2005, at 9:23 AM, Ray Whitmer wrote: The web browser should be a tool for promoting good behavior, not broken behavior The web browser should be a tool for browsing the web. That is no valid excuse for abdicating all responsibility for how the web is browsed. The browsers shape that, as they always have. Ray

Previous Message by Thread: click to view message preview

Re: [dom3core] getAttribute

Hi, On Fri, 2005-12-02 at 11:30 -0800, Maciej Stachowiak wrote: > On Dec 2, 2005, at 1:37 AM, Kasimier Buchcik wrote: > > > Hi, > > > > On Thu, 2005-12-01 at 23:16 -0800, Maciej Stachowiak wrote: > >> > >> On Dec 1, 2005, at 6:34 AM, Ray Whitmer wrote: > >> > >>> > >>> Can you tell me how many implementers of the standard would be made > >>> retroactively incompatible by this sort of change to an intentional > >>> part of DOM Level 1? I am not talking the major vendors current > >>> implementations, but other and prior implementatiions? Please > >>> enumerate those which will not be broken and let's see how many you > >>> leave out. It is perhaps not as relevant to me as you would like it > >>> to be that you personally do not care about these other > >>> implementations which followed the standard. I have know list but > >>> know of enough. > >> > >> Making either empty string or null an acceptable return value in this > >> case will break 0 implementations. Can you name any that would be > > > > How did you evaluate that it breaks 0 implementations? > > Since previously conforming DOM implementations would remain > conforming, there's no possible way they could be broken. Unless I > misunderstand what you mean. > > >> broken by making both behaviors conforming? I can't imagine how this > >> is possible. > > > > Yesterday I already posted a description of such a scenario. > > > > In case you missed it: > > > > If we have (e.getAttribute('foo') != "") then this will evaluate to > > true if: > > 1) there is an attribute node and its value is other than "" > > > > The change you request, would evaluate this to true if: > > 1) there is _no_ such attribute node (NULL != "") > > 2) there is such attribute node and its value is other than "" > > > > So every existing code which tests if an attribute node's value is > > non-empty, will break. > > That's not a DOM implementation, that's a DOM application. True, but then I'm not sure what the essence of your statement was, if it referred to the implementation only; probably no implementation would break if we would decide to return a hard-coded value of "foo" for getAttribute(). What was your point in referring to the implementation only? > > I can't claim it would break 0 applications, but I would expect most > ECMAScript DOM applications follow the de facto standard on this, not > the written spec. In other words, relaxing the spec on this would fix > far more applications than it would break. This is easy to say for you, but without a survey of the amount of code this change would break I'm see not much value in such a statement. I would find it more difficult to change non-script code already compiled and running, than script code with a text-replacing tool. > I'm also not sure you understand the proposed change. The proposal is > to allow implementations to return EITHER empty string OR null in > these cases. Presumably Java-based or C++-based implementations would > maintain their current behavior. I have understood the proposed change. I don't think it would be wise to have such an option. Optional behaviour should be restricted to issues which are not common, or you will end up in a lot of additional code, just to handle both cases. Neither I think the behaviour of such a fundamental method should deviate from implementation to implementation. Let's look at some code examples: - code like (e.getAttribute('foo') != "") would break - code like (e.getAttribute('foo') != NULL) and code like (e.getAttribute('foo') != ""), i.e. code for testing of a non-empty value of an attribute, would need to be rewritten to: ((e.getAttribute('foo') != "") && (e.getAttribute('foo') != NULL)) What code would profit from such a change? Actually I have difficulties to understand what code would profit from an optional return value of getAttribute(). If we take (e.getAttribute('foo') == NULL) as an example, and the author does not know that DOM implementation will be used on the user's side, then normally, a DOM implementation should be queried for such an option; so we get: if (someAttributeCanDoNULLMethod()) if (e.getAttribute('foo') == NULL) ... else if (e.getAttributeNode('foo') == NULL) ... An optional return value would produce a lot of trouble in my eyes. But I think you refer to a world where _all_ browser DOM implementations would implement the option to return NULL; i.e. the author would rely on NULL being returned, when an attribute is not existent and would need not to write additional code to test for both cases. Then the broken code you refer to would work. But this is exactly the case where I see the advantages of DOM - a portable API - being eroded. Such code would not be portable any more. Plus, excuse me for repeating this once more, such an option would _extend_ the semantics of getAttribute(), in a way that it allows only certain programming languages to test for non-existent attribute nodes. Regards, Kasimier

Next Message by Thread: click to view message preview

Re: [dom3core] getAttribute

We *did* debate this during the design of the DOM. The distinction between null and empty string was considered meaningful, for the reasons that have been pointed out. Folks are welcome to disagree with our decision, but there is absolutely no way it can be considered an erratum. And it's MUCH too late to propose it as a functional change to the DOM. ______________________________________ Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk