W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2010

Re: SVG/profiles/1.1F2/master coords.html,1.16,1.17 intro.html,1.25,1.26

From: Chris Lilley <chris@w3.org>
Date: Mon, 22 Nov 2010 23:12:39 +0100
Message-ID: <449250236.20101122231239@w3.org>
To: Cameron McCormack <cam@mcc.id.au>
CC: public-svg-wg@w3.org
On Friday, November 19, 2010, 7:54:25 PM, Cameron wrote:

CM> Hi Chris.

CM> Some comments on this change:

CM> Chris Lilley via cvs-syncmail:
>> +  <dd>
>> +    <p>
>> +      The rootmost
>> +      <a href="struct.html#SVGElement"><span class="element-name">'svg'</span></a>
>> +      element is the furthest
>> +      <a href="struct.html#SVGElement"><span class="element-name">'svg'</span></a>
>> +      ancestor element that does not exit an
>> +      <a href="intro.html#TermSVGContext"><span class="svg-term">SVG context</span></a>.
>> +      See also
>> +      <a href="intro.html#TermSVGDocumentFragment"><span class="svg-term">SVG document fragment</span></a>.
>> +    </p>
>> +  </dd>

CM> Is the definition of “rootmost ‘svg’ element” materially different from
CM> “outermost ‘svg’ element”, which is already in the spec?  It would be
CM> good to have only the one definition, if they are not.

I hadn't spotted that one. I agree it would be good to have just one definition. It would also be good for 1.1 and 1.2T to use the same term for the same thing.

In general the 1.2T definitions are more recent, benefit from later feedback, and are to be preferred. So I would be inclined to keep rootmost svg and update uses of outermost svg.

>> Index: coords.html
>> …
>> +<h2 id="IntrinsicSizing">Intrinsic sizing properties of the viewport of SVG content</h2>
>> +<p>SVG needs to specify how to calculate some intrinsic sizing properties  to
>> +enable inclusion within other languages. The intrinsic width and height
>> +of the <a href="intro.html#TermViewport"><span class="svg-term">viewport</span></a> of SVG content must be determined from the <a href="struct.html#SVGElementWidthAttribute"><span class="attr-name">'width'</span></a> and <a href="struct.html#SVGElementHeightAttribute"><span
>> +class="attr-name">'height'</span></a>
>> +    attributes. If either of these are not specified, the
>> +    lacuna value
>> +    of <span class="attr-value">'100%'</span> must
>> + be used. <em>Note:</em> the  <a href="struct.html#SVGElementWidthAttribute"><span class="attr-name">'width'</span></a> and <a href="struct.html#SVGElementHeightAttribute"><span

CM> SVG 1.1 doesn’t have the lacuna value definition.  I think we can just
CM> do s/lacuna// here.

I agree.

>> +  class="attr-name">'height'</span></a>
>> + attributes are <em>not the same</em> as the CSS width and height properties. Specifically, percentage values <em>do not
>> +provide an intrinsic width or height, and do not indicate a percentage of the containing block</em>. Rather, once the viewport is established, they indicate the portion of the viewport that is actually covered by image data.</p>
>> +
>> +<p>The intrinsic aspect ratio of the <a href="intro.html#TermViewport"><span class="svg-term">viewport</span></a> of SVG content is necessary
>> +for example, when including SVG from an object element in HTML styled with
>> +CSS.  It is possible (indeed, common) for an SVG graphic to have an intrinsic aspect ratio but not to have an intrinsic width or height.
>> +The intrinsic aspect ratio must be calculated based upon the
>> +following rules:</p>
>> +<ul>
>> +<li><p>The aspect ratio is calculated by dividing a width by a height.</p></li>
>> +<li><p>If the <a href="struct.html#SVGElementWidthAttribute"><span class="attr-name">'width'</span></a> and <a href="struct.html#SVGElementHeightAttribute"><span
>> +class="attr-name">'height'</span></a> of the <a href="intro.html#TermRootmostSVGElement"><span class="svg-term">rootmost 'svg' element</span></a> are both specified with 
>> +unit identifiers (in, mm, cm, pt, pc, px, em, ex) or in <a href="intro.html#TermUserUnits"><span class="svg-term">user units</span></a>, then the aspect ratio is
>> +calculated from the <a href="struct.html#SVGElementWidthAttribute"><span class="attr-name">'width'</span></a> and <a href="struct.html#SVGElementHeightAttribute"><span
>> +class="attr-name">'height'</span></a> attributes after resolving both values to user units.</p></li>
>> +<li><p>If either/both of the <a href="struct.html#SVGElementWidthAttribute"><span class="attr-name">'width'</span></a> and <a href="struct.html#SVGElementHeightAttribute"><span
>> +class="attr-name">'height'</span></a> of the <a href="intro.html#TermRootmostSVGElement"><span class="svg-term">rootmost 'svg' element</span></a> are in
>> +percentage units (or omitted), the aspect ratio is calculated from the width and
>> +height values of the <a href="coords.html#ViewBoxAttribute"><span
>> +    class="attr-name">'viewBox'</span></a> specified for the <a href="intro.html#TermCurrentSVGDocumentFragment"><span class="svg-term">current SVG document fragment</span></a>. If the <a href="coords.html#ViewBoxAttribute"><span
>> +    class="attr-name">'viewBox'</span></a> is not correctly specified, or set to <span class="attr-value">'none'</span>,
>> +the intrinsic aspect ratio cannot be calculated and is considered unspecified.</p></li>

CM> SVG 1.1 doesn’t have the ‘none’ value for viewBox.  I think we can just
CM> delete that parenthetical clause there.

Good catch, I agree also.

>> +</ul>
>> +
>> +<p>Examples:</p>
>> +
>> +<div class="example">
>> +<div class="exampleheader">
>> +<strong>Example:</strong> Intrinsic Aspect Ratio 1
>> +</div>
>> +
>> +<div class="examplesource">
>> +<pre><![CDATA[<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
>> +     width="10cm" height="5cm">
>> +  ...
>> +</svg>]]></pre>
>> +</div>
>> +</div>

CM> The styling of these examples doesn’t seem to match those in the rest of
CM> the 1.1 spec. 

Yes, I should have corrected that

CM Also I don’t think we should be using version="1.2"
CM> baseProfile="tiny" there.

(blush)

CM> I can make these changes if you agree.

I agree.



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Monday, 22 November 2010 22:12:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 November 2010 22:12:51 GMT