RE: Constrained specification of Icon element

2009-11-19 Thread Ola Andersson
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 PC 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
 



Re: Constrained specification of Icon element

2009-11-10 Thread Ola Andersson
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 PC spec states for the icon width/height attributes: The width 
http://dev.w3.org/2006/waf/widgets/#width0  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...) 

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): 

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. 

Best regards
/ola andersson


[1] http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementWidthAttribute


2009/11/2 Magnus Olsson magnus.ols...@ericsson.com 
mailto:magnus.ols...@ericsson.com?subject=re%3a%20constrained%20specification%20of%20icon%20elementIn-Reply-To=%253Cb21a10670911060819t2ef5d143u54092e173ab1a549%40mail.gmail.com%253EReferences=%253Cb21a10670911060819t2ef5d143u54092e173ab1a549%40mail.gmail.com%253E
 

  The icon element 
 (*http://dev.w3.org/2006/waf/widgets/#icon0*http://dev.w3.org/2006/waf/widgets/
  
 http://dev.w3.org/2006/waf/widgets/#icon0*%3Chttp://dev.w3.org/2006/waf/widgets/
  )
 has width/height properties which only applies to SVG icons. To me the spec
 isn't fully clear how to use them. Is it ok for a user agent to ignore the
 width/height of an SVG icon? IMO it should be since it will be hard to do a
 consistent widget desktop manager with widgets from multiple sources (and
 therefore possibly with different width/height set) if the widget icons are
 of different sizes. To me the width/height should just be a guide to the
 user agent but the user agent should have the choice of scaling to the
 appropriate size. This is of course also important for widgets intended to
 run on multiple platforms with different screen sizes.


Yes, the user agent can decide how best to treat icons based on the
available size. Where the width and height help is to establish the viewport
(the window in which the SVG will be rendered).  So, if an SVG declares
itself to be 1000 by 1000px (svg width=1000 height=1000 ...), but the
width and height of the icon both say 100 pixels, then the rendered
representation of the SVG will simply get clipped because it won't fit in
the 100 by 100 viewport.

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


___

Ola Andersson 
Senior System Manager 
Solution Area TV (SATV)
BU Multimedia Products (BMUM)

Mobile: +46 761 441320
Email: ola.anders...@ericsson.com

Ericsson AB
Tellusborgsvägen 83-87
SE-126 37, Stockholm, Sweden
www.ericsson.com