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: Thomas 'PointedEars' Lahn on 15 Dec 2009 17:12 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > On Nov 25, 12:43 pm, kangax <kan...(a)gmail.com> wrote: >> >> David Mark wrote: >> >> > Yes, those are things that you might try. So, if you need all >> >> > attributes to be 100% consistent across all browsers, you've got to >> >> > have a lot of feature tests. Thankfully this is a (very) rare >> >> > design requirement. In an HTML DOM, the typical app has no need to >> >> > query, set or remove attributes "manually". That's what the DOM >> >> > properties are for. >> >> >> >> But properties are not "reliable" either in case of older Opera (URL >> >> values are always reported as absolute, independent of whether they >> >> are accessed as properties — `.src` — or attributes — >> >> `getAttribute('src')`, etc.) >> > >> > The DOM properties interpret the attribute values. >> >> DOM properties are separate from attribute values for the most part. > > I wouldn't say _most_ part. There is a lot of reflection. It varies, > so you have to test at least some cases. > >> They >> represent the current value, not the value in the markup, where there is >> a corresponding attribute to begin with. > > Setting properties creates attributes in many cases. If a script > creates a DIV:- > > var elDiv = document.createElement('div'); > div.id = 'test'; > > ...the resulting structure is:- > > <div id="test"></div> > > div.getAttribute('id') == 'test' > > The distinction is that many properties have _defaults_, so there is > no way to know if the attribute is there or not. True. But I do not need to know. > That's where you need to call hasAttribute (or an emulation). No. > A common case where this > is necessary is:- > > <option value="">Test</option> > > ...because the value property will vary cross-browser. What a > serialization function needs to get here is "", not "Test". > >> >> > In the case of URI's, you get the full path (in all browsers). > > This must be an old post. Yes, I am trying hard to keep up with you ;-) > As we've seen on the test page, some browsers return unresolved URI's for > some properties. There is no such thing as an "unresolved URI". There are URIs (e.g. schema://host/path?query#fragment) and there are URI-references (e.g. path?query#fragment). See also RFC 3986, which obsoletes RFC 2396 as referred in W3C DOM Level 2 HTML. > I consider that a bug, though there is no formal spec that says so, But there is. You can find "URI" everywhere in <http://www.w3.org/TR/DOM-Level-2-HTML/html.html> sometimes strengthened by the word "absolute". You will find no occurence whatsoever of "URI-reference". > as it only makes sense for the property to hold the resolved path (else > how would you get it?) Using the proprietary `location' property, I presume. And yes, it is a bug for an otherwise conforming implementation not to yield a URI there. > Most modern browsers do this for a.href anyway. Where they > fail, the - prop - wrapper compensates (when possible). ACK >> > That's why you can't use properties - for example - to write an >> > innerHTML emulation. >> >> Yes, you can. > > A pretty crappy one. :( How so? > But the realAttr (renamed attr now) wrapper > will serialize a document without such contamination. Hmmm. Is it not more reasonable to assume that if an attribute property has been feature-tested to exist and has the default value the corresponding attribute specification does not need to be part of the serialized version at all? 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 15 Dec 2009 21:56 On Dec 15, 5:12 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > On Nov 25, 12:43 pm, kangax <kan...(a)gmail.com> wrote: > >> >> David Mark wrote: > >> >> > Yes, those are things that you might try. So, if you need all > >> >> > attributes to be 100% consistent across all browsers, you've got to > >> >> > have a lot of feature tests. Thankfully this is a (very) rare > >> >> > design requirement. In an HTML DOM, the typical app has no need to > >> >> > query, set or remove attributes "manually". That's what the DOM > >> >> > properties are for. > > >> >> But properties are not "reliable" either in case of older Opera (URL > >> >> values are always reported as absolute, independent of whether they > >> >> are accessed as properties `.src` or attributes > >> >> `getAttribute('src')`, etc.) > > >> > The DOM properties interpret the attribute values. > > >> DOM properties are separate from attribute values for the most part. > > > I wouldn't say _most_ part. There is a lot of reflection. It varies, > > so you have to test at least some cases. > > >> They > >> represent the current value, not the value in the markup, where there is > >> a corresponding attribute to begin with. > > > Setting properties creates attributes in many cases. If a script > > creates a DIV:- > > > var elDiv = document.createElement('div'); > > div.id = 'test'; > > > ...the resulting structure is:- > > > <div id="test"></div> > > > div.getAttribute('id') == 'test' > > > The distinction is that many properties have _defaults_, so there is > > no way to know if the attribute is there or not. > > True. But I do not need to know. Depends on what you are trying to do. > > > That's where you need to call hasAttribute (or an emulation). > > No. Did you read the example below? > > > A common case where this > > is necessary is:- > > > <option value="">Test</option> > > > ...because the value property will vary cross-browser. What a > > serialization function needs to get here is "", not "Test". That's what I'm talking about. > > >> > In the case of URI's, you get the full path (in all browsers). > > > This must be an old post. > > Yes, I am trying hard to keep up with you ;-) > > > As we've seen on the test page, some browsers return unresolved URI's for > > some properties. > > There is no such thing as an "unresolved URI". There are URIs (e.g. > schema://host/path?query#fragment) and there are URI-references (e.g. > path?query#fragment). See also RFC 3986, which obsoletes RFC 2396 as > referred in W3C DOM Level 2 HTML. > > > I consider that a bug, though there is no formal spec that says so, > > But there is. You can find "URI" everywhere in > > <http://www.w3.org/TR/DOM-Level-2-HTML/html.html> > > sometimes strengthened by the word "absolute". You will find no occurence > whatsoever of "URI-reference". Somewhere in this thread, it was asserted that the spec left all but a.href open to interpretation. > > > as it only makes sense for the property to hold the resolved path (else > > how would you get it?) > > Using the proprietary `location' property, I presume. And yes, it is a bug > for an otherwise conforming implementation not to yield a URI there. > > > Most modern browsers do this for a.href anyway. Where they > > fail, the - prop - wrapper compensates (when possible). > > ACK > > >> > 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, resolved paths, etc., so it would vary wildly from one browser to the next and would never give a clear view of the underlying document. > > > But the realAttr (renamed attr now) wrapper > > will serialize a document without such contamination. > > Hmmm. Is it not more reasonable to assume that if an attribute property has > been feature-tested to exist and has the default value the corresponding > attribute specification does not need to be part of the serialized version > at all? But generally you have no way of knowing what the default is. 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> What would you do with such a novelty? 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. These details matter for a number of applications (though they should not for a basic Web app). A basic (consistent) innerHTML emulation is the first thing that comes to mind. Serialization of edited HTML is another. 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). 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. Some purport to support both HTML and XML DOM's. 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).
From: Thomas 'PointedEars' Lahn on 16 Dec 2009 02:34 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > As we've seen on the test page, some browsers return unresolved URI's >> > for some properties. >> >> There is no such thing as an "unresolved URI". There are URIs (e.g. >> schema://host/path?query#fragment) and there are URI-references (e.g. >> path?query#fragment). See also RFC 3986, which obsoletes RFC 2396 as >> referred in W3C DOM Level 2 HTML. >> >> > I consider that a bug, though there is no formal spec that says so, >> >> But there is. You can find "URI" everywhere in >> >> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html> >> >> sometimes strengthened by the word "absolute". You will find no >> occurence whatsoever of "URI-reference". > > Somewhere in this thread, it was asserted that the spec left all but > a.href open to interpretation. Then that assertion was wrong. A URI is not a URI-reference. Read RFC 3986 (or the referred 2396, for that matter). >> >> > 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. > resolved paths, So what? > 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. >> > But the realAttr (renamed attr now) wrapper >> > will serialize a document without such contamination. >> >> Hmmm. Is it not more reasonable to assume that if an attribute property >> has been feature-tested to exist and has the default value the >> corresponding attribute specification does not need to be part of the >> serialized version at all? > > But generally you have no way of knowing what the default is. 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> > > 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. 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. Granted, that is not the same as `innerHTML'; it is a lot better. > 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. > These details matter for a number of applications (though they should > not for a basic Web app). Exactly, they should not. > 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? > Serialization of edited HTML is another. I do not see your point. > 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? > 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, and in Gecko & friends I can use the native XPath implemenation. I do not see your point. > Some purport to support both HTML and XML DOM's. So what? > 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. 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 16 Dec 2009 10:52 On Dec 16, 2:34 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > As we've seen on the test page, some browsers return unresolved URI's > >> > for some properties. > > >> There is no such thing as an "unresolved URI". There are URIs (e.g. > >> schema://host/path?query#fragment) and there are URI-references (e.g. > >> path?query#fragment). See also RFC 3986, which obsoletes RFC 2396 as > >> referred in W3C DOM Level 2 HTML. > > >> > I consider that a bug, though there is no formal spec that says so, > > >> But there is. You can find "URI" everywhere in > > >> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html> > > >> sometimes strengthened by the word "absolute". You will find no > >> occurence whatsoever of "URI-reference". > > > Somewhere in this thread, it was asserted that the spec left all but > > a.href open to interpretation. > > Then that assertion was wrong. A URI is not a URI-reference. Read RFC 3986 > (or the referred 2396, for that matter). Then the spec agrees with my original opinion that they should all resolve to URI's. Garrett said it was only specified for a.href. > > >> >> > 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? > > > resolved paths, > > So what? So, it's not the markup you are trying to serialize. > > > 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? > > > > >> > But the realAttr (renamed attr now) wrapper > >> > will serialize a document without such contamination. > > >> Hmmm. Is it not more reasonable to assume that if an attribute property > >> has been feature-tested to exist and has the default value the > >> corresponding attribute specification does not need to be part of the > >> serialized version at all? > > > But generally you have no way of knowing what the default is. 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. > 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. > 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. > > > 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. Best to test (and fix) only the features you need. However I've listed a few examples where you would need the whole thing. > > > 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. > > > 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. > > > Serialization of edited HTML is another. > > I do not see your point. Have you ever written an 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. If the host innerHTML properties were 100% consistent and standardized, there would be no need for such a solution. > > > 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? If not, think about what you use XPath for in Gecko and imagine what you would need to do to duplicate it in IE. > > > Some purport to support both HTML and XML DOM's. > > So what? So, you seem lost. > > > 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.
From: Thomas 'PointedEars' Lahn on 16 Dec 2009 11:45
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. >> > 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. >> > 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. But it does not need to nor would it appear that it was supposed to. >> > [...] 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. Obviously the former (or the value 0) does not make sense so it can be safely ignored for serialization. Per HTML 4.01, it only needs to be considered for type="text" or type="password" anyway. As for the latter, if one were to avoid the attribute specification, when in doubt hasAttribute() or getAttribute() can be called for comparison. >> 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. >> 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. >> > 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. If you want to prove something, prove it here. If you do not want to repeat yourself too much, you can support the argument with a Message-ID to one of your postings. > 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. >> > 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. You argument is too general to be useful, again. >> > 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. Those two Specifications are the lowest common denominator. >> > 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. >> > 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. > If the host innerHTML properties were 100% consistent and standardized, > there would be no need for such a solution. Correct, but useless. >> > 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. > 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. > and imagine what you would need to do to duplicate it in IE. This is not a guessing game. Get to the point, please. >> > Some purport to support both HTML and XML DOM's. >> So what? > > So, you seem lost. Likewise. >> > 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? And try to keep your quotes short, would you, please? PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.) |