Re: 300x150 px defaults too aggressive

Bjoern Hoehrmann wrote:
> * Jonathan Watt wrote:
>>> Is there some up to date description that defines the various intrinsic
>>> properties of the SVG document? For example, per section 6.17 of SVG 1.1
>>> I would arrive at a different conclusion than you do above,
>> http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing
> 
> My understanding is that that text is not up to date. For example, in
> <http://lists.w3.org/Archives/Public/www-svg/2007Jan/0032.html> (which
> is a public version of the message I pointed out earlier) we learn:
> 
>   Also, in the course of our discussion with Fantasai, we discovered
>   that the SVG specs were not sufficiently clear that percentage
>   values in the SVG root width and height attributes do not specify
>   an intrinsic width and height. We have resolved to add text to that
>   effect, and hope that this clarifies matters for all involved.
> 
> Contrary to that, you assume that the intrinsic width in your example
> is 100%. This probably does not affect your specific example, but has
> major implications for other content. Not knowing the current inter-
> pretation, we cannot fully evaluate the impact of changes.

No, I only assume that there is no intrinsic ratio, and that's clearly and 
explicitly stated to be the case by the SVG section linked above.

Whether the SVG specification defines percentage lengths to define intrinsic 
lengths or not would not change my example or the issue it raises. Either way, 
we'd still have the case where there is no intrinsic ratio, but the CSS auto 
length has an intrinsic length it could use instead of the fallback length.

If we were to change the 'height' attribute in my example to have a percentage 
value then whether 150px or the percentage value is used would depend on whether 
the SVG spec says percentage values are intrinsic or not. This doesn't detract 
from my point that there would still be the case where there is an intrinsic 
length available when a non-percentage value is used.

>> Although it's SVG that has brought this to my attention, I don't think this is 
>> necessarily an SVG issue. It's simply an issue of the CSS spec covering the 
>> cases where replaced elements have only _one_ of intrinsic width or intrinsic 
>> height, and no intrinsic ratio - a case that doesn't seem to have been considered.
> 
> I agree that the proposed change has consequences beyond SVG, but in
> order to evaluate the proposal, we should first evaluate the effect
> it would have on SVG-based content.

Fair enough. As an SVG implementer that has lately been spending considerable 
time on implementing SVG-as-a-replaced-element I'll assert that the effect is 
clearly an improvement in my view. I don't see how this change is anything other 
than obvious, so I'm not sure how better to explain why, but maybe that's 
because I've had my head in this for so long.

> As for not considering the case,
> author intuition was less a concern than having reasonably simple and
> complete rules that the SVG, CDF, and CSS Working Groups can agree to
> (which they did, after much discussion).

This addition seems very simple and obvious to me while also eliminating a 
potential annoyance for authors. I don't see any conflict. I've read a 
considerable number of threads from the archives on the SVG, CDF and CSS 
discussions on replaced element rules and my suggested addition seems to fit 
right in. Additionally, it only requires four straightforward lines to implement 
(in Mozilla).

>> The less contrived case would be when the SVG is embedded by reference and the 
>> CSS is on the embedding element (e.g. HTML <object>).
> 
> I would like an example that demonstrates why the issue you raised is
> or will be a problem in practise. For example, there may be a case
> where a specific effect can only be achieved using code structured
> like your example. If your case is just some rare edge case that does
> not occur in practise, it might be best to reject the proposal.

I can imagine authors creating SVG that has a fixed width but 
unknown/variable/large (scripted scrolling?) height. It might make sense to set 
the intrinsic to thus be 100%. When embedded by reference the author may wish to 
override the height (since it's scrolled?) but maintain the intrinsic width. An 
SVG sidebar menu springs to mind, but I'm not too imaginative. I do feel that 
this is a valid use case though, and that authors would not want the intrinsic 
width annoyingly overridden with the fallback of 300px.

Jonathan

Received on Tuesday, 18 September 2007 09:58:43 UTC