- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Wed, 6 Aug 2008 09:26:11 +0100
- To: Ken Stacey <ken@svgmaker.com>
- Cc: www-svg@w3.org
- Message-Id: <6FDAA351-5CFA-49C5-8BED-923615214C8A@btinternet.com>
Ken, your response whilst helpful** raises rather than relieves my concern. elsewhere Doug and others have expressed concern that of the graphic file formats only SVG content cannot be resized when referenced. I believe it was suggested that an addenda would be considered. furthermore <use> remote Jonathan Chetwynd j.chetwynd@btinternet.com http://www.openicon.org/ +44 (0) 20 7978 1764 **I had not appreciated that symbol had been dropped, whilst hardly essential symbol does provide useful semantic information. for instance hunting through code amongst id's and groups it may be difficult to identify whole 'symbols'. On 30 Jul 2008, at 05:56, Ken Stacey wrote: > > Hi Jonathan, > >> on what basis were height and width excluded for <use> in svg1.2 >> spec? > > It would appear to be on a technical basis. > > In 1.1 the width and height attributes of <use> are only meaningful > when referencing <svg> or <symbol> elements. The attributes are > used to form a new viewport for the referenced content. The width > and height attributes are not used for references to any other > elements. > > In 1.2T the <use> element cannot reference an <svg> element, and there > is no <symbol> element. There can be no new viewport, so the width > and > height attributes do nothing. > >> there is a clear use case that the author wishes to specify a >> different area to that in the remote file. > > Yes, there are use cases for specifying a new viewport. That is an > argument for allowing child <svg> elements in 1.2T. > >> it would also provide one method to specify the size of a checkbox in >> the case the resource is not loaded. > > In practice, the width and height attributes > a) may control the size of the referenced content (1.1 only) > b) may have no influence on the referenced content > c) may be absent > d) only one is present (subset of (a)) > > In case (a), there is a meaningful default region for fallback > content. Otherwise, only (b) is applicable for your method and in > this case the author is defining a known or nominal fallback region > of their choosing. > > Not so different to Doug's proposal (in part below) which goes a > long way to consistently addressing the issue for all elements which > can reference content > >> the user agent must display instead any fallback content supplied as >> a child of the element > > If the author wants meaningful fallback then the author can define > their own meaningful fallback. > > eg > <use xlink:href="another.svg#unresolved" x="50" y="50"> > <text x="10" y="20" font-size="10">:(</text> > </use> > > or > > <audio xlink:href="welcome.unsupportedaudioformat" begin="0s"> > <use xlink:href="#myMissingAudioIndicator" /> > </audio> > > > Ken Stacey > > > On 29/07/2008 8:15 PM, Jonathan Chetwynd wrote: >> My email was to erik, >> however... >> on what basis were height and width excluded for <use> in svg1.2 >> spec? >> there is a clear use case that the author wishes to specify a >> different area to that in the remote file. >> it would also provide one method to specify the size of a checkbox >> in the case the resource is not loaded. >> regards >> my logo <http://www.openicon.org> >> Jonathan Chetwynd >> j.chetwynd@btinternet.com <mailto:j.chetwynd@btinternet.com> >> http://www.openicon.org/ >> +44 (0) 20 7978 1764 >> On 29 Jul 2008, at 10:13, Doug Schepers wrote: >>> >>> >>>> the case against re-introduction of height and width needs to be >>>> stated clearly, hence my request to erik >>> >>> Your meaning here is unclear. > >
Received on Wednesday, 6 August 2008 08:26:56 UTC