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

On Tue, 2002-09-24 at 14:30, David Faure wrote:
> 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.

If it's a display problem, then it falls outside the scope of the DOM
imho. seems more an HTML issue.

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

I tend to agree with you that it seems a bug in the HTML spec rather a
pb in the DOM module.

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

except for mathematical operations of course.

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

As I replied to Glenn, DOM0 defined height and width as numbers and the
spec is committed to be backward compatible with DOM0. Regarding future
versions of HTML, ie XHTML, we only support XHTML 1.0, others are not
supported by the DOM HTML module. The remaining question is: should we
synchronize all vspace/hspace/height/width/border for
images/applets/objects? The conclusion from the call suggested that we
probably should for consistency.


Philippe

Received on Tuesday, 24 September 2002 14:44:01 UTC