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: kangax on 28 Nov 2009 22:05 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 28 Nov 2009 22:30 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 28 Nov 2009 23:35 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 29 Nov 2009 01:24 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 | +--------------+------------+ | & | & | | tab literal | 	 | | CRLF literal | | | ' | ' | | » | » | +--------------+------------+ 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 ' 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 29 Nov 2009 01:57
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 | > +--------------+------------+ > | & | & | > | tab literal | 	 | > | CRLF literal | | > | ' | ' | > | » | » | > +--------------+------------+ > > 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 ' > > 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. |