On 9 Dec 2009, at 23:34, Marcos Caceres wrote:

On Wed, Dec 9, 2009 at 2:46 PM, Robin Berjon <[email protected]> wrote:
On Dec 9, 2009, at 14:31 , Cyril Concolato wrote:
Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say:

Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used.


I agree that the strict ordering is irrelevant because of the reason
Cyril mentioned. And yeah, I agree that having multiple icon choices
was probably stupid idea :(But can we give it a month to see if anyone
does anything interesting with multiple icons in a list?). If everyone
ignores multiple icons, then we will chuck it out. A quicker route
might be to ask implementers what they want... I know that Robin wants
them gone, at least.

Cyril and Scott, is this feature any use to you? I'll ask the Bondi
guys (I've CC'd David).

I think having a list of icons in different sizes is useful for rendering widget galleries, so to that extent its useful (assuming most widget developers will not use SVG no matter how often they're told its good for them :-).

I do wonder however about the extent to which developers will want to produce localized icons for widgets, as its not really something in common practice now; localization of widgets tends to be mostly focussed on text labels rather than graphics. Is this feature in anticipation of a change of practice, or is it already common in some communities?

Exposing lists of icons in our gallery metadata - for the delivery platform to select which ones to display to users - is not a big deal technically and I can see apps using Wookie could make use of it.


--
Marcos Caceres
http://datadriven.com.au

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to