From: kangax on
David Mark wrote:
> On Nov 28, 9:03 pm, kangax <kan...(a)gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 25, 12:42 pm, kangax <kan...(a)gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> [...]
>>>>>> To run Blackberry Simulator, you need Email and MDS and then one or more
>>>>>> Simulators.
>>>>>> https://www.blackberry.com/Downloads/
>>>>> Page not found. :( I would like to see the results posted for this
>>>>> device.
>>>> Which results?
>>> Whatever was "document.written" at the time you ran it. You reported
>>> 20-something errors, but didn't say if that total was for both sets of
>>> tests (I assume it was). I'm curious about which tests failed as
>>> well. So far I've been able to smooth out the kinks in every tested
>>> browser (other than file URI's of course).
>> I get 2 errors now (on 9530).
>
> That means either some of the same quirks found in the old Opera
> versions were also present in Blackberry or (less likely) the beefed

Yet another proof of proper feature testing taking care of "bug
copying". There's an ubiquitous Opera/IE similarities; I found some of
the IE -like innerHTML bugs in Konqueror recently; and now Blackberry.

If only more people would understand this.

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

>
> Thanks for your help!

No problem.

--
kangax
From: David Mark on
On Nov 28, 9:03 pm, kangax <kan...(a)gmail.com> wrote:
> David Mark wrote:
> > On Nov 25, 12:42 pm, kangax <kan...(a)gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> [...]
> >>>> To run Blackberry Simulator, you need Email and MDS and then one or more
> >>>> Simulators.
> >>>>https://www.blackberry.com/Downloads/
> >>> Page not found.  :(  I would like to see the results posted for this
> >>> device.
> >> Which results?
>
> > Whatever was "document.written" at the time you ran it.  You reported
> > 20-something errors, but didn't say if that total was for both sets of
> > tests (I assume it was).  I'm curious about which tests failed as
> > well.  So far I've been able to smooth out the kinks in every tested
> > browser (other than file URI's of course).
>
> I get 2 errors now (on 9530).
>
> Removed column span: '2' is not null
> Input checked property set: false is not true

I see that the feature test I added for IE8-ish boolean woes was
checked in the getter, but not the setter in one fork. Oops. I
strongly suspect Blackberry was taking that fork and that should
account for the second one. Odd that only the checked property had a
problem as there are a few other tests with similar attribute sets and
boolean property checks. Should work now.

I also suspect that like the relative/absolute file URI issues (1 in
Opera 9.27, 6 in Opera 9.27), the first one is broken beyond repair on
Blackberry. Those two issues seem worthy of flagging externally (apps
may need them or not).

I need to add some better reporting (i.e. the state of the internal
flags) so I don't have to guess about the results as much. But it's
worked pretty well so far. ;)

ISTM that a CSS selector query engine needs to start with a foundation
like this. Likewise apps with exacting parsing requirements. Editors
and apps that need a consistent innerHTML interface would need such
wrappers for any semblance of cross-browser compatibility.

But virtually everyone else can do without them, perhaps using
individual tests (like those on the test page) on the rare occasion
that direct attribute manipulation is needed (DOM properties usually
suffice).

>
>
>
> > I downloaded a simulator recently, but didn't see immediately how to
> > do anything useful with it (it did hog my resources quite a bit to
> > show a picture of a phone though).  I'll have to give that another go
> > some time.
>
> I know. That simulator is a PITA to set up. Good luck ;)
>

I got it set up, but it didn't do anything impressive. :(
From: David Mark on
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:
> >>> On Nov 25, 12:42 pm, kangax <kan...(a)gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >> [...]
> >>>>>> To run Blackberry Simulator, you need Email and MDS and then one or more
> >>>>>> Simulators.
> >>>>>>https://www.blackberry.com/Downloads/
> >>>>> Page not found.  :(  I would like to see the results posted for this
> >>>>> device.
> >>>> Which results?
> >>> Whatever was "document.written" at the time you ran it.  You reported
> >>> 20-something errors, but didn't say if that total was for both sets of
> >>> tests (I assume it was).  I'm curious about which tests failed as
> >>> well.  So far I've been able to smooth out the kinks in every tested
> >>> browser (other than file URI's of course).
> >> I get 2 errors now (on 9530).
>
> > That means either some of the same quirks found in the old Opera
> > versions were also present in Blackberry or (less likely) the beefed
>
> Yet another proof of proper feature testing taking care of "bug
> copying".

Yes, and and testing features directly and with a plan (e.g. having
some idea what to expect, which allows the results of the tests to be
correctly analyzed).

> There's an ubiquitous Opera/IE similarities; I found some of
> the IE -like innerHTML bugs in Konqueror recently; and now Blackberry.

I bet. :)

>
> If only more people would understand this.

It's coming. The days of testing for !navigator.userAgent.indexOf
('Opera') are clearly over. That strategy was always aimed at trying
to keep up with the (seemingly impossible) present, never mind the
future. For cross-browser (or even multi-browser) scripting 2000-2005
was hell on earth compared to the last five years, so it is easy to
see how the browser sniffing craze gained so much momentum at the
start and is slowly petering out at the end of the decade. If only
more people had read the FAQ notes. ;)

>
> > 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
won't allow the removal of a colspan attribute at all. That would be
an extreme use case anyway, so I'll just flag it (in case an app must
rely on colspan removal). Have to figure rowspan has the same problem
too. It would be more apparent if I made the test table visible. :)

