Microsoft and attributes--will they ever figure them out?

[Thomas 'PointedEars' Lahn]

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.

You are very confused (and not making sense at all) Bijection?

Try a (mathematical) dictionary. Or Wikipedia.

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.

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.

Forms? It's not as if form elements are the only concern for
tabindex.

That does not matter.

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.

Wrong. See above.

You are wrong.

Still not clear what you mean.

Read the Specification, then. I cannot be more clear.

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.

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.

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.

There's that word again.

Look it up.

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.


PointedEars

 

[David Mark]

I have to see it before I believe it.

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"

Yes, it is.

Not even close. I explained why.

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

Try a (mathematical) dictionary.  Or Wikipedia.

No thanks. You have to communicate your point more clearly.

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

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.

Nope. Unsupported means tabIndex === undefined. That's a different
story altogether.

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?

So?  !!undefined === false.

What does that tell you?

DIV elements do not have a `tabindex' attribute in Valid (X)HTML.



That does not matter.

The other elements don't matter?

By which you would be running the risk of losing interoperability, though..

Not really. Browsers throw out unrecognized attributes.

You are wrong.

No I'm not.

Read the Specification, then.  I cannot be more clear.



I had to see it for myself with the form serialization already.

What is this new-found reliance on empirical evidence?

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.

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.

Look it up.

No, I don't think I will.

Yes, if an XML DOM, I would have said MSXML.

And if you were trying to support both...

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.