W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Constrained specification of Icon element

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 19 Nov 2009 13:14:05 +0000
Message-ID: <b21a10670911190514p37976591s3db8629564952d8a@mail.gmail.com>
To: Ola Andersson <ola.andersson@ericsson.com>
Cc: public-webapps <public-webapps@w3.org>
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.andersson@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
Received on Thursday, 19 November 2009 13:14:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT