Microsoft and attributes--will they ever figure them out?
David Mark
attributes, I put together a set of tests. Two sets, actually:-
http://www.cinsoft.net/attributes.html
One calls get/removeAttribute methods assuming they work consistently
across all browsers (a common strategy). Results are almost exactly
as expected. All green in modern standards-based browsers tested
(e.g. Chrome, FF3.5.) Mostly green in IE8 standards mode (yes,
they've _still_ got some mistakes in there). Put IE8 in
"compatibility view" and all hell breaks loose (all but three tests
fail).
Out of further curiosity, I added a second set of the same tests using
wrapper functions and a feature test proposed here two years ago. All
is exactly the same, except that now IE8 compatibility mode passes all
but one test (enctype). I believe IE6/7 will pass all of them as
there is a workaround in there for that attribute.
The moral is to avoid these methods whenever possible (virtually
always). Calling them outside of a suitable wrapper is surefire
disaster as users can affect the behavior of these methods with a
toolbar button in IE8 (and what a silly button that is).
When might these methods be handy? CSS selector queries (if you find
them useful), parsing/serializing markup and XML elements (e.g SVG)
come to mind. Not a lot else.
But in the "real world", virtually every jQuery example uses its attr
method, which calls get/setAttribute, etc. The big problem is that
the people reading (and writing) these examples are taking it on blind
faith that the jQuery authors understand these issues (they clearly do
not). Maybe a nice picture will finally drive the point home. :)
David Mark
> Out of curiosity about Microsoft's newfound understanding of
> attributes, I put together a set of tests. Two sets, actually:-
[...]
Added a test for the broken IE8 attribute features (a test for one
anyway, with another workaround inferred). Of course, there may be
more (it was well into the century before all of the IE6/7 quirks
surfaced).
RobG
> Out of curiosity about Microsoft's newfound understanding of
> attributes, I put together a set of tests. Two sets, actually:-
>
> http://www.cinsoft.net/attributes.html
>
> One calls get/removeAttribute methods assuming they work consistently
> across all browsers (a common strategy). Results are almost exactly
> as expected. All green in modern standards-based browsers tested
> (e.g. Chrome, FF3.5.) Mostly green in IE8 standards mode (yes,
> they've _still_ got some mistakes in there). Put IE8 in
> "compatibility view" and all hell breaks loose (all but three tests
> fail).
If "compatible" means has the same number of failures, then yes, it's
compatible with my IE 6.
>
> Out of further curiosity, I added a second set of the same tests using
> wrapper functions and a feature test proposed here two years ago. All
> is exactly the same, except that now IE8 compatibility mode passes all
> but one test (enctype). I believe IE6/7 will pass all of them as
> there is a workaround in there for that attribute.
Nope, enctype still fails in IE 6. Will look into it further later.
--
Rob
David Mark
> On Nov 16, 2:34 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Out of curiosity about Microsoft's newfound understanding of
> > attributes, I put together a set of tests. Two sets, actually:-
>
> >http://www.cinsoft.net/attributes.html
>
> > One calls get/removeAttribute methods assuming they work consistently
> > across all browsers (a common strategy). Results are almost exactly
> > as expected. All green in modern standards-based browsers tested
> > (e.g. Chrome, FF3.5.) Mostly green in IE8 standards mode (yes,
> > they've _still_ got some mistakes in there). Put IE8 in
> > "compatibility view" and all hell breaks loose (all but three tests
> > fail).
>
> If "compatible" means has the same number of failures, then yes, it's
> compatible with my IE 6.
IIRC, 6 and 7 won't match exactly. May not have enough tests in there
to show that.
>
>
>
> > Out of further curiosity, I added a second set of the same tests using
> > wrapper functions and a feature test proposed here two years ago. All
> > is exactly the same, except that now IE8 compatibility mode passes all
> > but one test (enctype). I believe IE6/7 will pass all of them as
> > there is a workaround in there for that attribute.
>
> Nope, enctype still fails in IE 6. Will look into it further later.
D'oh! That one is really screwy. The attributes collection key is
actually 'encType' (though that is not the DOM property name and IIRC
that property is missing in IE6/7), but the specified flag is never
set. Apparently it doesn't show up in outerHTML either. Whatever.
I added a few more tests. Didn't budge the success tally for IE6/7/
compatibility mode. Of course, that doesn't matter unless you rely on
these methods to be consistent from one IE version (or mode) to the
next. :)
There are certainly lots of related tests that will pass. More than
will fail certainly, which explains a lot about how "major" libraries
could waste years working around these headaches, even as IE8 is
tested and launched with what amounts to a destruct button. You can
see in the test suites that evidence was gathered, but apparently
nobody spotted the pattern (which was mostly documented around the
turn of the century).
David Mark
Turns out only for the default enctype. The MSHTML parser ignores it
as superfluous. So that one is just a harmless irritation. Several
other mistakes in IE8 standards mode are not.
kangax
Those wrappers still fail in Opera 9.27 and 8.54 on Mac (7 and 29
failures respectively). Latest Blackberry (9500) has 23 failures. Are
those wrappers from "My Library"?
--
kangax
David Mark
Post the results. The wrapper is just a call to get/set/
removeAttribute in quasi-standards-based browsers, so the first set
(without wrappers) should match the second (with). If not, perhaps
Opera's attribute methods are broken too (in some slightly different
way than IE).
One caveat, I did add a few lines to fix IE8 standards problems (MS
still hasn't fixed the problem completely).
And yes and no. They originated in My Library, but then I moved them
to Dojo and made a few improvements (including some new feature
testing). What is up there now is just as I left it.
David Mark
Yes. Opera 9.27 has some broken attribute features (e.g. getAttribute
method). As expected, the two sets of tests have identical results.
I am sure these new quirks can be feature tested. The demo is getting
to be a bit of a mess with a couple of inferences (related to IE8
quirks) that need feature tests.
David Mark
It was almost a hole in one on 9.27.
There were two quirks in Opera's getAttribute. One was being feature
tested (cellSpanAttributesBad), but not caught as the feature test was
too narrow.
The other one was related to booleans (e.g. disabled) and was not a
bug (just an inconsistency), but the tests were too strict to let it
pass. I fixed that so that the results are consistent (new flag
added).
A bit messy and there are still a couple of inferences related to
IE8's quirks that need to be replaced with proper tests. Now I need
to transplant it back in to My Library.
One thing to keep in mind is that IE6/7 are broken beyond belief
without these wrappers. Other browsers (e.g. Opera 9.27) may be less
than 100% consistent, but still workable. It's the IE6/7 path (and
IE8 in compatibility mode) that has been ignored by the "major"
libraries (and most other scripts written in the last decade).
So, what about Opera 8.54? The results for that sound positively IE-
ish. Perhaps the net for the broken MSHTML DOM needs to be widened a
bit. Opera has been known to copy IE bugs (usually in quirks mode
though).
David Mark
As for Blackberry. I imagine its DOM implementation is broken too.
Again, I assume the left and right results are the same. The former
uses no wrappers at all, calling the DOM methods directly. I'd be
very interested to see these results.
Thanks again!
David Mark
Tried Opera 8.54 on Windows. It is down to four failures (all file
paths) after the tests were added to make 9.27 consistent. The file
paths are irritating. Looks like Opera 8.54 always gives the full
path, regardless of the specified attribute value. Those are easy
enough to test, but not worth trying to fix IMO.
These unit tests is they are good feature tests as well. If you know
which attributes your design must manipulate and how it must
manipulate them, you know exactly what to test. That's the best
strategy (not a general purpose wrapper).
kangax
> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Yes. Opera 9.27 has some broken attribute features (e.g. getAttribute
>> method). As expected, the two sets of tests have identical results.
>> I am sure these new quirks can be feature tested. The demo is getting
>> to be a bit of a mess with a couple of inferences (related to IE8
>> quirks) that need feature tests.
>
> It was almost a hole in one on 9.27.
>
> There were two quirks in Opera's getAttribute. One was being feature
> tested (cellSpanAttributesBad), but not caught as the feature test was
> too narrow.
>
> The other one was related to booleans (e.g. disabled) and was not a
> bug (just an inconsistency), but the tests were too strict to let it
> pass. I fixed that so that the results are consistent (new flag
> added).
Checked 9.27 again. Only one failure � "Form action:
'http://www.cinsoft.net/images/cinsoft.gif' is not 'images/cinsoft.gif'"
8.54 now has 4 failures. The action one (as in 9.27) and 3 more similar
MSHTML-isms where relative urls are reported as absolute:
Link reference: 'http://www.cinsoft.net/images/cinsoft.gif' is not
'images/cinsoft.gif'
Image source: 'http://www.cinsoft.net/images/cinsoft.gif' is not
'images/cinsoft.gif'
Image long description: 'http://www.cinsoft.net/images/cinsoft.gif' is
not 'images/cinsoft.gif'
Image long description: 'http://www.cinsoft.net/images/cinsoft.gif' is
not 'images/cinsoft.gif'
Passing "2" flag to getAttribute doesn't seem to help.
`getAttributeNode(...).value` and `attributes[...].value` report
absolute values as well.
[...]
--
kangax
David Mark
> David Mark wrote:
> > On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
> [...]
> >> Yes. Opera 9.27 has some broken attribute features (e.g. getAttribute
> >> method). As expected, the two sets of tests have identical results.
> >> I am sure these new quirks can be feature tested. The demo is getting
> >> to be a bit of a mess with a couple of inferences (related to IE8
> >> quirks) that need feature tests.
>
> > It was almost a hole in one on 9.27.
>
> > There were two quirks in Opera's getAttribute. One was being feature
> > tested (cellSpanAttributesBad), but not caught as the feature test was
> > too narrow.
>
> > The other one was related to booleans (e.g. disabled) and was not a
> > bug (just an inconsistency), but the tests were too strict to let it
> > pass. I fixed that so that the results are consistent (new flag
> > added).
>
> 'http://www.cinsoft.net/images/cinsoft.gif'is not 'images/cinsoft.gif'"
>
> 8.54 now has 4 failures. The action one (as in 9.27) and 3 more similar
> MSHTML-isms where relative urls are reported as absolute:
Yes, that's what I show here. Opera fixed most of their URI bugs
between 8.54 and 9.27.
>
> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'is not
> 'images/cinsoft.gif'
> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'is not
> 'images/cinsoft.gif'
> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> not 'images/cinsoft.gif'
> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> not 'images/cinsoft.gif'
>
> Passing "2" flag to getAttribute doesn't seem to help.
> `getAttributeNode(...).value` and `attributes[...].value` report
> absolute values as well.
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.
An example would be a CSS selector query engine. That's one reason
why those are ever-shifting bad ideas. With the "major" libraries,
virtually every time a new browser comes out, their unit tests break
(assuming they have anywhere near enough tests and know how to
interpret them). In the minds of the authors, this invalidates the
old browsers rather than their backwards design decision to hang
everything on attributes. So they just "degrade" the old browser on
paper (browser grading), rather than in the code. :(
Those grading charts must be of great comfort to the end users who are
stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in
that Blackberry of yours (NetFront?) When a site breaks due to an
upgraded library and the user bothers to inform the developers (a
rarity), are they given a link to the chart as proof that it is
_their_ fault for not upgrading their browser in time for this new
library script?
You might ask what to do if one or more of the feature tests for your
attribute-dependent application breaks. The answer is that you do not
define the wrappers at all in that case. Your app's gateway would
look something like this:-
if (API.realAttr && API.removeAttr) {
...
}
...then as you figure out how to deal with odd browsers inside the
wrappers, the app keeps up without modification (and is oblivious to
the encapsulated quirks).
So, as usual, GP is a bad way to go. Your app may only need to deal
with certain attributes (e.g. it may not care about URI form) and
those are the only ones it should test. Or you can go the "major
library" route and break browsers you never tested (or heard of) for
no reason. ;)
Garrett Smith
> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> [...]
> Those grading charts must be of great comfort to the end users who are
> stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in
> that Blackberry of yours (NetFront?)
Blackberry browser is default browser for Blackberry device. It is a
totally unique browser with its own rendering engine.
Javascript is turned off, by default. Older versions of Blackberry
shipped with CSS off by default.
It 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.
The most interesting ECMAScript bug was recently found in Blackberry.
The bug? Activation/Variable object has a [[Prototype]].
I added a link in the FAQ some time back to Blackberry Browser
JavaScript Reference:
http://jibbering.com/faq/#browserResources
The Blackberry device is Java, so Opera Mini would be an option for that
device.
To run Blackberry Simulator, you need Email and MDS and then one or more
Simulators.
https://www.blackberry.com/Downloads/
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
David Mark
> David Mark wrote:
> > On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> [...]
> [snip]
> > Those grading charts must be of great comfort to the end users who are
> > stuck with such "ancient" browsers as Opera 9, FF3 and whatever is in
> > that Blackberry of yours (NetFront?)
>
> Blackberry browser is default browser for Blackberry device. It is a
> totally unique browser with its own rendering engine.
>
> Javascript is turned off, by default. Older versions of Blackberry
> shipped with CSS off by default.
>
> It 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's why you have to test whether style changes affect the DOM
immediately and as expected. If not, you skip any enhancements that
rely on that happening.
>
> The most interesting ECMAScript bug was recently found in Blackberry.
> The bug? Activation/Variable object has a [[Prototype]].
That is interesting.
>
> I added a link in the FAQ some time back to Blackberry Browser
> JavaScript Reference:http://jibbering.com/faq/#browserResources
>
> The Blackberry device is Java, so Opera Mini would be an option for that
> device.
Good. Maybe they will switch to that. :)
>
> 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.
kangax
I talked about it here:
<http://yura.thinkweb2.com/named-function-expressions/#activation-object-in-blackberry-browser>
(this peculiarity was found by Garrett recently in one of the threads
here, when we were trying to figure out if any browsers implement
Activation Object as an instance of built-in `Object` constructor).
>
>> I added a link in the FAQ some time back to Blackberry Browser
>> JavaScript Reference:http://jibbering.com/faq/#browserResources
>>
>> The Blackberry device is Java, so Opera Mini would be an option for that
>> device.
>
> Good. Maybe they will switch to that. :)
There are rumors of Blackberry switching to WebKit in a very near future
(given recent acquisition of Torch Mobile � makers of webkit-based Iris
browser � by RIM).
<http://www.theiphoneblog.com/2009/08/24/competition-blackberry-browser-webkit-torch-mobile/>
<http://wapreview.com/blog/?p=4935>
There's no point in developing yet another proprietary engine. If they
do adopt webkit, Blackberry browser will probably disappear in a couple
of years (given its already low share among other giants like iPhone and
Android � both webkit-based as well :))
>
>> 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?
--
kangax
kangax
>> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'is not
>> 'images/cinsoft.gif'
>> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'is not
>> 'images/cinsoft.gif'
>> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
>> not 'images/cinsoft.gif'
>> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
>> not 'images/cinsoft.gif'
>>
>> Passing "2" flag to getAttribute doesn't seem to help.
>> `getAttributeNode(...).value` and `attributes[...].value` report
>> absolute values as well.
>
> 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.)
>
> An example would be a CSS selector query engine. That's one reason
> why those are ever-shifting bad ideas. With the "major" libraries,
> virtually every time a new browser comes out, their unit tests break
> (assuming they have anywhere near enough tests and know how to
> interpret them). In the minds of the authors, this invalidates the
> old browsers rather than their backwards design decision to hang
> everything on attributes. So they just "degrade" the old browser on
> paper (browser grading), rather than in the code. :(
I thought those charts are representative of QA testing. Yes, we can
develop apps that degrade gracefully, but you still need to test things
and testing takes time.
[...]
--
kangax
Garrett Smith
> David Mark wrote:
>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> David Mark wrote:
>>>> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
>>>>> David Mark wrote:
>>>>>> On Nov 23, 10:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>>>>> On Nov 23, 7:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
[snip]
>>>
>>> The Blackberry device is Java, so Opera Mini would be an option for that
>>> device.
>>
>> Good. Maybe they will switch to that. :)
Well, if "they" means the end user, that is an option. Blackberry users
are allowed to use their hardware.
Contrast to the iPhone, which is locked. Fennec, which could run in
iPhone, cannot be used in iPhone because Apple monopolizes the App Store
and won't allow it. Apple SDK also prevents developing scriptable
applications, so no scriptable browser.
>
> There are rumors of Blackberry switching to WebKit in a very near future
Yes, I have heard those rumors. Does Iris uses a proxy, like Opera Mobile?
>
> There's no point in developing yet another proprietary engine.
There may be a point for keeping Blackberry. If Blackberry is more
efficient, the battery would last longer. With a smaller app footprint,
the browser will launch faster. There may be other reasons related to
the device hardware or OS.
The problem with browsers in touchscreen mobile I've tried is that they
have the pointing device (finger) scroll the viewport. This copies
iPhone. It breaks text selection, d'n'd, and overflow: scroll (among
other things).
David Mark
> David Mark wrote:
> > On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> [...]
> >> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
> >> 'images/cinsoft.gif'
> >> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
> >> 'images/cinsoft.gif'
> >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> >> not 'images/cinsoft.gif'
> >> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> >> not 'images/cinsoft.gif'
>
> >> Passing "2" flag to getAttribute doesn't seem to help.
> >> `getAttributeNode(...).value` and `attributes[...].value` report
> >> absolute values as well.
>
> > 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
> etc.)
The DOM properties interpret the attribute values. 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.
>
>
>
> > An example would be a CSS selector query engine. That's one reason
> > why those are ever-shifting bad ideas. With the "major" libraries,
> > virtually every time a new browser comes out, their unit tests break
> > (assuming they have anywhere near enough tests and know how to
> > interpret them). In the minds of the authors, this invalidates the
> > old browsers rather than their backwards design decision to hang
> > everything on attributes. So they just "degrade" the old browser on
> > paper (browser grading), rather than in the code. :(
>
> I thought those charts are representative of QA testing. Yes, we can
> develop apps that degrade gracefully, but you still need to test things
> and testing takes time.
Whatever they represent, the explanations for the results are often
wrong. That indicates they are observations without understanding.
That's fine for a QA tester, but no way for a programmer to approach
browser scripting.
So, not completely useless, but I'd rather test for myself.
David Mark
[...]
>
> 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.)
If by reliability you mean cross-browser consistency, then yes they
are perfectly reliable (and all you should need for most apps). The
point of all of this is that jQuery and other garbage dumps call get/
set/removeAttribute (e.g. the attr method). In some cases, there is
no attempt to normalize the results at all, creating a very wobbly
foundation for basic DOM scripting. More often, there are attempts to
work around broken implementations, but the logic is either wrong or
incomplete. These workarounds change from one version to the next as
additional observations are made, which leads to more upgrades and
incompatibilities with existing apps.
In short, it's a God-awful mess that could have easily been avoided
with a little understanding. And the first thing to understand is
that you don't often need these methods in an HTML DOM.
Garrett Smith
Did you mean to say that older Opera does *not* return a full URL for an
href property value?
The href property must be resolved to a full URL; DOM 2 requirs that.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319
| href of type DOMString
| The absolute URI [IETF RFC 2396] of the linked resource. See the
| href attribute definition in HTML 4.01.
Other URL properties are much less consistent in what is returned.
For example, img.longDesc does not return a full URL in IE, but does in
Firefox and Opera. DOM 2 HTML refers to HTML 4.
The HTML 4 spec does not state *when* a relative URL is resolved.
Links to HTML 4:
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
| Relative URIs are resolved to full URIs using a base URI. [RFC1808]
HTML 5 doesn't say when a URL attribute is resolved either:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element
| The IDL attributes href, rel, media, hreflang, and type, and sizes
| each must reflect the respective content attributes of the same name.
The link property reflects in IE. Other browsers resolve a LINK
element's href property to a full URL. I'm not sure why HTML 5 specifies
it this way. A common "Location" object, like window.location, would be
nice to have on other elements such as LINK and A.
The HTML 5 specification throws javascript Errors in IE. That should not
happen.
The one-page version of HTML 5 causes Firefox 3.5 to lock up for about
20 sec (on windows vista). This is caused by the onload function which
adds extra scripts that do a lot of DOM traversal.
DOM traversal onload is known to be slow, especially for larger
documents. It is recommended against for that very reason.
The errors that will occur in IE are pretty easy to spot (e.g. Node,
textContent) and may be deliberate, out of anger. I cannot justify the
DOM traversal that causes a freeze in Firefox 3.5.
If they cannot get a simple page right, they should not be authoring web
standards.
David Mark
> kangax wrote:
> > David Mark wrote:
> >> On Nov 24, 11:08 am, kangax <kan...@gmail.com> wrote:
> > [...]
> >>> Link reference: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
> >>> 'images/cinsoft.gif'
> >>> Image source: 'http://www.cinsoft.net/images/cinsoft.gif'isnot
> >>> 'images/cinsoft.gif'
> >>> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> >>> not 'images/cinsoft.gif'
> >>> Image long description: 'http://www.cinsoft.net/images/cinsoft.gif'is
> >>> not 'images/cinsoft.gif'
>
> >>> Passing "2" flag to getAttribute doesn't seem to help.
> >>> `getAttributeNode(...).value` and `attributes[...].value` report
> >>> absolute values as well.
>
> >> 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
> > etc.)
>
> Did you mean to say that older Opera does *not* return a full URL for an
> href property value?
Regardless, it isn't the case.
>
> The href property must be resolved to a full URL; DOM 2 requirs that.http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319
Right. It's consistent cross-browser in that regard.
>
> | href of type DOMString
> | The absolute URI [IETF RFC 2396] of the linked resource. See the
> | href attribute definition in HTML 4.01.
>
> Other URL properties are much less consistent in what is returned.
Some, but not many.
>
> For example, img.longDesc does not return a full URL in IE, but does in
> Firefox and Opera. DOM 2 HTML refers to HTML 4.
The wrapper fixes that in some proprietary MS way.
>
> The HTML 4 spec does not state *when* a relative URL is resolved.
When?
>
> Links to HTML 4:http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
> | Relative URIs are resolved to full URIs using a base URI. [RFC1808]
>
> HTML 5 doesn't say when a URL attribute is resolved either:
The attribute value is literally the string from the markup, whatever
it may be (e.g. full, relative, etc.) That's why Opera's 9.27 is
flagged with a violation (and 8.54 has 4) for the action attribute.
> [...]
>
> The HTML 5 specification throws javascript Errors in IE. That should not
> happen.
Yes, they have been sucking for some time. :)
RobG
[...]
> The HTML 5 specification throws javascript Errors in IE. That should not
> happen.
If you mean the one at:
<URL: http://www.w3.org/TR/html5/ >
it is valid according to the W3C validator and does not throw any
errors in my IE 6.
> The one-page version of HTML 5 causes Firefox 3.5 to lock up for about
> 20 sec (on windows vista). This is caused by the onload function which
> adds extra scripts that do a lot of DOM traversal.
I doubt it - the script file that contains the declaration of the
onload function isn't loaded so the onload function causes an error.
The function runs OK in both Firefox and IE in the multi-page version
(link above), it doesn't do any DOM traversal that I can see. It looks
at the URL and if there's a hash, replaces it with a different value
and resets window.location.
I think the reason it takes a while to load is that the document is
about 4.4MB.
[...]
> The errors that will occur in IE are pretty easy to spot (e.g. Node,
> textContent)
IE throws the same error that Firefox does: the onload function isn't
defined.
--
Rob
David Mark
>
> (this peculiarity was found by Garrett recently in one of the threads
> here, when we were trying to figure out if any browsers implement
> Activation Object as an instance of built-in `Object` constructor).
>
>
>
> >> I added a link in the FAQ some time back to Blackberry Browser
> >> JavaScript Reference:http://jibbering.com/faq/#browserResources
>
> >> The Blackberry device is Java, so Opera Mini would be an option for that
> >> device.
>
> > Good. Maybe they will switch to that. :)
>
> There are rumors of Blackberry switching to WebKit in a very near future
> browser — by RIM).
>
> <http://www.theiphoneblog.com/2009/08/24/competition-blackberry-browse...>
> <http://wapreview.com/blog/?p=4935>
>
> There's no point in developing yet another proprietary engine. If they
> do adopt webkit, Blackberry browser will probably disappear in a couple
> of years (given its already low share among other giants like iPhone and
>
>
>
> >> 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 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.
Garrett Smith
>>> etc.)
>> Did you mean to say that older Opera does *not* return a full URL for an
>> href property value?
>
> Regardless, it isn't the case.
>
>> The href property must be resolved to a full URL; DOM 2 requirs that.http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319
>
> Right. It's consistent cross-browser in that regard.
>
>> | href of type DOMString
>> | The absolute URI [IETF RFC 2396] of the linked resource. See the
>> | href attribute definition in HTML 4.01.
>>
>> Other URL properties are much less consistent in what is returned.
>
> Some, but not many.
>
Relative in IE, absolute in 4 others:
link.href
img.longDesc
script.src
Absolute in all:
a.href
img.src
Untested:
area.href
base.href
blockquote.cite
embed.src
head.profile
img.useMap
input.src
input.usemap
object.classid
object.codeBase
object.data
object.useMap
q.cite
form.action resolved in Firefox, not resolved in 4 others.
There should be a tests features all of the above using relative URIs
for attributes and see if the values of the corresponsing DOM properties
are absolute URIs.
DOM 2 HTML[1] says absolute URI for:
a.href
document.URL
document.cookie, when domain is not set
>> For example, img.longDesc does not return a full URL in IE, but does in
>> Firefox and Opera. DOM 2 HTML refers to HTML 4.
>
LINK href is also a full URI, and in Chrome and Safari.
> The wrapper fixes that in some proprietary MS way.
>
The realAttr? I don't think it does that. That function parses outerHTML
for IE. It seems like overkill.
The regexes expect no whitespace around the "=" in the attribute:
<b id = 'x'>b</b>
IE's outerHTML for that:
<B id=x>b</B>
Example code:
javascript: var div =document.createElement("div"); void(div.innerHTML =
"<b id = 'x'>b</b>"); alert(div.firstChild.outerHTML);
>> The HTML 4 spec does not state *when* a relative URL is resolved.
>
> When?
>
Precisely.
As you see, the HTML 4 specification states that Relative URIs are
resolved to full URIs:
>> Links to HTML 4:http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
>> | Relative URIs are resolved to full URIs using a base URI. [RFC1808]
>>
HTML 4 says an absolute URI is resolved. When? During parse time? When
the attribute is requested (as when the browser makes an HTTP request to
load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
From the perspective of HTML, it doesn't matter when.
A relative URI and an absolute URI are different. Programs should be
able to have an expectation of the URI being resolved.
>> HTML 5 doesn't say when a URL attribute is resolved either:
>
A pity that is.
As stated, a LINK's href is resolved to a full URI in a majority of
browsers. In contrast to what browsers do, HTML 5 specifies that that a
LINK's href reflects.
[1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
David Mark
[...]
>
> The realAttr? I don't think it does that. That function parses outerHTML
> for IE. It seems like overkill.
No, it only uses outerHTML for a couple of problematic properties
(neither related to URI's). IIRC, the file paths in the broken MSHTML
fork are dealt with through that silly iFlags argument. Regardless,
they are indeed dealt with and you do get the literal URI's in all
versions and modes AFAIK.
And of course it is overkill, except in the rare context when you need
to read attributes as they appear in the markup.
It also illustrates the futility of relying on these methods when you
don't have to (i.e. look at all of the hoops just to keep IE8's
various modes in sync).
>
> The regexes expect no whitespace around the "=" in the attribute:
>
> <b id = 'x'>b</b>
>
> IE's outerHTML for that:
> <B id=x>b</B>
I'll look at it. That was a last minute addition. I think enctype
and value have no other way to determine if they are present. If, for
instance, you were writing a function to serialize a DOM structure,
you would need to know the difference between value="" and no value
attribute at all (DOM property will be "" in either case).
>
> Example code:
> javascript: var div =document.createElement("div"); void(div.innerHTML =
> "<b id = 'x'>b</b>"); alert(div.firstChild.outerHTML);
So it shows that the white space is irrelevant in MSHTML? Regardless,
I agree that the RegExp should allow for such white space in
outerHTML. You never know when they might change it.
>
> >> The HTML 4 spec does not state *when* a relative URL is resolved.
>
> > When?
>
> Precisely.
>
> As you see, the HTML 4 specification states that Relative URIs are
> resolved to full URIs:>> Links to HTML 4:http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-uri
> >> | Relative URIs are resolved to full URIs using a base URI. [RFC1808]
I don't see the temporal connection.
>
> HTML 4 says an absolute URI is resolved. When? During parse time? When
> the attribute is requested (as when the browser makes an HTTP request to
> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
> From the perspective of HTML, it doesn't matter when.
I know that. A property get will normally resolve it, regardless of
when. A getAttribute call, in contrast, should return whatever is in
the markup verbatim (and normally does in most of the latest major
browsers).
>
> A relative URI and an absolute URI are different. Programs should be
> able to have an expectation of the URI being resolved.
Yes. That's another use case for these wrappers (to correct such
problems when possible and degrade gracefully otherwise).
>
> >> HTML 5 doesn't say when a URL attribute is resolved either:
>
> A pity that is.
I still don't understand the time question.
>
> As stated, a LINK's href is resolved to a full URI in a majority of
> browsers.
The DOM property? Yes. Virtually all of them.
> In contrast to what browsers do, HTML 5 specifies that that a
> LINK's href reflects.
> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
As in, it matches the attribute value? I think that would be a stupid
change in direction. It's useful to be able to get the resolved
path. But what the HTML5 group thinks is irrelevant right now anyway.
Garrett Smith
> On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> [...]
>> The HTML 5 specification throws javascript Errors in IE. That should not
>> happen.
>
> If you mean the one at:
>
> <URL: http://www.w3.org/TR/html5/ >
>
http://www.whatwg.org/specs/web-apps/current-work/
Throws javascript errors in IE.
> it is valid according to the W3C validator and does not throw any
> errors in my IE 6.
>
I didn't check the HTML validator.
http://www.whatwg.org/specs/web-apps/current-work/multipage/
Throws javascript errors in IE:
The init() method called in onload:
http://www.whatwg.org/specs/web-apps/current-work/multipage/toc.js
function filterToc(toc, callback) {
var li = toc.firstChild;
var allmatched = true;
while (li) {
if (li.nodeType == Node.ELEMENT_NODE) {
Looks like DOM traversal.
What is |Node| on line 5? Looks like a ReferenceError in IE.
ALthough I don't advocate writing of code that spitefully throws angry
errors in IE, other contemptful authors do (Jorge might do something
like that).
However, it is hard to find any sort of justification for wanting the
one-page document to freeze any browser it loads in.
Whatever it is doing, it could probably do it more efficiently; perhaps
using event bubbling or something.
[snip]
>
> I think the reason it takes a while to load is that the document is
> about 4.4MB.
>
The spec on whatwg page freezes IE. The spec on w3.org does not.
The problem is not the size alone.
> [...]
>> The errors that will occur in IE are pretty easy to spot (e.g. Node,
>> textContent)
>
> IE throws the same error that Firefox does: the onload function isn't
> defined.
>
Oh, really? So the w3c site throws errors?
Huh, I am seeing:
fixBrokenLink(); fixBrokenLink()
- which is redundant, but no errors thrown. Maybe it was updated just
now and the file did not load. Try a force-reload and let me know what
happens.
Garrett Smith
> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> [...]
>
>> The realAttr? I don't think it does that. That function parses outerHTML
>> for IE. It seems like overkill.
>
Method realAttr address attribute issue; not properties.
link.href (as in HTMLLinkElement) is a property. The value is a relative
URI in IE.
[snip]
>
> It also illustrates the futility of relying on these methods when you
> don't have to (i.e. look at all of the hoops just to keep IE8's
> various modes in sync).
>
Is there a good page that details those in more depth?
[snip]
> So it shows that the white space is irrelevant in MSHTML? Regardless,
> I agree that the RegExp should allow for such white space in
> outerHTML. You never know when they might change it.
>
Whitespace is allowed there in HTML. I would not rely on nonstandard
quirks. I remember differences in Opera outerHTML.
[snip]
>> HTML 4 says an absolute URI is resolved. When? During parse time? When
>> the attribute is requested (as when the browser makes an HTTP request to
>> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
>> From the perspective of HTML, it doesn't matter when.
>
> I know that. A property get will normally resolve it,
No, a property get does not normally resolve it. DOM 2 guarantees a full
URI for document.URL, a.href, and the domain of a cookie.
In Four browsers, the property form.action is relative URI.
Further testing of properties is warranted.
regardless of
> when. A getAttribute call, in contrast, should return whatever is in
> the markup verbatim (and normally does in most of the latest major
> browsers).
>
That is correct.
>> A relative URI and an absolute URI are different. Programs should be
>> able to have an expectation of the URI being resolved.
>
> Yes. That's another use case for these wrappers (to correct such
> problems when possible and degrade gracefully otherwise).
>
That wrapper does not guarantee a full URI from a property.
>>>> HTML 5 doesn't say when a URL attribute is resolved either:
>> A pity that is.
>
> I still don't understand the time question.
>
The browser has a few options. Take form action:
1) when the form action attribute is used internally
2) when the form action dom property is accessed
When the property form.action is accessed through script, the browser
has a choice to return a value that was parsed or to return an absolute
URI.
Is it lazily, upon reading the property> or is it only when
>> As stated, a LINK's href is resolved to a full URI in a majority of
>> browsers.
>
> The DOM property? Yes. Virtually all of them.
>
Unfortunately no, many URI attributes' corresponding dom *properties*
don't get resolved to a full URI as in IE.
does not resolve to an absolute URI in IE:
script.src
form.action
img.longDesc
form.action resolves to a full URI in Firefox, but not IE, Chrome,
Safari, Opera.
All of the other URI attributes could be tested and specified.
>> In contrast to what browsers do, HTML 5 specifies that that a
>> LINK's href reflects.
>> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>
> As in, it matches the attribute value?
Yes, HTML 5 says link.href returns the content attribute value.
That's not what four browsers do.
I think that would be a stupid
Yeah they should fix that.
RobG
> RobG wrote:
> > On Nov 26, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> > [...]
> >> The HTML 5 specification throws javascript Errors in IE. That should not
> >> happen.
>
> > If you mean the one at:
>
> > <URL:http://www.w3.org/TR/html5/>
>
> No, I meant:http://www.whatwg.org/specs/web-apps/current-work/
OK, we're looking at different documents then.
>
> Throws javascript errors in IE.
Yes.
> > it is valid according to the W3C validator and does not throw any
> > errors in my IE 6.
>
> I didn't check the HTML validator.
The whatwg document has a couple of minor errors that shouldn't affect
the script.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/
> Throws javascript errors in IE:
Yes.
>
> The init() method called in onload:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/toc.js
> function filterToc(toc, callback) {
> var li = toc.firstChild;
> var allmatched = true;
> while (li) {
> if (li.nodeType == Node.ELEMENT_NODE) {
>
> Looks like DOM traversal.
Yes.
> What is |Node| on line 5? Looks like a ReferenceError in IE.
>
> ALthough I don't advocate writing of code that spitefully throws angry
> errors in IE, other contemptful authors do (Jorge might do something
> like that).
>
> However, it is hard to find any sort of justification for wanting the
> one-page document to freeze any browser it loads in.
Presuming it was malicious rather than clueless.
--
Rob
David Mark
> David Mark wrote:
> > On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > [...]
>
> >> The realAttr? I don't think it does that. That function parses outerHTML
> >> for IE. It seems like overkill.
>
> Method realAttr address attribute issue; not properties.
Of course. There is a companion (unfortunately) called "attr" that
addresses properties. ;)
>
> link.href (as in HTMLLinkElement) is a property.
Yes.
> The value is a relative
> URI in IE.
That's a bug and irrelevant to realAttr as it deals with attributes.
Apparently, using realAttr (or bits of it) will be more consistent
than DOM properties in some cases.
>
> [snip]
>
>
>
> > It also illustrates the futility of relying on these methods when you
> > don't have to (i.e. look at all of the hoops just to keep IE8's
> > various modes in sync).
>
> Is there a good page that details those in more depth?
Not really. But we've been over it here. In a nutshell, IE < 8 (plus
IE8 compatibility mode) doesn't understand the difference between
attributes and properties. They also foul up the attributes that
correspond to boolean DOM properties (e.g. disabled, readonly). The
details are in the comments in the wrappers.
>
> [snip]> So it shows that the white space is irrelevant in MSHTML? Regardless,
> > I agree that the RegExp should allow for such white space in
> > outerHTML. You never know when they might change it.
>
> Whitespace is allowed there in HTML. I would not rely on nonstandard
> quirks. I remember differences in Opera outerHTML.
I agree and will definitely update that RegExp when I get a chance.
>
> [snip]
>
> >> HTML 4 says an absolute URI is resolved. When? During parse time? When
> >> the attribute is requested (as when the browser makes an HTTP request to
> >> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
> >> From the perspective of HTML, it doesn't matter when.
>
> > I know that. A property get will normally resolve it,
>
> No, a property get does not normally resolve it. DOM 2 guarantees a full
> URI for document.URL, a.href, and the domain of a cookie.
That's what I said. The get will resolve a relative URI (to a full
URI). Getting the attribute should _not_ do that (and doesn't in most
browsers).
>
> In Four browsers, the property form.action is relative URI.
Those are four bugs. Using the wrappers, it is down to two as IE is
taken care of. But certainly I wouldn't count on being able to get a
URI attribute value as it appears in the markup (or conversely rely on
property gets to resolve them to full paths).
>
> Further testing of properties is warranted.
Yes. I have a companion piece that does just that. Compares Dojo,
jQuery and GoogClosure versions of "attr" to a wrapper based on my
code and the raw results from the browser. It's quite illuminating
(and very scary if you built on those libraries) but needs a little
more work before I publish it.
>
> regardless of
>
> > when. A getAttribute call, in contrast, should return whatever is in
> > the markup verbatim (and normally does in most of the latest major
> > browsers).
>
> That is correct.
>
> >> A relative URI and an absolute URI are different. Programs should be
> >> able to have an expectation of the URI being resolved.
>
> > Yes. That's another use case for these wrappers (to correct such
> > problems when possible and degrade gracefully otherwise).
>
> That wrapper does not guarantee a full URI from a property.
>
> >>>> HTML 5 doesn't say when a URL attribute is resolved either:
> >> A pity that is.
>
> > I still don't understand the time question.
>
> The browser has a few options. Take form action:
> 1) when the form action attribute is used internally
> 2) when the form action dom property is accessed
>
> When the property form.action is accessed through script, the browser
> has a choice to return a value that was parsed or to return an absolute
> URI.
Yes and the latter is the correct choice.
>
> Is it lazily, upon reading the property> or is it only when
Oh, who knows? That's behind-the-scenes and up to the implementation.
>
> >> As stated, a LINK's href is resolved to a full URI in a majority of
> >> browsers.
>
> > The DOM property? Yes. Virtually all of them.
>
> Unfortunately no, many URI attributes' corresponding dom *properties*
> don't get resolved to a full URI as in IE.
Those are bugs.
>
> does not resolve to an absolute URI in IE:
> script.src
> form.action
> img.longDesc
IE has lots of bugs. Apparently using realAttr is more consistent
than using DOM properties in IE.
>
> form.action resolves to a full URI in Firefox, but not IE, Chrome,
> Safari, Opera.
FF is the only one that got that one right then.
>
> All of the other URI attributes could be tested and specified.>> In contrast to what browsers do, HTML 5 specifies that that a
> >> LINK's href reflects.
> >> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>
> > As in, it matches the attribute value?
>
> Yes, HTML 5 says link.href returns the content attribute value.
> That's not what four browsers do.
Actually, that's what you said the four (bad) browsers did (returned
the attribute value verbatim). That's wrong and if HTML5 copies that,
they have eliminated the possibility of ever getting the fully
resolved URI from the href property. (!)
>
> I think that would be a stupid
>
> Yeah they should fix that.
Definitely. What the hell are they doing? Watching browsers and
taking notes? Do they understand the behavior observed and the
ramifications to present and future scripts? It sure doesn't sound
like it. :(
Garrett Smith
> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> [...]
>>>> The realAttr? I don't think it does that. That function parses outerHTML
>>>> for IE. It seems like overkill.
>> Method realAttr address attribute issue; not properties.
>
> Of course. There is a companion (unfortunately) called "attr" that
> addresses properties. ;)
>
>> link.href (as in HTMLLinkElement) is a property.
>
> Yes.
>
>> The value is a relative
>> URI in IE.
>
> That's a bug
Why do you say so?
>>
>>
>>> It also illustrates the futility of relying on these methods when you
>>> don't have to (i.e. look at all of the hoops just to keep IE8's
>>> various modes in sync).
>> Is there a good page that details those in more depth?
>
> Not really. But we've been over it here. In a nutshell, IE < 8 (plus
> IE8 compatibility mode)
| The X-UA-COMPATIBLE header has greater precedence than Compatibility
| View. If a Web site is on the Compatibility View List and a page on
| that site includes an X-UA-COMPATIBLE header telling Internet Explorer
| 8 to display a page in IE8 mode, the page is displayed in Internet
| Explorer 8 Standards mode. This allows Web developers to support
| Internet Explorer 8 Standards mode on an incremental basis. For more
| information, see Defining Document Compatibility.
>
>> [snip]> So it shows that the white space is irrelevant in MSHTML? Regardless,
>>> I agree that the RegExp should allow for such white space in
>>> outerHTML. You never know when they might change it.
>> Whitespace is allowed there in HTML. I would not rely on nonstandard
>> quirks. I remember differences in Opera outerHTML.
>
> I agree and will definitely update that RegExp when I get a chance.
>
>> [snip]
>>
>>>> HTML 4 says an absolute URI is resolved. When? During parse time? When
>>>> the attribute is requested (as when the browser makes an HTTP request to
>>>> load a stylesheet from the src of a LINK tag)? HTML4 does not say when.
>>>> From the perspective of HTML, it doesn't matter when.
>>> I know that. A property get will normally resolve it,
>> No, a property get does not normally resolve it. DOM 2 guarantees a full
>> URI for document.URL, a.href, and the domain of a cookie.
>
> That's what I said.
No, you wrote: "A property get will normally resolve it".
If "it" means a property with a URL value, then that would be a false
statement. A property get of URL attribute's corresponding DOM property
does *not* normally resolve a relative URL to an absolute URL. DOM 2
HTML says absolute URI for three properties (cookie, a.href,
document.url) What browsers return for other properties that correspond
to URI attributes varies.
URIs in stylesheets is yet another matter.
The get will resolve a relative URI (to a full
> URI). Getting the attribute should _not_ do that (and doesn't in most
> browsers).
>
>> In Four browsers, the property form.action is relative URI.
>
(that does not express my intent well; I meant that form.action reflects
the corresponding content attribute).
> Those are four bugs.
Why do you say so?
Using the wrappers, it is down to two as IE is
> taken care of. But certainly I wouldn't count on being able to get a
> URI attribute value as it appears in the markup (or conversely rely on
> property gets to resolve them to full paths).
>
Programs can't rely on properties or attributes.
>> Further testing of properties is warranted.
>
> Yes. I have a companion piece that does just that. Compares Dojo,
> jQuery and GoogClosure versions of "attr" to a wrapper based on my
> code and the raw results from the browser. It's quite illuminating
> (and very scary if you built on those libraries) but needs a little
> more work before I publish it.
>
I am interested in seeing a test page for reading properties from objects.
DOM URI Properties are Resolved to Absolute URI?
| property | IE7 | FF3 | | Standard |
+-------------+-----+-----+ [...] -+----------+
| link.href | N | Y | | N |
| a.href | Y | Y | | Y |
| form.action | N | Y
Just adding in all the browsers. Its work to be done, but would be
worthwhile to have published, for reference.
>> regardless of
>>
>>> when. A getAttribute call, in contrast, should return whatever is in
>>> the markup verbatim (and normally does in most of the latest major
>>> browsers).
>> That is correct.
>>
>>>> A relative URI and an absolute URI are different. Programs should be
>>>> able to have an expectation of the URI being resolved.
>>> Yes. That's another use case for these wrappers (to correct such
>>> problems when possible and degrade gracefully otherwise).
>> That wrapper does not guarantee a full URI from a property.
>>
>>>>>> HTML 5 doesn't say when a URL attribute is resolved either:
>>>> A pity that is.
>>> I still don't understand the time question.
>> The browser has a few options. Take form action:
>> 1) when the form action attribute is used internally
>> 2) when the form action dom property is accessed
>>
>> When the property form.action is accessed through script, the browser
>> has a choice to return a value that was parsed or to return an absolute
>> URI.
>
> Yes and the latter is the correct choice.
>
AFAIK, there isn't any standard that confirms that to be true.
In fact, the DOM explicitly states *absolute URI* for a.href, but does
not state so for link.href. This leads me to believe that the value of
the DOM property is not guaranteed to be an absolute URI.
[snip]
>>>> As stated, a LINK's href is resolved to a full URI in a majority of
>>>> browsers.
>>> The DOM property? Yes. Virtually all of them.
>> Unfortunately no, many URI attributes' corresponding dom *properties*
>> don't get resolved to a full URI as in IE.
>
> Those are bugs.
>
That hasn't been shown to be the case.
[...]
>
>> All of the other URI attributes could be tested and specified.>> In contrast to what browsers do, HTML 5 specifies that that a
>>>> LINK's href reflects.
>>>> [1]http://www.w3.org/TR/DOM-Level-2-HTML/html.html
>>> As in, it matches the attribute value?
>> Yes, HTML 5 says link.href returns the content attribute value.
>> That's not what four browsers do.
>
> Actually, that's what you said the four (bad) browsers did (returned
> the attribute value verbatim).
I did not write that. I wrote the opposite:
| HTML 5 says link.href returns the content attribute value. That's
| *not* what four browsers do.
Four browsers return an absolute URI for link.href.
We need a test page. I outlined earlier the object properties that have
URI-valued attributes. Each attribute needs to be tested and the resulst
published in a table.
That's wrong and if HTML5 copies that,
> they have eliminated the possibility of ever getting the fully
> resolved URI from the href property. (!)
>
>> I think that would be a stupid
>>
>> Yeah they should fix that.
>
> Definitely. What the hell are they doing? Watching browsers and
> taking notes?
Probably not in this case.
When standardizing legacy features, Ian and Anne seem look at what
browsers do. Unfortunately this often includes things that are useless,
inconsistent, and buggy, such as form.elementName, HTMLCollection.tags,
and quirks mode.
The standardizing of legacy garbage is a forest for the trees issue.
Also a chicken and egg issue. What scripts do is largely the result of
the bad DOMs and so looking at the bad DOMs and looking at the scripts
and standardizing what happens encourages browser consistency but misses
the big picture: The API should exist to solve problems. Rather than
standardizing garbage because it works in three browsers, it might make
sense to look at how it is being used and present a superior alternative.
The new HTML 5 and WebIDL features are even more bizarre, including
Element.prototype, [[Class]], special delete operator behavior. What a
disaster that is. AIUI, Brendan will be going in an cleaning up their
mess. Poor guy. Allen, great guy but they don't hang.
David Mark
> David Mark wrote:
> > On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>> [...]
> >>>> The realAttr? I don't think it does that. That function parses outerHTML
> >>>> for IE. It seems like overkill.
> >> Method realAttr address attribute issue; not properties.
>
> > Of course. There is a companion (unfortunately) called "attr" that
> > addresses properties. ;)
>
> >> link.href (as in HTMLLinkElement) is a property.
>
> > Yes.
>
> >> The value is a relative
> >> URI in IE.
>
> > That's a bug
>
> Why do you say so?
Because it should be absolute, just like a.href, img.src, etc.
I added link.href to the tests. All consistent save for Opera 8.27,
which now has five inconsistencies (all URI related). Opera 9.27 has
the one (form.action).
I'll add usemap to the tests when I get a chance.
And, other than if you need to differentiate between absolute and
relative URI's, you can rely on DOM properties. It's the opposite
with attributes, unless you use wrappers (i.e. it is complete chaos).
That's what makes the reliance on get/set/removeAttribute so shaky and
therefore the use of these methods usually indicates a bad script.
Just take this structure:-
<input type="checkbox">
It is guaranteed that the checked property is false. The quasi-
standards-based browsers will return null for the checked attribute
(as is correct as it isn't there). Broken MSHTML implementations
return false. IE8 (in standards mode) returns ''.
Then take this:-
<input type="checkbox" checked>
The DOM property is true, always. Many non-IE browsers will return ''
for the attribute. Uh oh. :(
All you have to do is search the jQuery groups for attr to see that
such issues have been biting them for years. Even where that method
works, it is often by coincidence. As predicted (and relayed to the
jQuery developers and other interested parties 2 years ago), IE8
brought these issues to a head. jQuery responded with... nothing.
The newly released rendition in GoogClosure is a hundred times worse.
Other than for their (ill-advised) CSS selector query engines (Goog
uses an old Dojo version), they didn't need these methods at all.
Strange they ended up at the forefront of DOM manipulation in both
(and others).
David Mark
[...]
>
> I'll add usemap to the tests when I get a chance.
>
Added. As usual, bad news for browsers (e.g. IE8), but great news if
you use realAttr. :)
Or more accurately, if you reproduce the feature tests (from the code
and/or the test page) needed for your app.
I'd say the most strenuous test of such a GP wrapper would be
serializing a DOM a la innerHTML. That's one of the few things that
it is used for in My Library (though that version is not quite as good
as the one in the test page).
So where could such an app (that needs to get all attributes
accurately) fail? Looks like (some) relative file URI's in older
Opera browsers and default enctype in IE < 8 (and IE8 compatibility
mode). That latter has no real downside. The former would convert
some URI attributes to absolute. If you really need the relative
paths, you should feature test this issue before defining whatever
wrapper will retrieve the paths.
Then there's Blackberry. Haven't seen the results for that one yet.
I heard that environment failed about as many unit tests as Opera 8.54
did. Only took one feature test to smooth that one out and I'm
hopeful it put a dent in the Blackberry quirks as well.
Garrett Smith
> On Nov 26, 10:05 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 26, 3:45 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Nov 26, 2:17 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>>> [...]
>>>>>> The realAttr? I don't think it does that. That function parses outerHTML
>>>>>> for IE. It seems like overkill.
>>>> Method realAttr address attribute issue; not properties.
>>> Of course. There is a companion (unfortunately) called "attr" that
>>> addresses properties. ;)
>>>> link.href (as in HTMLLinkElement) is a property.
>>> Yes.
>>>> The value is a relative
>>>> URI in IE.
>>> That's a bug
>> Why do you say so?
>
> Because it should be absolute, just like a.href, img.src, etc.
>
Alas, the DOM 2 HTML specification does not standardize it that way. Not
even for img.src.
[snip]
Understanding what browsers do offers the most benefit developers and
HTML 5 spec authors. That goal is best realized in a comprehensive table
showing browser+version in column with property names in rows.
Trying to create a comprehensive realAttr or resolvedURI(prop) method is
just going to add a lot extra cruft and slow the code down.
The jQuery attr function, as a core method, is broken by design. The
attr function seems to be an attempt to provide a cross browser function
to read *something* about an object. That something was either content
attributes or dom properties, and the discrimination between the two was
apparently grossly overlooked in the initial design.
From jQuery attr:
| // If applicable, access the attribute via the DOM 0 way
| if ( name in elem && notxml && !special ) {
David Mark
I know that. Neither is necessary for _most_ applications. The best
policy is avoidance.
>
> The jQuery attr function, as a core method, is broken by design.
I know and they are not alone. And I don't think it was designed as
much as oozed out as a result of observations.
> The
> attr function seems to be an attempt to provide a cross browser function
> to read *something* about an object.
It's definitely something. Unfortunately nobody has ever been able to
describe what that something is (including John Resig).
> That something was either content
> attributes or dom properties, and the discrimination between the two was
> apparently grossly overlooked in the initial design.
Yes. Somehow they missed the broken MSHTML pattern, which has been
well documented for ten years.
>
> From jQuery attr:
> | // If applicable, access the attribute via the DOM 0 way
> | if ( name in elem && notxml && !special ) {
Yes, I know. As documented here numerous times, it is a ridiculous
function (and used in every jQuery tutorial, plug-in example, etc.)
It's a critical, low-level function and somehow they've had it botched
all this time. So much for the browser Ninjas and their "test
swarms". They are clearly unfamiliar with IE in all sorts of critical
ways. IE8 only made things worse and they _still_ haven't fixed the
attribute issue.
Too late perhaps as there are likely a million workarounds floating
around out there. I suppose at least a small percentage of them will
break if they breathe on attr. But then, as written, it can't even be
pinned down in IE8 (results vary with the mode) and attr changes a
little bit with each jQuery release (as new "phenomena" are observed).
This can't inspire confidence for apps, widgets, etc. written on top
of any version of jQuery. They can clearly break in all sorts of
maddening ways with the click of a button, which is handily located
next to Refresh in IE8. Imagine somebody testing a jQuery app today
in IE8 standards mode, FF3, Opera 10, Chrome, Safari and nothing
else. They could easily be fooled into thinking the app works when it
actually falls apart in IE6/7 (or at the click of toolbar button).
David Mark
[...]
>
> Alas, the DOM 2 HTML specification does not standardize it that way. Not
> even for img.src.
>
I know, but there definitely should be. The browser developers are
mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
IE6-8, and most if not all FF versions).
How else would you (easily) get the resolved path? That's why I
couldn't believe HTML5 would consider going in the other direction
(URI properties and attributes _both_ return unresolved paths).
Garrett Smith
> On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> [...]
>
>> Alas, the DOM 2 HTML specification does not standardize it that way. Not
>> even for img.src.
>>
>
> I know, but there definitely should be.
It is not standard. Browsers vary for many properties.
The browser developers are
> mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
> IE6-8, and most if not all FF versions).
>
For img.src Netscape 4 provides a full URI. Other browsers copied that.
For other URI attributes, browsers vary.
David Mark
> David Mark wrote:
> > On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > [...]
>
> >> Alas, the DOM 2 HTML specification does not standardize it that way. Not
> >> even for img.src.
>
> > I know, but there definitely should be.
>
> It is not standard. Browsers vary for many properties.
>
> The browser developers are
>
> > mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
> > IE6-8, and most if not all FF versions).
I meant mostly in agreement with URI attributes. The URI properties
are all over the place.
>
> For img.src Netscape 4 provides a full URI. Other browsers copied that.
Generally a.href as well. The idea that they would split the
remaining URI properties up into resolve and "no resolve" piles is
ridiculous. ISTM that properties should always resolve as else there
would be no way to get the resolved URI.
> For other URI attributes, browsers vary.
Not with attributes of late. Else that test page would have red spots
on the right.
Garrett Smith
> On Nov 27, 2:45 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 27, 3:35 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> [...]
>>>> Alas, the DOM 2 HTML specification does not standardize it that way. Not
>>>> even for img.src.
>>> I know, but there definitely should be.
>> It is not standard. Browsers vary for many properties.
>>
attribute's corresponding property to have absolute URI.
| If a reflecting IDL attribute is a DOMString attribute whose content
| attribute is defined to contain a URL, then on getting, the IDL
| attribute must resolve the value of the content attribute relative to
| the element and return the resulting absolute URL if that was
| successful, or the empty string otherwise; and on setting, must set
| the content attribute to the specified literal value. If the content
| attribute is absent, the IDL attribute must return the default value,
| if the content attribute has one, or else the empty
That means that all URI valued properties, form.action, link.href,
script.src, etc would return an absolute URL (or "" if that fails).
>> The browser developers are
>>
>>> mostly in agreement at this time (e.g. Opera 9.5+, Chrome, Safari 4,
>>> IE6-8, and most if not all FF versions).
>
> I meant mostly in agreement with URI attributes.
Attribute value is whatever is in the source code, unless the property
"reflects". In that case, changing the property changes the attribute
value and vice versa.
For example, setting the title property actually creates the title
attribute value:
var node = document.createElement("div");
node.getAttribute("title"); // null
node.title="t";
node.getAttribute("title"); // "t"
The style property has a more involved serialization.
The URI properties
> are all over the place.
>
>> For img.src Netscape 4 provides a full URI. Other browsers copied that.
>
> Generally a.href as well.
a.href is required to return absolute URI per DOM 2 HTML. The same spec
says img.src is a URI but does not say if that should be relative or
absolute:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-87762984
| src of type DOMString
| URI [IETF RFC 2396] designating the source of this image. See the
| src attribute definition in HTML 4.01.
The idea that they would split the
> remaining URI properties up into resolve and "no resolve" piles is
> ridiculous. ISTM that properties should always resolve as else there
> would be no way to get the resolved URI.
>
>> For other URI attributes, browsers vary.
>
disambiguation:
For other URI-valued attributes, values of corresponding DOM properties
vary between browsers.
HTML 5 defines "reflect" specially for URI-valued attributes/properties,
as stated (and explained in the reflink below).
Eric Bednarz
> 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. :-)
In the source code – of HTML documents, at least – are attribute value
*literals*.
David Mark
[...]
>
> The jQuery attr function, as a core method, is broken by design. The
> attr function seems to be an attempt to provide a cross browser function
> to read *something* about an object. That something was either content
> attributes or dom properties, and the discrimination between the two was
> apparently grossly overlooked in the initial design.
>
> From jQuery attr:
> | // If applicable, access the attribute via the DOM 0 way
> | if ( name in elem && notxml && !special ) {
> --
> Garrett
> comp.lang.javascript FAQ:http://jibbering.com/faq/
Then there's GoogClosure (but why?)
Here's the documentation for createDOM:-
Returns a dom node with a set of attributes. This function accepts
varargs for subsequent nodes to be added. Subsequent nodes will be
added to the first node as childNodes. So: createDom('div', null,
createDom('p'), createDom('p')); would return a div with two child
paragraphs
Yeah, that's it. No idea what it means. Could be important.
goog.dom.createDom_ = function(doc, args) {
var tagName = args[0];
var attributes = args[1];
Confusing start (and it doesn't get any better).
// Internet Explorer is dumb: http://msdn.microsoft.com/workshop/author/
// dhtml/reference/properties/name_2.asp
As mentioned, PKB.
// Also does not allow setting of 'type' attribute on 'input' or
'button'.
Oh but it does. They'd know if they only tested (instead of
misinterpreting a Microsoft missive).
if (goog.userAgent.IE && attributes && (attributes.name ||
attributes.type)) {
So, if the UA string says IE (!) and the attributes argument passed
has "name" or "type" properties...
var tagNameArr = ['<', tagName];
if (attributes.name) {
tagNameArr.push(' name="', goog.string.htmlEscape
(attributes.name),
'"');
}
if (attributes.type) {
tagNameArr.push(' type="', goog.string.htmlEscape
(attributes.type),
'"');
// Create copy of attribute map to remove 'type' without
mutating argument
attributes = goog.cloneObject(attributes);
delete attributes.type;
It's interesting. They didn't delete attributes.name.
}
tagNameArr.push('>');
tagName = tagNameArr.join('');
}
This whole mess is a completely unneeded workaround that will fail
miserably (likely throwing an exception) in any non-IE browser.
Unnecessary and programming for disaster as many UA strings look like
IE's.
In short, type can be set once. Set it immediately after creating the
element (before some other property set causes it to sprout a document
fragment). You can set name any time, but set it after appending if
you want the element to show up in DOM collections (e.g. form elements
collection).
I haven't read the MSDN article they cited (at least not recently).
Perhaps it is wildly inaccurate (wouldn't be the first time).
Regardless, these things are easy to test and the behavior has been
the same for IE4-8 AFAIK.
var element = doc.createElement(tagName);
if (attributes) {
if (goog.isString(attributes)) {
typeof attributes == 'string'
I am pleasantly surprised they checked for the string first. :)
element.className = attributes;
Seems an odd design.
} else {
goog.dom.setProperties(element, attributes);
That looks critical.
}
}
if (args.length > 2) {
var childHandler = function(child) {
// TODO: More coercion, ala MochiKit?
if (child) {
element.appendChild(goog.isString(child) ?
doc.createTextNode(child) : child);
}
};
for (var i = 2; i < args.length; i++) {
var arg = args[i];
// TODO: Fix isArrayLike to return false for a text node.
if (goog.isArrayLike(arg) && !goog.dom.isNodeLike(arg)) {
"Overloading" strategy is designed for failure.
// If the argument is a node list, not a real array, use a
clone,
// because forEach can't be used to mutate a NodeList.
goog.array.forEach(goog.dom.isNodeList(arg) ?
goog.array.clone(arg) : arg,
childHandler);
} else {
childHandler(arg);
}
}
}
Right, we'll skip that mess. Here's the salient bit:-
goog.dom.setProperties = function(element, properties) {
goog.object.forEach(properties, function(val, key) {
if (key == 'style') {
element.style.cssText = val;
No feature detection.
} else if (key == 'class') {
As there is no real documentation, this is the first clue as to what
is expected for attribute (property?) names. That's an attribute
name.
element.className = val;
} else if (key == 'for') {
As is that.
element.htmlFor = val;
} else if (key in goog.dom.DIRECT_ATTRIBUTE_MAP_) {
No filter. And that object is a partial mapping of attribute names to
DOM property names (see below).
element.setAttribute(goog.dom.DIRECT_ATTRIBUTE_MAP_[key], val);
Cue the Twilight Zone music. This passes a DOM property name to
setAttribute.
} else {
This sets a DOM property with an attribute name.
element[key] = val;
element.readonly = ???; // Don't know what to pass for values
element.colspan = ???;
Those result in useless host object augmentations and you can't pass
the property names (e.g. readOnly, colSpan) either (see mapping
below).
}
});
};
In a nutshell, this is completely unusable. It literally makes no
sense. Should be immediately apparent to almost anyone who has ever
scripted an MSHTML DOM. Look closer and notice it is broken (by
design) for everything else as well. I can see why their "technical
writers" punted on writing this one up.
As advertised:-
goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'cellpadding': 'cellPadding',
'cellspacing': 'cellSpacing',
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'valign': 'vAlign',
'height': 'height',
'width': 'width',
'usemap': 'useMap',
'frameborder': 'frameBorder',
'type': 'type'
};
The height and width "mappings" are intriguing. Will force the use of
setAttribute for height/width. Same for type, which makes no sense
either. So eliminate those three.
goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'cellpadding': 'cellPadding',
'cellspacing': 'cellSpacing',
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'valign': 'vAlign',
'usemap': 'useMap',
'frameborder': 'frameBorder'
};
Nobody really cares about the old cellpadding (padding style) or
cellspacing (border-collapse style) or valign (vertical-align style)
attributes/properties. So this is left:-
goog.dom.DIRECT_ATTRIBUTE_MAP_ = {
'colspan': 'colSpan',
'rowspan': 'rowSpan',
'usemap': 'useMap',
'frameborder': 'frameBorder'
};
...accesskey, codebase, framespacing, maxlength, readonly, longdesc,
tabindex, ismap... Overlooked? I suppose it doesn't really matter
when you consider how this is used above. ;)
Google couldn't have budgeted more than a case of Ripple for this
(back in 2005). They got what they paid for. It was broken then and
it is even more so now, even in an IE8-only environment. (!) Hard to
believe they've been using this code for anything, but their
developers have probably been stepping on mines for years, creating
maps, passing along folklore, etc. Did nobody have time to look at
(or test) the code that creates DOM nodes in five years? I see a note
to go back and raid more fantasy code from MochiKit, which is a
further indication of staleness (not to mention apathy).
David Mark
It's not that much cruft, though any is too much IMO. Why put in
workarounds for things you don't use?
But the slowdown isn't an issue, even with the all the extra baggage
of a GP wrapper. I added times at the end of each set. In IE, as
expected (and regardless of mode), the wrappers are definitely several
milliseconds slower. Results vary from one load to the next, but the
direct method calls always win. It's about even in FF with the direct
method calls usually a bit faster and, oddly enough, reversed in Chome
where the wrappers are twice as fast as the direct method calls. YMMV
of course. And I think I'd be more confident in the comparison if it
looped through the 50 tests 100 times.
kangax
> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@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 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 ;)
--
kangax
kangax
> kangax wrote:
[...]
>>
>> There are rumors of Blackberry switching to WebKit in a very near future
>
No idea.
>
>>
>> There's no point in developing yet another proprietary engine.
>
> There may be a point for keeping Blackberry. If Blackberry is more
> efficient, the battery would last longer. With a smaller app footprint,
> the browser will launch faster. There may be other reasons related to
> the device hardware or OS.
That could be a reason, sure. But look at how poor its standards support
is: <http://www.quirksmode.org/m/table.html#link23>
It gets 14 on Acid 3, comparing to Iris' 100.
[...]
--
kangax
David Mark
> David Mark wrote:
> > On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@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
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?
Thanks for your help!
kangax
> On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@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
David Mark
> David Mark wrote:
> > On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@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. :(
David Mark
> David Mark wrote:
> > On Nov 28, 9:03 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 25, 12:42 pm, kangax <kan...@gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> On Nov 25, 2:37 am, Garrett Smith <dhtmlkitc...@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!
Garrett Smith
> Garrett Smith <dhtmlk...@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.
David Mark
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.
David Mark
>
> >> 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. ;)
kangax
> On Nov 28, 10:05 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 28, 9:03 pm, kangax <kan...@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
David Mark
> David Mark wrote:
> > On Nov 28, 10:05 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Nov 28, 9:03 pm, kangax <kan...@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.
kangax
Cell span attributes bad
48 tests, 23 failure(s), 0 skip(s)
--
kangax
David Mark
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.
David Mark
Okay, that should indicate the problem then. Thanks!
David Mark
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.
Thomas 'PointedEars' Lahn
> [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$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> On Nov 25, 12:43 pm, kangax <kan...@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
David Mark
wrote:
> David Mark wrote:
> > On Nov 25, 12:43 pm, kangax <kan...@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.
Thomas 'PointedEars' Lahn
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
David Mark
wrote:
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).
Thomas 'PointedEars' Lahn
> 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.
David Mark
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.
Thomas 'PointedEars' Lahn
> 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.)
David Mark
wrote:
> 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.
I see. Unfortunately, some browser developers (e.g. MS) don't see the
specifications as firm rules.
>
> >> > 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.
Interoperability through consistency is the point.
>
> >> > 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.
That's the point. My example is a replacement that does. As
mentioned, if the innerHTML were standardized to the point of
interoperability, this would be a moot point.
> But it does not need to nor would it appear that it was supposed to.
See directly above.
>
>
>
> >> > [...] 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.
So?
Obviously the former (or the value 0) does not make sense so
> it can be safely ignored for serialization.
The latter? How do you figure a default tab index of 0 makes no
sense? It makes perfect sense to me.
> Per HTML 4.01, it only needs to
> be considered for type="text" or type="password" anyway.
That illustrates just how old that spec is. It was just the starting
point. Obviously if you ignored tab index for all but text and
password inputs today, you would miss a lot of significant
information.
>
> As for the latter, if one were to avoid the attribute specification, when in
> doubt hasAttribute() or getAttribute() can be called for comparison.
Not sure what you mean about avoiding the attribute specification. As
for hasAttribute, that was introduced by MS in IE8 (standards mode
only). And, as I hope we all know by _now_ (two years since this
subject was brought up and beaten to death), get/set/removeAttribute
are all screwy in IE < 8 (and IE8 compatibility mode). So what are
you saying?
For a "Real World" example, at the recent jQuery attribute summit,
somebody pointed out that jQuery UI uses these DOM methods
(sparingly), but calls jQuery's odd assortment of "wrappers" more
often.
"47 occurrences of .attr() (a mix of string and object argument
syntaxes) and 12 .removeAttr()'s"
What does that tell you? It was determined by the panel that:-
"jQuery UI is more then expected to work browser independently, its
implied by its use."
I wouldn't expect their cunning plan to work any bettter than whatever
it is you mean by using has/getAttribute "when in doubt". My position
is there shouldn't be any real doubt about these methods at this
point.
>
> >> 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.
Discard at will. Like I said, never mind custom attributes.
Obviously, we are talking about the standard ones.
>
> >> 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.
That's your opinion.
>
> >> > 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.
Okay. :)
> If you want to prove something, prove it here.
I'm not trying to prove anything.
> If you do not want to repeat yourself too much, you can support the argument
> with a Message-ID to one of your postings.
Thanks.
>
> > 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.
What do you consider commonplace?
>
> >> > 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.
Exactly.
> You argument is too general to be useful, again.
I don't see that at all.
>
> >> > 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.
I don't see that either. I say no.
> Those two Specifications are the lowest common denominator.
You could still include custom attributes in a serialization. I'm not
saying it would be particularly useful though.
>
> >> > 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.
I made the point about the 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.
>
> I will look into it if and when I find the time. Until then, I will
> continue writing my own.
Look into what? There are some related wrappers in My Library (e.g.
getElementHtml, getElementOuterHtml).
>
> > If the host innerHTML properties were 100% consistent and standardized,
> > there would be no need for such a solution.
>
> Correct, but useless.
I don't follow that.
>
> >> > 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.
Well, then perhaps you haven't considered what goes into it. Think
about it.
>
> > 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.
Okay.
>
> > and imagine what you would need to do to duplicate it in IE.
>
> This is not a guessing game. Get to the point, please.
How would you duplicate any or all of those XPath tasks in IE?
>
> >> > Some purport to support both HTML and XML DOM's.
> >> So what?
>
> > So, you seem lost.
>
> Likewise.
Well, I'm not.
>
> >> > 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?
At this point, that's my line. :)
>
> And try to keep your quotes short, would you, please?
Sure.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> 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.
>
> I see. Unfortunately, some browser developers (e.g. MS) don't see the
> specifications as firm rules.
One can determine which default values of attribute properties are necessary
to include in the serialization and which are not.
>> >> > 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.
>
> Interoperability through consistency is the point.
However, this contradicts your requirement that there would need to be a
bijection between the element object and the serialization of it.
>> >> > 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.
>
> That's the point. My example is a replacement that does. As
> mentioned, if the innerHTML were standardized to the point of
> interoperability, this would be a moot point.
>
>> But it does not need to nor would it appear that it was supposed to.
>
> See directly above.
Still nobody needs that.
>> The default values for `maxLength' and `tabIndex' are -1 and 0 in a
>> Gecko- based browser.
>
> So?
>
>> Obviously the former (or the value 0) does not make sense so
>> it can be safely ignored for serialization.
>
> The latter?
No, the former, maxLength < 0 or maxLength == 0.
> How do you figure a default tab index of 0 makes no
> sense? It makes perfect sense to me.
Check your assumptions. tabIndex == 0 is the same as if the `tabindex'
attribute was not supported on an element or was not specified (omitted).
<http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex>
>> Per HTML 4.01, it only needs to be considered for type="text" or
>> type="password" anyway.
>
> That illustrates just how old that spec is.
No, if it illustrates anything then that it is the lowest common
denominator, the target for achieving interoperability.
> It was just the starting point. Obviously if you ignored tab index for
> all but text and password inputs today, you would miss a lot of
> significant information.
Not information significant to interoperability, which was the point of the
whole exercise.
>> As for the latter, if one were to avoid the attribute specification, when
>> in doubt hasAttribute() or getAttribute() can be called for comparison.
>
> Not sure what you mean about avoiding the attribute specification.
It means not serializing an attribute property and its value into
`attribute="value"' because it would not make a difference.
> As for hasAttribute, that was introduced by MS in IE8 (standards mode
> only). And, as I hope we all know by _now_ (two years since this
> subject was brought up and beaten to death), get/set/removeAttribute
> are all screwy in IE < 8 (and IE8 compatibility mode).
So "screwy" that you cannot use it to differentiate whether the attribute
was specified or not? I doubt it.
>> >> 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.
>
> That's your opinion.
Which should be relevant to you as you are discussing this with me. Unless
your purpose here is just to state something and to hell with the
contradictions.
>> If you want to prove something, prove it here.
>
> I'm not trying to prove anything.
What are you up to, then?
>> > 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.
>
> What do you consider commonplace?
Too general a description.
>> You argument is too general to be useful, again.
>
> I don't see that at all.
Well, you are talking rather nebulously about potential problems. Why not
take this opportunity to name some of the perceived problems explicitly and
concisely instead, to support your argument?
>> Those two Specifications are the lowest common denominator.
>
> You could still include custom attributes in a serialization. I'm not
> saying it would be particularly useful though.
Most importantly, it would not be interoperable, so we can safely ignore
them by default.
>> >> > 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.
>
> I made the point about the editor.
No, you failed to do that by asking a closed question which could be
understood as a red herring.
>> > If the host innerHTML properties were 100% consistent and standardized,
>> > there would be no need for such a solution.
>> Correct, but useless.
>
> I don't follow that.
While stating the obvious is no doubt a correct statement in itself, it does
not help with this discussion.
>> >> > 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.
>
> Well, then perhaps you haven't considered what goes into it. Think
> about it.
I am growing tired of your commonplace arguments.
>> > 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.
>
> Okay.
>
>> > and imagine what you would need to do to duplicate it in IE.
>> This is not a guessing game. Get to the point, please.
>
> How would you duplicate any or all of those XPath tasks in IE?
Type identifier is easy as is ancestor-decendant relationship. Attributes
are a bit harder, but not unsolvable.
That said, I would not even attempt using XPath in IE except for XHTML
served as text/xml or application/xml where there is a native
implementation. So you see, you are tackling the problem from the wrong
side: XPath in HTML is a (proprietary) bonus in Gecko (and perhaps in other
!MSHTMLs) that can be taken advantage of on occasion, not a lack in MSHTML
that needs to be compensated for.
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> 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.
>
> > I see. Unfortunately, some browser developers (e.g. MS) don't see the
> > specifications as firm rules.
>
> One can determine which default values of attribute properties are necessary
> to include in the serialization and which are not.
You don't know _which_ property values are defaults. For instance,
maxlength has a default of some very large number in MSHTML. And
this:-
<a href="..." tabindex="0">
...is not the same as this:-
<a href="...">
...and no, you cannot just go with the latter. :)
>
> >> >> > 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.
>
> > Interoperability through consistency is the point.
>
> However, this contradicts your requirement that there would need to be a
> bijection between the element object and the serialization of it.
You are very confused (and not making sense at all) Bijection?
>
> >> >> > 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.
>
> > That's the point. My example is a replacement that does. As
> > mentioned, if the innerHTML were standardized to the point of
> > interoperability, this would be a moot point.
>
> >> But it does not need to nor would it appear that it was supposed to.
>
> > See directly above.
>
> Still nobody needs that.
Those who would rely on CSS selector queries would certainly need it.
Same for an editor that must save its results.
And you said yourself that you would "refer" to hasAttribute and
getAttribute, when in "doubt". How would you do that if those methods
are missing or broken? :)
>
> >> The default values for `maxLength' and `tabIndex' are -1 and 0 in a
> >> Gecko- based browser.
>
> > So?
>
> >> Obviously the former (or the value 0) does not make sense so
> >> it can be safely ignored for serialization.
>
> > The latter?
>
> No, the former, maxLength < 0 or maxLength == 0.
Regardless, the default is some huge integer in MSHTML. Will you
throw out every value that is either very large or negative? :)
>
> > How do you figure a default tab index of 0 makes no
> > sense? It makes perfect sense to me.
>
> Check your assumptions. tabIndex == 0 is the same as if the `tabindex'
> attribute was not supported on an element or was not specified (omitted).
Nope. You are dead wrong on that. Leaving it off will disallow
tabbing to that element in some agents. And if it is not supported,
the property value is typically undefined. Also, leaving it off - for
example - a DIV will result in a default property value of -1 in some
agents. You've got nothing to go on.
It's really simple. Either you can serialize a document or you
can't. I've demonstrated how to do it (e.g. getElementOuterHtml in My
Library) and you have speculated how you might do it. I'm telling you
that your proposed algorithm will result in markup that looks like the
output of MS Word. :)
>
> <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex>
Forms? It's not as if form elements are the only concern for
tabindex.
>
> >> Per HTML 4.01, it only needs to be considered for type="text" or
> >> type="password" anyway.
>
> > That illustrates just how old that spec is.
>
> No, if it illustrates anything then that it is the lowest common
> denominator, the target for achieving interoperability.
All I am saying is that you could optionally allow non-standard
attributes.
>
> > It was just the starting point. Obviously if you ignored tab index for
> > all but text and password inputs today, you would miss a lot of
> > significant information.
>
> Not information significant to interoperability, which was the point of the
> whole exercise.
Wrong. See above.
>
> >> As for the latter, if one were to avoid the attribute specification, when
> >> in doubt hasAttribute() or getAttribute() can be called for comparison.
>
> > Not sure what you mean about avoiding the attribute specification.
>
> It means not serializing an attribute property and its value into
> `attribute="value"' because it would not make a difference.
Still not clear what you mean.
>
> > As for hasAttribute, that was introduced by MS in IE8 (standards mode
> > only). And, as I hope we all know by _now_ (two years since this
> > subject was brought up and beaten to death), get/set/removeAttribute
> > are all screwy in IE < 8 (and IE8 compatibility mode).
>
> So "screwy" that you cannot use it to differentiate whether the attribute
> was specified or not? I doubt it.
You better believe it. And if you don't, that explains your
"position" on this.
>
> >> >> 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.
>
> > That's your opinion.
>
> Which should be relevant to you as you are discussing this with me. Unless
> your purpose here is just to state something and to hell with the
> contradictions.
Your assertion about "general examples" has no technical meaning.
>
> >> If you want to prove something, prove it here.
>
> > I'm not trying to prove anything.
>
> What are you up to, then?
>
> >> > 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.
>
> > What do you consider commonplace?
>
> Too general a description.
Whatever.
>
> >> You argument is too general to be useful, again.
>
> > I don't see that at all.
>
> Well, you are talking rather nebulously about potential problems. Why not
> take this opportunity to name some of the perceived problems explicitly and
> concisely instead, to support your argument?
As you mentioned, you are way behind on this. Catch up and your
questions will have been answered.
>
> >> Those two Specifications are the lowest common denominator.
>
> > You could still include custom attributes in a serialization. I'm not
> > saying it would be particularly useful though.
>
> Most importantly, it would not be interoperable, so we can safely ignore
> them by default.
>
> >> >> > 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.
>
> > I made the point about the editor.
>
> No, you failed to do that by asking a closed question which could be
> understood as a red herring.
You just can't get your brain around this or you are deliberately
obfuscating the points made. I don't really care which at this point.
>
> >> > If the host innerHTML properties were 100% consistent and standardized,
> >> > there would be no need for such a solution.
> >> Correct, but useless.
>
> > I don't follow that.
>
> While stating the obvious is no doubt a correct statement in itself, it does
> not help with this discussion.
>
> >> >> > 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.
>
> > Well, then perhaps you haven't considered what goes into it. Think
> > about it.
>
> I am growing tired of your commonplace arguments.
There's that word again.
>
> >> > 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.
>
> > Okay.
>
> >> > and imagine what you would need to do to duplicate it in IE.
> >> This is not a guessing game. Get to the point, please.
>
> > How would you duplicate any or all of those XPath tasks in IE?
>
> Type identifier is easy as is ancestor-decendant relationship. Attributes
> are a bit harder, but not unsolvable.
Read that last bit again. You summarized my point exactly. Take it a
step further and realize that none of the "major" libraries have even
tried to solve it.
>
> That said, I would not even attempt using XPath in IE except for XHTML
> served as text/xml or application/xml where there is a native
> implementation.
Of course you wouldn't attempt to use XPath with MSHTML (for an HTML
DOM). That's why you would have to write an equivalent script. And
that requires...
> So you see, you are tackling the problem from the wrong
> side: XPath in HTML is a (proprietary) bonus in Gecko (and perhaps in other
> !MSHTMLs) that can be taken advantage of on occasion, not a lack in MSHTML
> that needs to be compensated for.
You clearly don't know what I'm doing or why. Strange.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> 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.
>> > I see. Unfortunately, some browser developers (e.g. MS) don't see the
>> > specifications as firm rules.
>> One can determine which default values of attribute properties are
>> necessary to include in the serialization and which are not.
>
> You don't know _which_ property values are defaults. For instance,
> maxlength has a default of some very large number in MSHTML.
I have to see it before I believe it.
> And this:-
>
> <a href="..." tabindex="0">
>
> ...is not the same as this:-
>
> <a href="...">
Yes, it is.
> ...and no, you cannot just go with the latter. :)
Yes, you can. The HTML 4.01 Specification is very clear about this. If
only one browser or whatever that is not Firefox/Iceweasel 3.5.6 (where I
have confirmed the Specification regarding this) differs here, then this
behavior would be a bug that does not need to be considered for an
`innerHTML' replacement that wants to be interoperable. IOW, the attribute
specification in question should not have been in the document in the first
place, so it can be safely omitted.
>> >> >> > 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.
>> >
>> > Interoperability through consistency is the point.
>>
>> However, this contradicts your requirement that there would need to be a
>> bijection between the element object and the serialization of it.
>
> You are very confused (and not making sense at all) Bijection?
Try a (mathematical) dictionary. Or Wikipedia.
>> >> `innerHTML' does not give "a clear view of the underlying document"
>> >> either.
>> > That's the point. My example is a replacement that does. As
>> > mentioned, if the innerHTML were standardized to the point of
>> > interoperability, this would be a moot point.
>> >
>> >> But it does not need to nor would it appear that it was supposed to.
>> >
>> > See directly above.
>>
>> Still nobody needs that.
>
> Those who would rely on CSS selector queries would certainly need it.
> Same for an editor that must save its results.
>
> And you said yourself that you would "refer" to hasAttribute and
> getAttribute, when in "doubt". How would you do that if those methods
> are missing or broken? :)
I think you are citing me out of context. But I see your point here.
>> >> Obviously [maxLength < 0 or maxLength == 0] does not make sense so
>> >> it can be safely ignored for serialization.
>> [...]
>
> Regardless, the default is some huge integer in MSHTML.
Starting with which version, on which element types? Not in 6.0.2800.1106
for `A' and INPUT elements, the default value is 0 there.
> Will you throw out every value that is either very large or negative? :)
It *might* be necessary to check the attribute specification
(attribute=value); however, if the default value is such a large value, and
there are different large default values on other elements in the same
document that correspond with their relative position in the document
stream, it can be safely included. Maybe it would not be pretty, but it
would not be harmful either.
>> > How do you figure a default tab index of 0 makes no
>> > sense? It makes perfect sense to me.
>>
>> Check your assumptions. tabIndex == 0 is the same as if the `tabindex'
>> attribute was not supported on an element or was not specified (omitted).
>
> Nope. You are dead wrong on that. Leaving it off will disallow
> tabbing to that element in some agents.
So we have either a bug or not Valid markup here, evidently ("some") not to
be considered for an interoperable solution.
> And if it is not supported, the property value is typically undefined.
So? !!undefined === false.
> Also, leaving it off - for example - a DIV will result in a default
> property value of -1 in some agents. You've got nothing to go on.
DIV elements do not have a `tabindex' attribute in Valid (X)HTML.
>> <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex>
>
> Forms? It's not as if form elements are the only concern for
> tabindex.
That does not matter.
>> >> Per HTML 4.01, it only needs to be considered for type="text" or
>> >> type="password" anyway.
>> > That illustrates just how old that spec is.
>>
>> No, if it illustrates anything then that it is the lowest common
>> denominator, the target for achieving interoperability.
>
> All I am saying is that you could optionally allow non-standard
> attributes.
By which you would be running the risk of losing interoperability, though.
>> > It was just the starting point. Obviously if you ignored tab index for
>> > all but text and password inputs today, you would miss a lot of
>> > significant information.
>>
>> Not information significant to interoperability, which was the point of
>> the whole exercise.
>
> Wrong. See above.
You are wrong.
>> >> As for the latter, if one were to avoid the attribute specification,
>> >> when in doubt hasAttribute() or getAttribute() can be called for
>> >> comparison.
>>
>> > Not sure what you mean about avoiding the attribute specification.
>>
>> It means not serializing an attribute property and its value into
>> `attribute="value"' because it would not make a difference.
>
> Still not clear what you mean.
Read the Specification, then. I cannot be more clear.
>> > As for hasAttribute, that was introduced by MS in IE8 (standards mode
>> > only). And, as I hope we all know by _now_ (two years since this
>> > subject was brought up and beaten to death), get/set/removeAttribute
>> > are all screwy in IE < 8 (and IE8 compatibility mode).
>>
>> So "screwy" that you cannot use it to differentiate whether the attribute
>> was specified or not? I doubt it.
>
> You better believe it. And if you don't, that explains your
> "position" on this.
I had to see it for myself with the form serialization already.
>> >> >> 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.
>> >
>> > That's your opinion.
>>
>> Which should be relevant to you as you are discussing this with me.
>> Unless your purpose here is just to state something and to hell with the
>> contradictions.
>
> Your assertion about "general examples" has no technical meaning.
Your examples are so general (if they qualify as examples at all) that they
have no meaning at all. That is the problem.
>> >> You argument is too general to be useful, again.
>> > I don't see that at all.
>>
>> Well, you are talking rather nebulously about potential problems. Why
>> not take this opportunity to name some of the perceived problems
>> explicitly and concisely instead, to support your argument?
>
> As you mentioned, you are way behind on this. Catch up and your
> questions will have been answered.
So far, with Valid markup, there is *one* buggy implementation (MSHTML) only
for which *some* approaches do not work as one would expect in *some*
versions of it, whereas the latter waits to be proved.
>> >> >> > 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.
>> > Well, then perhaps you haven't considered what goes into it. Think
>> > about it.
>> I am growing tired of your commonplace arguments.
>
> There's that word again.
Look it up.
>> That said, I would not even attempt using XPath in IE except for XHTML
>> served as text/xml or application/xml where there is a native
>> implementation.
>
> Of course you wouldn't attempt to use XPath with MSHTML (for an HTML
> DOM).
Yes, if an XML DOM, I would have said MSXML.
> That's why you would have to write an equivalent script. And
> that requires...
No, I mean I would not *use* XPath with MSHTML. The notation, not the DOM
feature.
David Mark
Is that supposed to be some sort of sick joke? If not, the debugger
is your friend. :) Or you could check here:-
http://www.cinsoft.net/attributes.html
"Fail: Input maximum length: 2147483647 is not null"
>
> > And this:-
>
> > <a href="..." tabindex="0">
>
> > ...is not the same as this:-
>
> > <a href="...">
>
> Yes, it is.
Not even close. I explained why.
>
> > ...and no, you cannot just go with the latter. :)
>
> Yes, you can. The HTML 4.01 Specification is very clear about this. If
> only one browser or whatever that is not Firefox/Iceweasel 3.5.6 (where I
> have confirmed the Specification regarding this) differs here, then this
> behavior would be a bug that does not need to be considered for an
> `innerHTML' replacement that wants to be interoperable. IOW, the attribute
> specification in question should not have been in the document in the first
> place, so it can be safely omitted.
Depends on your definition of "interoperable". :)
>
>
>
> >> >> >> > 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.
>
> >> > Interoperability through consistency is the point.
>
> >> However, this contradicts your requirement that there would need to be a
> >> bijection between the element object and the serialization of it.
>
> > You are very confused (and not making sense at all) Bijection?
>
> Try a (mathematical) dictionary. Or Wikipedia.
No thanks. You have to communicate your point more clearly.
>
>
>
> >> >> `innerHTML' does not give "a clear view of the underlying document"
> >> >> either.
> >> > That's the point. My example is a replacement that does. As
> >> > mentioned, if the innerHTML were standardized to the point of
> >> > interoperability, this would be a moot point.
>
> >> >> But it does not need to nor would it appear that it was supposed to.
>
> >> > See directly above.
>
> >> Still nobody needs that.
>
> > Those who would rely on CSS selector queries would certainly need it.
> > Same for an editor that must save its results.
>
> > And you said yourself that you would "refer" to hasAttribute and
> > getAttribute, when in "doubt". How would you do that if those methods
> > are missing or broken? :)
>
> I think you are citing me out of context. But I see your point here.
Okay.
>
> >> >> Obviously [maxLength < 0 or maxLength == 0] does not make sense so
> >> >> it can be safely ignored for serialization.
> >> [...]
>
> > Regardless, the default is some huge integer in MSHTML.
>
> Starting with which version, on which element types? Not in 6.0.2800.1106
> for `A' and INPUT elements, the default value is 0 there.
See above. And this attribute is just one example.
>
> > Will you throw out every value that is either very large or negative? :)
>
> It *might* be necessary to check the attribute specification
> (attribute=value); however, if the default value is such a large value, and
> there are different large default values on other elements in the same
> document that correspond with their relative position in the document
> stream, it can be safely included. Maybe it would not be pretty, but it
> would not be harmful either.
>
> >> > How do you figure a default tab index of 0 makes no
> >> > sense? It makes perfect sense to me.
>
> >> Check your assumptions. tabIndex == 0 is the same as if the `tabindex'
> >> attribute was not supported on an element or was not specified (omitted).
Nope. Unsupported means tabIndex === undefined. That's a different
story altogether.
>
> > Nope. You are dead wrong on that. Leaving it off will disallow
> > tabbing to that element in some agents.
>
> So we have either a bug or not Valid markup here, evidently ("some") not to
> be considered for an interoperable solution.
Fairly recent versions of Opera?
>
> > And if it is not supported, the property value is typically undefined.
>
> So? !!undefined === false.
What does that tell you?
>
> > Also, leaving it off - for example - a DIV will result in a default
> > property value of -1 in some agents. You've got nothing to go on.
>
> DIV elements do not have a `tabindex' attribute in Valid (X)HTML.
>
> >> <http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex>
>
> > Forms? It's not as if form elements are the only concern for
> > tabindex.
>
> That does not matter.
The other elements don't matter?
>
> >> >> Per HTML 4.01, it only needs to be considered for type="text" or
> >> >> type="password" anyway.
> >> > That illustrates just how old that spec is.
>
> >> No, if it illustrates anything then that it is the lowest common
> >> denominator, the target for achieving interoperability.
>
> > All I am saying is that you could optionally allow non-standard
> > attributes.
>
> By which you would be running the risk of losing interoperability, though.
Not really. Browsers throw out unrecognized attributes.
>
> >> > It was just the starting point. Obviously if you ignored tab index for
> >> > all but text and password inputs today, you would miss a lot of
> >> > significant information.
>
> >> Not information significant to interoperability, which was the point of
> >> the whole exercise.
>
> > Wrong. See above.
>
> You are wrong.
No I'm not. :)
>
> >> >> As for the latter, if one were to avoid the attribute specification,
> >> >> when in doubt hasAttribute() or getAttribute() can be called for
> >> >> comparison.
>
> >> > Not sure what you mean about avoiding the attribute specification.
>
> >> It means not serializing an attribute property and its value into
> >> `attribute="value"' because it would not make a difference.
>
> > Still not clear what you mean.
>
> Read the Specification, then. I cannot be more clear.
>
> >> > As for hasAttribute, that was introduced by MS in IE8 (standards mode
> >> > only). And, as I hope we all know by _now_ (two years since this
> >> > subject was brought up and beaten to death), get/set/removeAttribute
> >> > are all screwy in IE < 8 (and IE8 compatibility mode).
>
> >> So "screwy" that you cannot use it to differentiate whether the attribute
> >> was specified or not? I doubt it.
>
> > You better believe it. And if you don't, that explains your
> > "position" on this.
>
> I had to see it for myself with the form serialization already.
What is this new-found reliance on empirical evidence?
>
> >> >> >> 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.
>
> >> > That's your opinion.
>
> >> Which should be relevant to you as you are discussing this with me.
> >> Unless your purpose here is just to state something and to hell with the
> >> contradictions.
>
> > Your assertion about "general examples" has no technical meaning.
>
> Your examples are so general (if they qualify as examples at all) that they
> have no meaning at all. That is the problem.
That's odd. The meaning hit home for you on one of them (form
serialization) recently. You mentioned you don't do editors or
queries, so it's not that odd that you don't understand what I'm
talking about.
>
> >> >> You argument is too general to be useful, again.
> >> > I don't see that at all.
>
> >> Well, you are talking rather nebulously about potential problems. Why
> >> not take this opportunity to name some of the perceived problems
> >> explicitly and concisely instead, to support your argument?
>
> > As you mentioned, you are way behind on this. Catch up and your
> > questions will have been answered.
>
> So far, with Valid markup, there is *one* buggy implementation (MSHTML) only
> for which *some* approaches do not work as one would expect in *some*
> versions of it, whereas the latter waits to be proved.
No, there is one completely Broken as Designed implementation, which
can still rear its ugly head in IE8 (and is all you have in IE < 8).
Then there are a lot of buggy implementations.
>
>
>
> >> >> >> > 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.
> >> > Well, then perhaps you haven't considered what goes into it. Think
> >> > about it.
> >> I am growing tired of your commonplace arguments.
>
> > There's that word again.
>
> Look it up.
No, I don't think I will.
>
> >> That said, I would not even attempt using XPath in IE except for XHTML
> >> served as text/xml or application/xml where there is a native
> >> implementation.
>
> > Of course you wouldn't attempt to use XPath with MSHTML (for an HTML
> > DOM).
>
> Yes, if an XML DOM, I would have said MSXML.
And if you were trying to support both...
>
> > That's why you would have to write an equivalent script. And
> > that requires...
>
> No, I mean I would not *use* XPath with MSHTML. The notation, not the DOM
> feature.
Whatever. You will not be able to - for example - query elements by
attribute without something along those lines.