And I added a notes section after the first set of tests to make it
easier to interpret results.

Thanks again!
From: Garrett Smith on
Eric Bednarz wrote:
> Garrett Smith <dhtmlkitchen(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.

Entities in outerHTML may be resolved or they may be unresolved.
Seems IE chooses a mix of the two, plus entitification of various other
characters:

IE6-IE8:
+--------------+------------+
| Source Code | outerHTML |
+--------------+------------+
| &amp; | &amp; |
| tab literal | &#9; |
| CRLF literal | &#13;&#10; |
| &#39; | ' |
| &raquo; | » |
+--------------+------------+

The results in the table show that some entities are resolved while
others are not, and that some literal characters result in creation of
entities where none occurred.

Persuing a comprehensive way to read attribute values (like realAttr)
seems not worth the effort. Testing various encodings, all entities,
etc, sounds like a tremendous effort.

IE8 still does not support &apos;

My next table is going to be a list of clientHeight clientWidth for
documentElement and body in quirks mode and standards mode. I will test
tall, wide documents and short, narrow documents.

This will require the creation of many documents and a considerable
amount of time.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
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.
>
> Entities in outerHTML may be resolved or they may be unresolved.
> Seems IE chooses a mix of the two, plus entitification of various other
> characters:
>
> IE6-IE8:
> +--------------+------------+
> | Source Code  | outerHTML  |
> +--------------+------------+
> | &amp;        | &amp;      |
> | tab literal  | &#9;       |
> | CRLF literal | &#13;&#10; |
> | &#39;        | '          |
> | &raquo;      | »          |
> +--------------+------------+
>
> The results in the table show that some entities are resolved while
> others are not, and that some literal characters result in creation of
> entities where none occurred.
>
> Persuing a comprehensive way to read attribute values (like realAttr)
> seems not worth the effort. Testing various encodings, all entities,
> etc, sounds like a tremendous effort.
>
> IE8 still does not support &apos;
>
> My next table is going to be a list of clientHeight clientWidth for
> documentElement and body in quirks mode and standards mode. I will test
> tall, wide documents and short, narrow documents.

Don't forget borders on the body. ;) But I think you are wasting
your time.

>
> This will require the creation of many documents and a considerable
> amount of time.

So why bother? There's already a test for it. Why not try the test
page from the FAQ 9.3 thread in something other than the browsers
already tested? I really think it is close to perfect on the
measurement at this point and am going to update with scroll position
reporting (and setting) shortly.