Microsoft and attributes--will they ever figure them out?
in [JavaScript]
|
Prev: What is a software engineer?
Next: Java Front end Developer | NYC | Long term (Only GC/Citizens)
From: David Mark on 16 Dec 2009 12:46 On Dec 16, 11:45 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> David Mark wrote: > >> >> >> > That's why you can't use properties - for example - to write an > >> >> >> > innerHTML emulation. > >> >> >> Yes, you can. > >> >> > A pretty crappy one. :( > >> >> How so? > >> > Would be full of DOM defaults, user input, > >> No. > > > No? How would you know which are defaults? > > From the specifications. I see. Unfortunately, some browser developers (e.g. MS) don't see the specifications as firm rules. > > >> > resolved paths, > >> So what? > > > So, it's not the markup you are trying to serialize. > > Not exactly, that is correct. Like innerHTML, the innerHTML replacement > implementation only needs to provide something that resembles the original > markup enough for it to work; in the case of the replacement that means that > it needs to be consistent in one user agent, and interoperable among user > agents if possible. Interoperability through consistency is the point. > > >> > etc., so it would vary wildly from one browser to the next and would > >> > never give a clear view of the underlying document. > >> What you appear to be overlooking is that it was never supposed to. > > > What wasn't? > > `innerHTML' does not give "a clear view of the underlying document" either. That's the point. My example is a replacement that does. As mentioned, if the innerHTML were standardized to the point of interoperability, this would be a moot point. > But it does not need to nor would it appear that it was supposed to. See directly above. > > > > >> > [...] If you want to serialize something like this:- > > >> > <div id="test"></div> > > >> > ...you don't normally want this:- > > >> > <div id="test" maxlength="1234567" tabindex="0" ... ></div> > > > Typo. That was supposed to be an INPUT example. > > >> > What would you do with such a novelty? > > >> It is not going to happen in the first place. My implementation would > >> consider only properties specified in W3C DOM Level 2 HTML. > > > See above. > > The default values for `maxLength' and `tabIndex' are -1 and 0 in a Gecko- > based browser. So? Obviously the former (or the value 0) does not make sense so > it can be safely ignored for serialization. The latter? How do you figure a default tab index of 0 makes no sense? It makes perfect sense to me. > Per HTML 4.01, it only needs to > be considered for type="text" or type="password" anyway. That illustrates just how old that spec is. It was just the starting point. Obviously if you ignored tab index for all but text and password inputs today, you would miss a lot of significant information. > > As for the latter, if one were to avoid the attribute specification, when in > doubt hasAttribute() or getAttribute() can be called for comparison. Not sure what you mean about avoiding the attribute specification. As for hasAttribute, that was introduced by MS in IE8 (standards mode only). And, as I hope we all know by _now_ (two years since this subject was brought up and beaten to death), get/set/removeAttribute are all screwy in IE < 8 (and IE8 compatibility mode). So what are you saying? For a "Real World" example, at the recent jQuery attribute summit, somebody pointed out that jQuery UI uses these DOM methods (sparingly), but calls jQuery's odd assortment of "wrappers" more often. "47 occurrences of .attr() (a mix of string and object argument syntaxes) and 12 .removeAttr()'s" What does that tell you? It was determined by the panel that:- "jQuery UI is more then expected to work browser independently, its implied by its use." I wouldn't expect their cunning plan to work any bettter than whatever it is you mean by using has/getAttribute "when in doubt". My position is there shouldn't be any real doubt about these methods at this point. > > >> We are not dealing with any markup language here, but with HTML. Since > >> responsible Web development forbids augmenting host objects, proprietary > >> attributes and properties, I would simply ignore them. > > > I wasn't talking about those. > > Look, I am not to guess your thoughts; you will have to tell them or > consider your "argument" discarded. Discard at will. Like I said, never mind custom attributes. Obviously, we are talking about the standard ones. > > >> Granted, that is not the same as `innerHTML'; it is a lot better. > > > Depends on the context. It wouldn't be better for the examples I > > listed. > > Unfortunately, your "examples" are too general to be useful in a discussion. That's your opinion. > > >> > Similarly, if you have this structure:- > > >> > <input name="test" value="test"> > > >> > the "proper" serialization would not normally be:- > > >> > <input name="test" value="last thing the user typed"> > > >> > The value attribute if reflected by defaultValue, not its namesake > >> > property. The same goes for checked and selected. > >> Some exceptions to the rule need to made, of course. That does not mean > >> one needs a full-blown getAttribute() fixing wrapper to do this. > > > I've mentioned that several times in this thread. > > I do not want to read that whole mostly full-quoted thread and sieve your > possible points out of it. Okay. :) > If you want to prove something, prove it here. I'm not trying to prove anything. > If you do not want to repeat yourself too much, you can support the argument > with a Message-ID to one of your postings. Thanks. > > > Best to test (and fix) only the features you need. However I've listed a > > few examples where you would need the whole thing. > > Name them. And no more commonplace examples, please. What do you consider commonplace? > > >> > These details matter for a number of applications (though they should > >> > not for a basic Web app). > >> Exactly, they should not. > > > Unfortunately, the current lynch-pins for the "major" libraries are > > CSS selector queries. So everyone using them is potentially affected > > by these variations. > > Their problem. Exactly. > You argument is too general to be useful, again. I don't see that at all. > > >> > A basic (consistent) innerHTML emulation is > >> > the first thing that comes to mind. > >> That kind of emulation would need to be restricted to attributes > >> specified in HTML and properties specified in W3C DOM Level 2 HTML, > >> right? > > > Not necessarily, no. > > It was a rhetorical question. Most certainly the answer is yes. I don't see that either. I say no. > Those two Specifications are the lowest common denominator. You could still include custom attributes in a serialization. I'm not saying it would be particularly useful though. > > >> > Serialization of edited HTML is another. > >> I do not see your point. > > > Have you ever written an editor? > > No, but I have debugged one. Get to the point, please. I made the point about the editor. > > >> > The proprietary innerHTML as seen by the host does not make > >> > a good canonical form (e.g. the form to send to the DB on the server). > >> Exactly my point. So is it not next to stupid to try to emulate it as > >> exactly as possible? > > > That's not what I said at all. The emulation I propose would be > > consistent cross-browser. > > I will look into it if and when I find the time. Until then, I will > continue writing my own. Look into what? There are some related wrappers in My Library (e.g. getElementHtml, getElementOuterHtml). > > > If the host innerHTML properties were 100% consistent and standardized, > > there would be no need for such a solution. > > Correct, but useless. I don't follow that. > > >> > Then there are these silly CSS selector query engines, which have > >> > become a ludicrous standard fixture for "Real World" Web apps. A lot > >> > of them use XPath. > >> XPath does not work with HTML in MSHTML, > > Exactly. > > >> and in Gecko & friends I can use > >> the native XPath implemenation. > > Right. > > >> I do not see your point. > > > You just reinforced it. :) Have you ever written a CSS selector > > query? > > No. Well, then perhaps you haven't considered what goes into it. Think about it. > > > If not, think about what you use XPath for in Gecko > > I use it to retrieve elements by type identifier or attribute or ancestor- > descendant relationship. Aside from the `class' attribute in (X)HTML, CSS > does not even enter into my considerations. Okay. > > > and imagine what you would need to do to duplicate it in IE. > > This is not a guessing game. Get to the point, please. How would you duplicate any or all of those XPath tasks in IE? > > >> > Some purport to support both HTML and XML DOM's. > >> So what? > > > So, you seem lost. > > Likewise. Well, I'm not. > > >> > Others use QSA. So the requirements for an alternate jQuery-ish fork > >> > are clear. Any variations between the various forks will lead to > >> > sporadic incompatibilities that will be virtually impossible to track > >> > down without writing a dissertation on the underlying library code > >> > (probably more than the average code monkey bargains for). > > >> You cannot fix junk, you can only replace it with something better which > >> means that you must not implement all its quirks. > > > You have missed the point entirely. I am not talking about > > replicating quirks at all. > > So, what are you talking about then? At this point, that's my line. :) > > And try to keep your quotes short, would you, please? Sure.
From: Thomas 'PointedEars' Lahn on 16 Dec 2009 13:38 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> David Mark wrote: >> >> >> >> > That's why you can't use properties - for example - to write >> >> >> >> > an innerHTML emulation. >> >> >> >> Yes, you can. >> >> >> > A pretty crappy one. :( >> >> >> How so? >> >> > Would be full of DOM defaults, user input, >> >> No. >> > No? How would you know which are defaults? >> From the specifications. > > I see. Unfortunately, some browser developers (e.g. MS) don't see the > specifications as firm rules. One can determine which default values of attribute properties are necessary to include in the serialization and which are not. >> >> > resolved paths, >> >> So what? >> > So, it's not the markup you are trying to serialize. >> >> Not exactly, that is correct. Like innerHTML, the innerHTML replacement >> implementation only needs to provide something that resembles the >> original markup enough for it to work; in the case of the replacement >> that means that it needs to be consistent in one user agent, and >> interoperable among user agents if possible. > > Interoperability through consistency is the point. However, this contradicts your requirement that there would need to be a bijection between the element object and the serialization of it. >> >> > etc., so it would vary wildly from one browser to the next and would >> >> > never give a clear view of the underlying document. >> >> What you appear to be overlooking is that it was never supposed to. >> > What wasn't? >> `innerHTML' does not give "a clear view of the underlying document" >> either. > > That's the point. My example is a replacement that does. As > mentioned, if the innerHTML were standardized to the point of > interoperability, this would be a moot point. > >> But it does not need to nor would it appear that it was supposed to. > > See directly above. Still nobody needs that. >> The default values for `maxLength' and `tabIndex' are -1 and 0 in a >> Gecko- based browser. > > So? > >> Obviously the former (or the value 0) does not make sense so >> it can be safely ignored for serialization. > > The latter? No, the former, maxLength < 0 or maxLength == 0. > How do you figure a default tab index of 0 makes no > sense? It makes perfect sense to me. Check your assumptions. tabIndex == 0 is the same as if the `tabindex' attribute was not supported on an element or was not specified (omitted). <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex> >> Per HTML 4.01, it only needs to be considered for type="text" or >> type="password" anyway. > > That illustrates just how old that spec is. No, if it illustrates anything then that it is the lowest common denominator, the target for achieving interoperability. > It was just the starting point. Obviously if you ignored tab index for > all but text and password inputs today, you would miss a lot of > significant information. Not information significant to interoperability, which was the point of the whole exercise. >> As for the latter, if one were to avoid the attribute specification, when >> in doubt hasAttribute() or getAttribute() can be called for comparison. > > Not sure what you mean about avoiding the attribute specification. It means not serializing an attribute property and its value into `attribute="value"' because it would not make a difference. > As for hasAttribute, that was introduced by MS in IE8 (standards mode > only). And, as I hope we all know by _now_ (two years since this > subject was brought up and beaten to death), get/set/removeAttribute > are all screwy in IE < 8 (and IE8 compatibility mode). So "screwy" that you cannot use it to differentiate whether the attribute was specified or not? I doubt it. >> >> Granted, that is not the same as `innerHTML'; it is a lot better. >> > Depends on the context. It wouldn't be better for the examples I >> > listed. >> >> Unfortunately, your "examples" are too general to be useful in a >> discussion. > > That's your opinion. Which should be relevant to you as you are discussing this with me. Unless your purpose here is just to state something and to hell with the contradictions. >> If you want to prove something, prove it here. > > I'm not trying to prove anything. What are you up to, then? >> > Best to test (and fix) only the features you need. However I've listed >> > a few examples where you would need the whole thing. >> Name them. And no more commonplace examples, please. > > What do you consider commonplace? Too general a description. >> You argument is too general to be useful, again. > > I don't see that at all. Well, you are talking rather nebulously about potential problems. Why not take this opportunity to name some of the perceived problems explicitly and concisely instead, to support your argument? >> Those two Specifications are the lowest common denominator. > > You could still include custom attributes in a serialization. I'm not > saying it would be particularly useful though. Most importantly, it would not be interoperable, so we can safely ignore them by default. >> >> > Serialization of edited HTML is another. >> >> I do not see your point. >> > Have you ever written an editor? >> No, but I have debugged one. Get to the point, please. > > I made the point about the editor. No, you failed to do that by asking a closed question which could be understood as a red herring. >> > If the host innerHTML properties were 100% consistent and standardized, >> > there would be no need for such a solution. >> Correct, but useless. > > I don't follow that. While stating the obvious is no doubt a correct statement in itself, it does not help with this discussion. >> >> > Then there are these silly CSS selector query engines, which have >> >> > become a ludicrous standard fixture for "Real World" Web apps. A >> >> > lot of them use XPath. >> >> XPath does not work with HTML in MSHTML, >> > Exactly. >> >> and in Gecko & friends I can use >> >> the native XPath implemenation. >> > Right. >> >> I do not see your point. >> > You just reinforced it. :) Have you ever written a CSS selector >> > query? >> No. > > Well, then perhaps you haven't considered what goes into it. Think > about it. I am growing tired of your commonplace arguments. >> > If not, think about what you use XPath for in Gecko >> I use it to retrieve elements by type identifier or attribute or >> ancestor- descendant relationship. Aside from the `class' attribute in >> (X)HTML, CSS does not even enter into my considerations. > > Okay. > >> > and imagine what you would need to do to duplicate it in IE. >> This is not a guessing game. Get to the point, please. > > How would you duplicate any or all of those XPath tasks in IE? Type identifier is easy as is ancestor-decendant relationship. Attributes are a bit harder, but not unsolvable. That said, I would not even attempt using XPath in IE except for XHTML served as text/xml or application/xml where there is a native implementation. So you see, you are tackling the problem from the wrong side: XPath in HTML is a (proprietary) bonus in Gecko (and perhaps in other !MSHTMLs) that can be taken advantage of on occasion, not a lack in MSHTML that needs to be compensated for. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: David Mark on 17 Dec 2009 09:55 On Dec 16, 1:38 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> David Mark wrote: > >> >> > Thomas 'PointedEars' Lahn wrote: > >> >> >> David Mark wrote: > >> >> >> >> > That's why you can't use properties - for example - to write > >> >> >> >> > an innerHTML emulation. > >> >> >> >> Yes, you can. > >> >> >> > A pretty crappy one. :( > >> >> >> How so? > >> >> > Would be full of DOM defaults, user input, > >> >> No. > >> > No? How would you know which are defaults? > >> From the specifications. > > > I see. Unfortunately, some browser developers (e.g. MS) don't see the > > specifications as firm rules. > > One can determine which default values of attribute properties are necessary > to include in the serialization and which are not. You don't know _which_ property values are defaults. For instance, maxlength has a default of some very large number in MSHTML. And this:- <a href="..." tabindex="0"> ....is not the same as this:- <a href="..."> ....and no, you cannot just go with the latter. :) > > >> >> > resolved paths, > >> >> So what? > >> > So, it's not the markup you are trying to serialize. > > >> Not exactly, that is correct. Like innerHTML, the innerHTML replacement > >> implementation only needs to provide something that resembles the > >> original markup enough for it to work; in the case of the replacement > >> that means that it needs to be consistent in one user agent, and > >> interoperable among user agents if possible. > > > Interoperability through consistency is the point. > > However, this contradicts your requirement that there would need to be a > bijection between the element object and the serialization of it. You are very confused (and not making sense at all) Bijection? > > >> >> > etc., so it would vary wildly from one browser to the next and would > >> >> > never give a clear view of the underlying document. > >> >> What you appear to be overlooking is that it was never supposed to. > >> > What wasn't? > >> `innerHTML' does not give "a clear view of the underlying document" > >> either. > > > That's the point. My example is a replacement that does. As > > mentioned, if the innerHTML were standardized to the point of > > interoperability, this would be a moot point. > > >> But it does not need to nor would it appear that it was supposed to. > > > See directly above. > > Still nobody needs that. Those who would rely on CSS selector queries would certainly need it. Same for an editor that must save its results. And you said yourself that you would "refer" to hasAttribute and getAttribute, when in "doubt". How would you do that if those methods are missing or broken? :) > > >> The default values for `maxLength' and `tabIndex' are -1 and 0 in a > >> Gecko- based browser. > > > So? > > >> Obviously the former (or the value 0) does not make sense so > >> it can be safely ignored for serialization. > > > The latter? > > No, the former, maxLength < 0 or maxLength == 0. Regardless, the default is some huge integer in MSHTML. Will you throw out every value that is either very large or negative? :) > > > How do you figure a default tab index of 0 makes no > > sense? It makes perfect sense to me. > > Check your assumptions. tabIndex == 0 is the same as if the `tabindex' > attribute was not supported on an element or was not specified (omitted). Nope. You are dead wrong on that. Leaving it off will disallow tabbing to that element in some agents. And if it is not supported, the property value is typically undefined. Also, leaving it off - for example - a DIV will result in a default property value of -1 in some agents. You've got nothing to go on. It's really simple. Either you can serialize a document or you can't. I've demonstrated how to do it (e.g. getElementOuterHtml in My Library) and you have speculated how you might do it. I'm telling you that your proposed algorithm will result in markup that looks like the output of MS Word. :) > > <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex> Forms? It's not as if form elements are the only concern for tabindex. > > >> Per HTML 4.01, it only needs to be considered for type="text" or > >> type="password" anyway. > > > That illustrates just how old that spec is. > > No, if it illustrates anything then that it is the lowest common > denominator, the target for achieving interoperability. All I am saying is that you could optionally allow non-standard attributes. > > > It was just the starting point. Obviously if you ignored tab index for > > all but text and password inputs today, you would miss a lot of > > significant information. > > Not information significant to interoperability, which was the point of the > whole exercise. Wrong. See above. > > >> As for the latter, if one were to avoid the attribute specification, when > >> in doubt hasAttribute() or getAttribute() can be called for comparison.. > > > Not sure what you mean about avoiding the attribute specification. > > It means not serializing an attribute property and its value into > `attribute="value"' because it would not make a difference. Still not clear what you mean. > > > As for hasAttribute, that was introduced by MS in IE8 (standards mode > > only). And, as I hope we all know by _now_ (two years since this > > subject was brought up and beaten to death), get/set/removeAttribute > > are all screwy in IE < 8 (and IE8 compatibility mode). > > So "screwy" that you cannot use it to differentiate whether the attribute > was specified or not? I doubt it. You better believe it. And if you don't, that explains your "position" on this. > > >> >> Granted, that is not the same as `innerHTML'; it is a lot better. > >> > Depends on the context. It wouldn't be better for the examples I > >> > listed. > > >> Unfortunately, your "examples" are too general to be useful in a > >> discussion. > > > That's your opinion. > > Which should be relevant to you as you are discussing this with me. Unless > your purpose here is just to state something and to hell with the > contradictions. Your assertion about "general examples" has no technical meaning. > > >> If you want to prove something, prove it here. > > > I'm not trying to prove anything. > > What are you up to, then? > > >> > Best to test (and fix) only the features you need. However I've listed > >> > a few examples where you would need the whole thing. > >> Name them. And no more commonplace examples, please. > > > What do you consider commonplace? > > Too general a description. Whatever. > > >> You argument is too general to be useful, again. > > > I don't see that at all. > > Well, you are talking rather nebulously about potential problems. Why not > take this opportunity to name some of the perceived problems explicitly and > concisely instead, to support your argument? As you mentioned, you are way behind on this. Catch up and your questions will have been answered. > > >> Those two Specifications are the lowest common denominator. > > > You could still include custom attributes in a serialization. I'm not > > saying it would be particularly useful though. > > Most importantly, it would not be interoperable, so we can safely ignore > them by default. > > >> >> > Serialization of edited HTML is another. > >> >> I do not see your point. > >> > Have you ever written an editor? > >> No, but I have debugged one. Get to the point, please. > > > I made the point about the editor. > > No, you failed to do that by asking a closed question which could be > understood as a red herring. You just can't get your brain around this or you are deliberately obfuscating the points made. I don't really care which at this point. > > >> > If the host innerHTML properties were 100% consistent and standardized, > >> > there would be no need for such a solution. > >> Correct, but useless. > > > I don't follow that. > > While stating the obvious is no doubt a correct statement in itself, it does > not help with this discussion. > > >> >> > Then there are these silly CSS selector query engines, which have > >> >> > become a ludicrous standard fixture for "Real World" Web apps. A > >> >> > lot of them use XPath. > >> >> XPath does not work with HTML in MSHTML, > >> > Exactly. > >> >> and in Gecko & friends I can use > >> >> the native XPath implemenation. > >> > Right. > >> >> I do not see your point. > >> > You just reinforced it. :) Have you ever written a CSS selector > >> > query? > >> No. > > > Well, then perhaps you haven't considered what goes into it. Think > > about it. > > I am growing tired of your commonplace arguments. There's that word again. > > >> > If not, think about what you use XPath for in Gecko > >> I use it to retrieve elements by type identifier or attribute or > >> ancestor- descendant relationship. Aside from the `class' attribute in > >> (X)HTML, CSS does not even enter into my considerations. > > > Okay. > > >> > and imagine what you would need to do to duplicate it in IE. > >> This is not a guessing game. Get to the point, please. > > > How would you duplicate any or all of those XPath tasks in IE? > > Type identifier is easy as is ancestor-decendant relationship. Attributes > are a bit harder, but not unsolvable. Read that last bit again. You summarized my point exactly. Take it a step further and realize that none of the "major" libraries have even tried to solve it. > > That said, I would not even attempt using XPath in IE except for XHTML > served as text/xml or application/xml where there is a native > implementation. Of course you wouldn't attempt to use XPath with MSHTML (for an HTML DOM). That's why you would have to write an equivalent script. And that requires... > So you see, you are tackling the problem from the wrong > side: XPath in HTML is a (proprietary) bonus in Gecko (and perhaps in other > !MSHTMLs) that can be taken advantage of on occasion, not a lack in MSHTML > that needs to be compensated for. You clearly don't know what I'm doing or why. Strange.
From: Thomas 'PointedEars' Lahn on 19 Dec 2009 01:00 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> David Mark wrote: >> >> >> > Thomas 'PointedEars' Lahn wrote: >> >> >> >> David Mark wrote: >> >> >> >> >> > That's why you can't use properties - for example - to >> >> >> >> >> > write an innerHTML emulation. >> >> >> >> >> Yes, you can. >> >> >> >> > A pretty crappy one. :( >> >> >> >> How so? >> >> >> > Would be full of DOM defaults, user input, >> >> >> No. >> >> > No? How would you know which are defaults? >> >> From the specifications. >> > I see. Unfortunately, some browser developers (e.g. MS) don't see the >> > specifications as firm rules. >> One can determine which default values of attribute properties are >> necessary to include in the serialization and which are not. > > You don't know _which_ property values are defaults. For instance, > maxlength has a default of some very large number in MSHTML. I have to see it before I believe it. > And this:- > > <a href="..." tabindex="0"> > > ...is not the same as this:- > > <a href="..."> Yes, it is. > ...and no, you cannot just go with the latter. :) Yes, you can. The HTML 4.01 Specification is very clear about this. If only one browser or whatever that is not Firefox/Iceweasel 3.5.6 (where I have confirmed the Specification regarding this) differs here, then this behavior would be a bug that does not need to be considered for an `innerHTML' replacement that wants to be interoperable. IOW, the attribute specification in question should not have been in the document in the first place, so it can be safely omitted. >> >> >> > resolved paths, >> >> >> So what? >> >> > So, it's not the markup you are trying to serialize. >> >> >> >> Not exactly, that is correct. Like innerHTML, the innerHTML >> >> replacement implementation only needs to provide something that >> >> resembles the original markup enough for it to work; in the case of >> >> the replacement that means that it needs to be consistent in one user >> >> agent, and interoperable among user agents if possible. >> > >> > Interoperability through consistency is the point. >> >> However, this contradicts your requirement that there would need to be a >> bijection between the element object and the serialization of it. > > You are very confused (and not making sense at all) Bijection? Try a (mathematical) dictionary. Or Wikipedia. >> >> `innerHTML' does not give "a clear view of the underlying document" >> >> either. >> > That's the point. My example is a replacement that does. As >> > mentioned, if the innerHTML were standardized to the point of >> > interoperability, this would be a moot point. >> > >> >> But it does not need to nor would it appear that it was supposed to. >> > >> > See directly above. >> >> Still nobody needs that. > > Those who would rely on CSS selector queries would certainly need it. > Same for an editor that must save its results. > > And you said yourself that you would "refer" to hasAttribute and > getAttribute, when in "doubt". How would you do that if those methods > are missing or broken? :) I think you are citing me out of context. But I see your point here. >> >> Obviously [maxLength < 0 or maxLength == 0] does not make sense so >> >> it can be safely ignored for serialization. >> [...] > > Regardless, the default is some huge integer in MSHTML. Starting with which version, on which element types? Not in 6.0.2800.1106 for `A' and INPUT elements, the default value is 0 there. > Will you throw out every value that is either very large or negative? :) It *might* be necessary to check the attribute specification (attribute=value); however, if the default value is such a large value, and there are different large default values on other elements in the same document that correspond with their relative position in the document stream, it can be safely included. Maybe it would not be pretty, but it would not be harmful either. >> > How do you figure a default tab index of 0 makes no >> > sense? It makes perfect sense to me. >> >> Check your assumptions. tabIndex == 0 is the same as if the `tabindex' >> attribute was not supported on an element or was not specified (omitted). > > Nope. You are dead wrong on that. Leaving it off will disallow > tabbing to that element in some agents. So we have either a bug or not Valid markup here, evidently ("some") not to be considered for an interoperable solution. > And if it is not supported, the property value is typically undefined. So? !!undefined === false. > Also, leaving it off - for example - a DIV will result in a default > property value of -1 in some agents. You've got nothing to go on. DIV elements do not have a `tabindex' attribute in Valid (X)HTML. >> <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex> > > Forms? It's not as if form elements are the only concern for > tabindex. That does not matter. >> >> Per HTML 4.01, it only needs to be considered for type="text" or >> >> type="password" anyway. >> > That illustrates just how old that spec is. >> >> No, if it illustrates anything then that it is the lowest common >> denominator, the target for achieving interoperability. > > All I am saying is that you could optionally allow non-standard > attributes. By which you would be running the risk of losing interoperability, though. >> > It was just the starting point. Obviously if you ignored tab index for >> > all but text and password inputs today, you would miss a lot of >> > significant information. >> >> Not information significant to interoperability, which was the point of >> the whole exercise. > > Wrong. See above. You are wrong. >> >> As for the latter, if one were to avoid the attribute specification, >> >> when in doubt hasAttribute() or getAttribute() can be called for >> >> comparison. >> >> > Not sure what you mean about avoiding the attribute specification. >> >> It means not serializing an attribute property and its value into >> `attribute="value"' because it would not make a difference. > > Still not clear what you mean. Read the Specification, then. I cannot be more clear. >> > As for hasAttribute, that was introduced by MS in IE8 (standards mode >> > only). And, as I hope we all know by _now_ (two years since this >> > subject was brought up and beaten to death), get/set/removeAttribute >> > are all screwy in IE < 8 (and IE8 compatibility mode). >> >> So "screwy" that you cannot use it to differentiate whether the attribute >> was specified or not? I doubt it. > > You better believe it. And if you don't, that explains your > "position" on this. I had to see it for myself with the form serialization already. >> >> >> Granted, that is not the same as `innerHTML'; it is a lot better. >> >> > Depends on the context. It wouldn't be better for the examples I >> >> > listed. >> >> >> >> Unfortunately, your "examples" are too general to be useful in a >> >> discussion. >> > >> > That's your opinion. >> >> Which should be relevant to you as you are discussing this with me. >> Unless your purpose here is just to state something and to hell with the >> contradictions. > > Your assertion about "general examples" has no technical meaning. Your examples are so general (if they qualify as examples at all) that they have no meaning at all. That is the problem. >> >> You argument is too general to be useful, again. >> > I don't see that at all. >> >> Well, you are talking rather nebulously about potential problems. Why >> not take this opportunity to name some of the perceived problems >> explicitly and concisely instead, to support your argument? > > As you mentioned, you are way behind on this. Catch up and your > questions will have been answered. So far, with Valid markup, there is *one* buggy implementation (MSHTML) only for which *some* approaches do not work as one would expect in *some* versions of it, whereas the latter waits to be proved. >> >> >> > Then there are these silly CSS selector query engines, which have >> >> >> > become a ludicrous standard fixture for "Real World" Web apps. A >> >> >> > lot of them use XPath. >> >> >> XPath does not work with HTML in MSHTML, >> >> > Exactly. >> >> >> and in Gecko & friends I can use >> >> >> the native XPath implemenation. >> >> > Right. >> >> >> I do not see your point. >> >> > You just reinforced it. :) Have you ever written a CSS selector >> >> > query? >> >> No. >> > Well, then perhaps you haven't considered what goes into it. Think >> > about it. >> I am growing tired of your commonplace arguments. > > There's that word again. Look it up. >> That said, I would not even attempt using XPath in IE except for XHTML >> served as text/xml or application/xml where there is a native >> implementation. > > Of course you wouldn't attempt to use XPath with MSHTML (for an HTML > DOM). Yes, if an XML DOM, I would have said MSXML. > That's why you would have to write an equivalent script. And > that requires... No, I mean I would not *use* XPath with MSHTML. The notation, not the DOM feature. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 19 Dec 2009 10:58
On Dec 19, 1:00 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> David Mark wrote: > >> >> > Thomas 'PointedEars' Lahn wrote: > >> >> >> David Mark wrote: > >> >> >> > Thomas 'PointedEars' Lahn wrote: > >> >> >> >> David Mark wrote: > >> >> >> >> >> > That's why you can't use properties - for example - to > >> >> >> >> >> > write an innerHTML emulation. > >> >> >> >> >> Yes, you can. > >> >> >> >> > A pretty crappy one. :( > >> >> >> >> How so? > >> >> >> > Would be full of DOM defaults, user input, > >> >> >> No. > >> >> > No? How would you know which are defaults? > >> >> From the specifications. > >> > I see. Unfortunately, some browser developers (e.g. MS) don't see the > >> > specifications as firm rules. > >> One can determine which default values of attribute properties are > >> necessary to include in the serialization and which are not. > > > You don't know _which_ property values are defaults. For instance, > > maxlength has a default of some very large number in MSHTML. > > I have to see it before I believe it. Is that supposed to be some sort of sick joke? If not, the debugger is your friend. :) Or you could check here:- http://www.cinsoft.net/attributes.html "Fail: Input maximum length: 2147483647 is not null" > > > And this:- > > > <a href="..." tabindex="0"> > > > ...is not the same as this:- > > > <a href="..."> > > Yes, it is. Not even close. I explained why. > > > ...and no, you cannot just go with the latter. :) > > Yes, you can. The HTML 4.01 Specification is very clear about this. If > only one browser or whatever that is not Firefox/Iceweasel 3.5.6 (where I > have confirmed the Specification regarding this) differs here, then this > behavior would be a bug that does not need to be considered for an > `innerHTML' replacement that wants to be interoperable. IOW, the attribute > specification in question should not have been in the document in the first > place, so it can be safely omitted. Depends on your definition of "interoperable". :) > > > > >> >> >> > resolved paths, > >> >> >> So what? > >> >> > So, it's not the markup you are trying to serialize. > > >> >> Not exactly, that is correct. Like innerHTML, the innerHTML > >> >> replacement implementation only needs to provide something that > >> >> resembles the original markup enough for it to work; in the case of > >> >> the replacement that means that it needs to be consistent in one user > >> >> agent, and interoperable among user agents if possible. > > >> > Interoperability through consistency is the point. > > >> However, this contradicts your requirement that there would need to be a > >> bijection between the element object and the serialization of it. > > > You are very confused (and not making sense at all) Bijection? > > Try a (mathematical) dictionary. Or Wikipedia. No thanks. You have to communicate your point more clearly. > > > > >> >> `innerHTML' does not give "a clear view of the underlying document" > >> >> either. > >> > That's the point. My example is a replacement that does. As > >> > mentioned, if the innerHTML were standardized to the point of > >> > interoperability, this would be a moot point. > > >> >> But it does not need to nor would it appear that it was supposed to.. > > >> > See directly above. > > >> Still nobody needs that. > > > Those who would rely on CSS selector queries would certainly need it. > > Same for an editor that must save its results. > > > And you said yourself that you would "refer" to hasAttribute and > > getAttribute, when in "doubt". How would you do that if those methods > > are missing or broken? :) > > I think you are citing me out of context. But I see your point here. Okay. > > >> >> Obviously [maxLength < 0 or maxLength == 0] does not make sense so > >> >> it can be safely ignored for serialization. > >> [...] > > > Regardless, the default is some huge integer in MSHTML. > > Starting with which version, on which element types? Not in 6.0.2800.1106 > for `A' and INPUT elements, the default value is 0 there. See above. And this attribute is just one example. > > > Will you throw out every value that is either very large or negative? :) > > It *might* be necessary to check the attribute specification > (attribute=value); however, if the default value is such a large value, and > there are different large default values on other elements in the same > document that correspond with their relative position in the document > stream, it can be safely included. Maybe it would not be pretty, but it > would not be harmful either. > > >> > How do you figure a default tab index of 0 makes no > >> > sense? It makes perfect sense to me. > > >> Check your assumptions. tabIndex == 0 is the same as if the `tabindex' > >> attribute was not supported on an element or was not specified (omitted). Nope. Unsupported means tabIndex === undefined. That's a different story altogether. > > > Nope. You are dead wrong on that. Leaving it off will disallow > > tabbing to that element in some agents. > > So we have either a bug or not Valid markup here, evidently ("some") not to > be considered for an interoperable solution. Fairly recent versions of Opera? > > > And if it is not supported, the property value is typically undefined. > > So? !!undefined === false. What does that tell you? > > > Also, leaving it off - for example - a DIV will result in a default > > property value of -1 in some agents. You've got nothing to go on. > > DIV elements do not have a `tabindex' attribute in Valid (X)HTML. > > >> <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex> > > > Forms? It's not as if form elements are the only concern for > > tabindex. > > That does not matter. The other elements don't matter? > > >> >> Per HTML 4.01, it only needs to be considered for type="text" or > >> >> type="password" anyway. > >> > That illustrates just how old that spec is. > > >> No, if it illustrates anything then that it is the lowest common > >> denominator, the target for achieving interoperability. > > > All I am saying is that you could optionally allow non-standard > > attributes. > > By which you would be running the risk of losing interoperability, though.. Not really. Browsers throw out unrecognized attributes. > > >> > It was just the starting point. Obviously if you ignored tab index for > >> > all but text and password inputs today, you would miss a lot of > >> > significant information. > > >> Not information significant to interoperability, which was the point of > >> the whole exercise. > > > Wrong. See above. > > You are wrong. No I'm not. :) > > >> >> As for the latter, if one were to avoid the attribute specification, > >> >> when in doubt hasAttribute() or getAttribute() can be called for > >> >> comparison. > > >> > Not sure what you mean about avoiding the attribute specification. > > >> It means not serializing an attribute property and its value into > >> `attribute="value"' because it would not make a difference. > > > Still not clear what you mean. > > Read the Specification, then. I cannot be more clear. > > >> > As for hasAttribute, that was introduced by MS in IE8 (standards mode > >> > only). And, as I hope we all know by _now_ (two years since this > >> > subject was brought up and beaten to death), get/set/removeAttribute > >> > are all screwy in IE < 8 (and IE8 compatibility mode). > > >> So "screwy" that you cannot use it to differentiate whether the attribute > >> was specified or not? I doubt it. > > > You better believe it. And if you don't, that explains your > > "position" on this. > > I had to see it for myself with the form serialization already. What is this new-found reliance on empirical evidence? > > >> >> >> Granted, that is not the same as `innerHTML'; it is a lot better.. > >> >> > Depends on the context. It wouldn't be better for the examples I > >> >> > listed. > > >> >> Unfortunately, your "examples" are too general to be useful in a > >> >> discussion. > > >> > That's your opinion. > > >> Which should be relevant to you as you are discussing this with me. > >> Unless your purpose here is just to state something and to hell with the > >> contradictions. > > > Your assertion about "general examples" has no technical meaning. > > Your examples are so general (if they qualify as examples at all) that they > have no meaning at all. That is the problem. That's odd. The meaning hit home for you on one of them (form serialization) recently. You mentioned you don't do editors or queries, so it's not that odd that you don't understand what I'm talking about. > > >> >> You argument is too general to be useful, again. > >> > I don't see that at all. > > >> Well, you are talking rather nebulously about potential problems. Why > >> not take this opportunity to name some of the perceived problems > >> explicitly and concisely instead, to support your argument? > > > As you mentioned, you are way behind on this. Catch up and your > > questions will have been answered. > > So far, with Valid markup, there is *one* buggy implementation (MSHTML) only > for which *some* approaches do not work as one would expect in *some* > versions of it, whereas the latter waits to be proved. No, there is one completely Broken as Designed implementation, which can still rear its ugly head in IE8 (and is all you have in IE < 8). Then there are a lot of buggy implementations. > > > > >> >> >> > Then there are these silly CSS selector query engines, which have > >> >> >> > become a ludicrous standard fixture for "Real World" Web apps. A > >> >> >> > lot of them use XPath. > >> >> >> XPath does not work with HTML in MSHTML, > >> >> > Exactly. > >> >> >> and in Gecko & friends I can use > >> >> >> the native XPath implemenation. > >> >> > Right. > >> >> >> I do not see your point. > >> >> > You just reinforced it. :) Have you ever written a CSS selector > >> >> > query? > >> >> No. > >> > Well, then perhaps you haven't considered what goes into it. Think > >> > about it. > >> I am growing tired of your commonplace arguments. > > > There's that word again. > > Look it up. No, I don't think I will. > > >> That said, I would not even attempt using XPath in IE except for XHTML > >> served as text/xml or application/xml where there is a native > >> implementation. > > > Of course you wouldn't attempt to use XPath with MSHTML (for an HTML > > DOM). > > Yes, if an XML DOM, I would have said MSXML. And if you were trying to support both... > > > That's why you would have to write an equivalent script. And > > that requires... > > No, I mean I would not *use* XPath with MSHTML. The notation, not the DOM > feature. Whatever. You will not be able to - for example - query elements by attribute without something along those lines. |