- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 14 Dec 2009 16:49:04 +0100
- To: cyril.concolato@telecom-paristech.fr
- Cc: public-webapps <public-webapps@w3.org>
On Fri, Dec 4, 2009 at 5:04 PM, Cyril Concolato <cyril.concolato@enst.fr> wrote: > Dear Widgets-experts, > > While checking some of the tests, I found some unclear processing with > regards to the width and height attribute of widget element. The spec says: > > "If the width attribute is used, then let normalized width be the result of > applying the rule for parsing a non-negative integer to the value of the > attribute. If the normalized width is not in error and greater than 0, then > let widget width be the value of normalized width. If the width attribute is > in error, then the user agent must ignore the attribute." > > It explicitely says "greater than 0" which means that 0 should not be > allowed, but the test suite says for c9.wgt that the result should be 0. Argh. Right. > This seems inconsistent. On top of that, the spec seems to make the > distinction between 'null' (when in error) and '0' (not specified). From an > implementation point of view, I would prefer two cases: > - specified, not in error, greater than 0, width = the specified value > - in error or not specified, width = null, empty or 0. > Actually, I would prefer 0 since then the attribute can be implemented as an > integer not as a string. > > What do you think ? Given that a number of UAs have implemented support for getting back the value "0", I think we should just say "greater than or equal to 0". So: <widget width/height=""> = Error. value remains null. <widget width/height=" "> = Error, value remains null. <widget width/height="abc"> returns 0, value is 0. <widget width/height="100abc"> returns 100, value is 100. <widget width/height="000100abc"> returns 100, value is 100. However, I'm open to just saying return 0 upon error. More thoughts on this are welcomed from interested parties. -- Marcos Caceres http://datadriven.com.au
Received on Monday, 14 December 2009 15:50:03 UTC