Excellent! I'm happy with this. cheers /o
> > Hi Ola, > Apologies for the delay in replying. I, and others, agree > with your presented use cases and have changed the spec to > match. Please see comments below. Can you please get back to > us ASAP confirming that you agree with the changes. We intend > to republish this specification next week, but we must have > confirmation from you that you are satisfied with the changes. > > 2009/11/10 Ola Andersson <ola.anders...@ericsson.com>: > > Hi, > > I understand it might be too late to modify the spec now > but I still think the spec isn't clear with regards to <icon> > size and should be clarified, maybe in some future version at > least. I'm also not fully convinced your description (bottom > of this mail) about clipping an SVG icon is correct. This is > because the Widget P&C spec states for the <icon> > width/height attributes: "The width is only applicable to > graphic formats that have no intrinsic width or height (e.g., > SVG)." However, SVG do have intrinsic size when SVG > width/height are specified [1] (except in the case when > widht/height are %-values) so the widget spec might want to > clarify this and your example below should, according to the > <icon> definition, ignore the <icon> width/height and render > the icon using the intrinsic 1000x1000px size. > > > > To me this behavior is not what you want, rather I propose > the following changes to the <icon> size: > > > > 1. For the widget <icon> element's width and height attributes the > > spec should state that the width and height attribute > values are to be > > seen as a guide to the UA in order for the widget provider > to indicate > > the preferred size of the icon. The UA is allowed to ignore the > > width/height in order to change the size of the icon, > exampels of when > > this might occur is if a UA is to display icons from different > > providers in a single GUI (and thus prefer to display them > all at the > > same size). Or if a UA needs to enlarge icons in a GUI due to > > accessability requirements (vision impaired users...) > > > > Agreed. > > > 2. icon width/height attributes should apply to all graphic > formats, not just those without intrinsic size. Having this > would make it possible to reuse the same icon resource for > multiple resolutions. The following example (almost from the > widget spec): > > > > Agreed. Removed restriction on usage of the width and height > attribute (applies to all graphic formats). > > > Ok, the spec now reads: > > [ > Width/Height > A numeric attribute greater than 0 that represents, in CSS > pixels [CSS21], the author's preferred width/height for the > icon. A user agent may ignore this value when changing the > height icon to fit a rendering context or for accessibility reasons. > ] > > > > <icon src="icons/big.png"/> > > <icon src="icons/medium.png"/> > > <icon src="icons/small.png"/> > > > > could then be rewritten as: > > > > <icon src="icons/big.png"/> > > <icon src="icons/big.png" width="128" height="128"/> <icon > > src="icons/big.png" width="64" height="64"/> > > > > Which would save the author the work of creating different > pngs, and save bandwith. All UAs have features for raster > scaling so no issue with that. > > > > I think in the above cases the author would just declare (and > the UA would just use the icon in all contexts): > > <icon src="icons/big.png"/> > > A more complicated example would be: > > <icon src="icons/big.png"/> > <icon src="icons/medium.png"/> > <icon src="icons/big.png" width="16" height="16" /> > > However, I do not see a need to add such complexity to the > spec. In other words, though I have changed the definition of > the icon width and height, I am reluctant to change the > parsing model to allow the same icon to be declared more than > once (as above). > > Kind regards, > Marcos > > -- > Marcos Caceres > http://datadriven.com.au >
