- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 10 Sep 2009 10:29:16 +0200
- To: public-webapps <public-webapps@w3.org>
On Wed, Sep 9, 2009 at 5:55 PM, Marcos Caceres <marcosc@opera.com> wrote: > During testing I discovered that the preference element is under specified > (sorry, y'all!). It is not clear what the user agent is supposed to do when > encountering the following: > > > <preference name="a" value="a"/> > <preference name="a" value="b"/> > <preference name="a" value="c" readonly="true"/> > <preference name="a" value="d"/> > <preference name="a" value="e" readonly="false"/> > > Options: > > 1. <preference name="a" value="a"/> wins (subsequent repetitions are > ignored by the UA, which is how non-repeat elements work already). > > 2. the 'widget preferences list' end up with 5 preferences named "a", but > with different values. Then the Widgets A&E spec can sort out the mess. > > 3. Each subsequent repetition resets the value of the preference, and if it > is read-only or not. In the following case, when value is set to d, the use > agent sets will set the readonly value to 'false': > > <preference name="a" value="b"/> > <preference name="a" value="c" readonly="true"/> > <preference name="a" value="d"/> > > > My preference is 3 because that is how I would expect it to behave. However, > 1 might be more "correct". > After some discussion with Artb on IRC [1], we concluded that option 1 above is the preferred behavior (it is consistent with the behavior of other elements). I will specify that behavior in the P&C Test Suite Edition. If anyone objects, please speak up quickly. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 10 September 2009 08:30:16 UTC