Re: PRE.width (Re: Minutes from telcon 20020920)

On 24 Sep 2002, Philippe Le Hegaret wrote:
> Do you have a detail report for Konqueror?

Here's the current status.

I. Remaining bugs to be fixed in Konqueror:

- HTMLLabelElement01: <label> should be treated as a form element (it has
no "form" property at the moment)
- HTMLOptionElement04: Konqueror displays the contents of the "label"
attribute, for <option> elements. Mozilla doesn't. I re-read the spec, and
I think even though it says browsers should display that value, it
implicitely says "when used withing <optgroup> only". This would need to
be clarified IMHO. If that's the case, this is indeed a Konqueror bug.

II. Dubious tests ;)

- HTMLIsIndexElement02 says that an <isindex> out of a form should have 0
for its form property. But to handle such elements properly, we
auto-generate a form around it, and treat it as a form element, so its
form property is actually set. Is it necessary to test for form==0 in such
a case?
- HTMLInputElement13 number vs string, see below.

III. Things to be investigated:

- HTMLDocument02 expects the referrer to be empty. In Konqueror it's set
to ...../tests/document.html. I'm not sure if that's right or wrong yet.

All the other failures & errors (we have currently 31 in all) are in table
stuff. I'm investigating those right now, but most do look like Konqueror
bugs.

> btw David, I'd like to have your input on:
> http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0177.html
[The string vs number issue]

Interestingly, I raised this problem too, a few days ago (in my post about
HTMLInputElement13).

From a purely Javascript point of view, it doesn't matter much (the value
is converted from number to string and vice-versa); the test only fails
because it actually compares the types, but this doesn't make websites
fail.
However we also provide a C++ DOM implementation, and in that one it's
important to get the types right.

IMHO: this all comes from HTML, in which attributes are strings. Even if
in the current version only a number makes sense, future versions of HTML
might allow different values for those attributes, e.g. including unit
names (like in CSS, 400px vs 400mm etc.)
I would say, better treat those as strings, even if only for future
extensions. Of course this means the "users" of those DOM methods must do
a conversion to number, and test if that worked... that's the price of
flexibility. But if such extensions are for sure ruled out, better have
them as number, that's easier to handle.

David.

Received on Tuesday, 24 September 2002 14:28:18 UTC