Microsoft and attributes--will they ever figure them out? [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 04:10

On Nov 29, 1:24 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Eric Bednarz wrote:
> > Garrett Smith <dhtmlkitc...(a)gmail.com> writes:
>
> >> Attribute value is whatever is in the source code,
>
> > Since there are numerous people posting to this group who appear to
> > think that SGML validation is a relevant tool for HTML QA, I am
> > delighted to say that you are wrong about that. :-)
>
> Good point. In fact, I distinctly remember an angry situation with URLs
> containing literal ^ (unencoded %5E), somebody's unwillingness to fix
> the URLs' generator, and HTML 4.01 Appendix B.2.
>
> As it turns out, many browsers do not follow HTML 4.01 Appendix B.2
> completely, and will not encode ^. Safari 4 for windows does (or did).
>
> > In the source code of HTML documents, at least are attribute value
> > *literals*.
>
> Thank you for bringing this point up.
>
> The implication of this is outerHTML cannot be used directly for reading
> attribute values. It could be used intermediately, to first get the
> value, then set textContent of an element to that value, then get the
> innerText of the element read. Hackery.
>

Oh, I missed this part. The outerHTML property is used (when
possible) in broken MSHTML implementations (and those that would mimic
them) to determine if attributes _exist_. That property is not used
to read attributes at all. So your worries are of no consequence to
the example at hand. I think you'll find the viewport example to be
the same case. ;)

From: kangax on 29 Nov 2009 23:01

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`.

A test case was:

<table>
<tbody>
<tr><td colspan="2" id="testee"></td></tr>
</tbody>
</table>

<script type="text/javascript">
(function(){
var el = document.getElementById('testee');
el.removeAttribute('colspan');
document.write(
el.parentNode.innerHTML
.replace(/</g, '<').replace(/>/g, '>'));
document.write('<br>' + el.hasAttribute('colspan'));
document.write('<br>' + (el.getAttribute('colspan') === ''));
})();
</script>

and it resulted in:

<TD id="testee"></TD>
false
true

[...]

--
kangax

From: David Mark on 29 Nov 2009 23:17

From: kangax on 29 Nov 2009 23:38

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

48 tests, 23 failure(s), 0 skip(s)

--
kangax

From: David Mark on 29 Nov 2009 23:44

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`.
>
> A test case was:
>
> <table>
> <tbody>
> <tr><td colspan="2" id="testee"></td></tr>
> </tbody>
> </table>
>
> <script type="text/javascript">
> (function(){
> var el = document.getElementById('testee');
> el.removeAttribute('colspan');
> document.write(
> el.parentNode.innerHTML
> .replace(/</g, '<').replace(/>/g, '>'));
> document.write('<br>' + el.hasAttribute('colspan'));
> document.write('<br>' + (el.getAttribute('colspan') === ''));
> })();
> </script>
>
> and it resulted in:
>
> <TD id="testee"></TD>
> false
> true
>
> [...]

Yes, there are several attributes in odd browsers that fail in this
way. This is a typical feature test that is likely related to this
last quirk in Blackberry:-

var cellSpanAttributesBad = (function() {
var el = doc.createElement('td');
return el.getAttribute('colspan') !== null;
})();

After reducing the equations, outside of broken MSHTML
implementations, there are two forks that are nearly identical. The
difference is in when they use hasAttr to guard against unreliable
getAttribute results. Let me know if the above flag is mentioned in
the first notes section. ISTM it should be there as the only
difference in your test is that you removed the attribute (and the
tested element is in the document). But if that flag is set, the
workaround should be happening.

Need to make the feature testing a little more specific to merge (or
diverge) the two forks.

Thanks again for your help on this. If you are curious, there are two
more sets of tests that deal with DOM properties.