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 29 Nov 2009 23:46 On Nov 29, 11:38 pm, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 29, 11:01 pm, kangax <kan...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 28, 10:05 pm, kangax <kan...(a)gmail.com> wrote: > >>>> David Mark wrote: > >>>>> On Nov 28, 9:03 pm, kangax <kan...(a)gmail.com> wrote: > >>>>>> David Mark wrote: > >> [...] > >>>>> up test for broken MSHTML DOM's put it on the right path. Either way, > >>>>> I'm quite pleased with the progress on the bizarre and ancient browser > >>>>> front. :) > >>>>>> Removed column span: '2' is not null > >>>>>> Input checked property set: false is not true > >>>>> The former likely means the Blackberry DOM can't remove that attribute > >>>>> (and probably others). > >>>>> Looking at the latter, I can see how that slipped through the net > >>>>> (never feature tested that the boolean properties were consistent in > >>>>> their reflections). > >>>>> 2 on the right (wrapped) and 30-something on the left (raw), right? > >>>> Yep. 23 on the left. 2 on the right. > >>> I think it should be down to the one now. ISTM that maybe Blackberry > >> Yep, just colspan one is left. I toyed with a minimal test case a little > >> and it looks like Blackberry does delete attribute after all. > > >> The reason test is failing is due to getAttribute('colspan') returning > >> an empty string instead of `null`. > > > Thanks! Will look into it. Would you tell me what the Notes section > > says (after first set, link at the top?) I am just curious. > > Cell span attributes bad > Okay, that should indicate the problem then. Thanks!
From: David Mark on 30 Nov 2009 02:54 On Nov 29, 11:46 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Nov 29, 11:38 pm, kangax <kan...(a)gmail.com> wrote: > > > > > David Mark wrote: > > > On Nov 29, 11:01 pm, kangax <kan...(a)gmail.com> wrote: > > >> David Mark wrote: > > >>> On Nov 28, 10:05 pm, kangax <kan...(a)gmail.com> wrote: > > >>>> David Mark wrote: > > >>>>> On Nov 28, 9:03 pm, kangax <kan...(a)gmail.com> wrote: > > >>>>>> David Mark wrote: > > >> [...] > > >>>>> up test for broken MSHTML DOM's put it on the right path. Either way, > > >>>>> I'm quite pleased with the progress on the bizarre and ancient browser > > >>>>> front. :) > > >>>>>> Removed column span: '2' is not null > > >>>>>> Input checked property set: false is not true > > >>>>> The former likely means the Blackberry DOM can't remove that attribute > > >>>>> (and probably others). > > >>>>> Looking at the latter, I can see how that slipped through the net > > >>>>> (never feature tested that the boolean properties were consistent in > > >>>>> their reflections). > > >>>>> 2 on the right (wrapped) and 30-something on the left (raw), right? > > >>>> Yep. 23 on the left. 2 on the right. > > >>> I think it should be down to the one now. ISTM that maybe Blackberry > > >> Yep, just colspan one is left. I toyed with a minimal test case a little > > >> and it looks like Blackberry does delete attribute after all. > > > >> The reason test is failing is due to getAttribute('colspan') returning > > >> an empty string instead of `null`. > > > > Thanks! Will look into it. Would you tell me what the Notes section > > > says (after first set, link at the top?) I am just curious. > > > Cell span attributes bad > > Okay, that should indicate the problem then. Thanks! Yeah, I think I see it. Based on feedback, I determined it was safe to merge the two quasi-standard forks and eliminate all but that one feature test, which not coincidentally relates to table cell spans. I provided an easier out for hasAttr for browsers that botch table cell attributes as well. That should do it. I will add some more unit tests when I get a chance. I'm sure there are more table-related attributes that should be considered for this workaround. I know it isn't all attributes that correspond to number properties as there is a test that removes the tabindex attribute. I'll probably end up testing all of the numeric table-related attributes and flagging for the GP workaround if one fails.
From: Thomas 'PointedEars' Lahn on 8 Dec 2009 17:07 Garrett Smith wrote: > [BlackBerry browser] has some really weird javascript bugs in it, some > very undesirable behavior with respect to DOM recalc (it skips many), but > has decent DOM support and pretty good support of ECMA-262 r3. That is a contradiction. No wait, two. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 15 Dec 2009 12:56 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. They represent the current value, not the value in the markup, where there is a corresponding attribute to begin with. > In the case of URI's, you get the full path (in all browsers). That's why > you can't use properties - for example - to write an innerHTML emulation. Yes, you can. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: David Mark on 15 Dec 2009 13:27
On Dec 15, 12:56 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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. That's where you need to call hasAttribute (or an emulation). 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. As we've seen on the test page, some browsers return unresolved URI's for some properties. I consider that a bug, though there is no formal spec that says so, as it only makes sense for the property to hold the resolved path (else how would you get it?) Most modern browsers do this for a.href anyway. Where they fail, the - prop - wrapper compensates (when possible). From the version that is up there now:- Known Exceptions * IE6/7 and IE8 compatibility mode return unresolved paths for the action, usemap, longdesc and link href attributes. I think I've added a few to that list. And BTW, in case you are curious, there's a typo in that test in the version up there now. There's a line that sets an href property of a dummy anchor, but in the test it is setting the wrong property. It's only working by coincidence, but I have tested without the coincidence locally. I should have the new version, which has a lot more tests and filters out user input (another source of distinction between properties and attributes) up soon. I think it will turn out to be a good test page for browser developers (especially the IE team). > > That's why > > you can't use properties - for example - to write an innerHTML emulation. > > Yes, you can. A pretty crappy one. :( But the realAttr (renamed attr now) wrapper will serialize a document without such contamination. |