W3C home > Mailing lists > Public > www-dom-ts@w3.org > September 2002

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

From: David Faure <david@mandrakesoft.com>
Date: Tue, 24 Sep 2002 21:08:33 +0200 (CEST)
To: Philippe Le Hegaret <plh@w3.org>
cc: <www-dom-ts@w3.org>
Message-ID: <Pine.LNX.4.33L2.0209242058140.12160-100000@smtp.mandrakesoft.com>

On 24 Sep 2002, Philippe Le Hegaret wrote:

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

No, it also affects the result of myOption.text, and that's why the test
fails. Konq returns the value of the label attribute ("l1"), since that's
the text it displays, but the test expects text="EMP10002" instead.

Does it sound correct to say that a browser should ignore the label
attribute for <option> if the option isn't inside an <optgroup>? I'm not
very familiar with optgroup...

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

Is there any way to get this corrected in the HTML spec?

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

Hmm, indeed. So returning a number does make things easier.
And the DOM0 compat is another reason to do so.
Future extensions will have to use another attribute then ;)

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

That sounds great to me. Feel free to send me updated tests when this
change is done (I guess it must be changed in the HTML spec too...).

Received on Tuesday, 24 September 2002 15:06:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:05 UTC