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
