W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2012

Re: svg2: merge in content from SVG Color

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 21 Aug 2012 10:24:22 +1000
Message-ID: <5032D536.4030304@mcc.id.au>
To: public-svg-wg@w3.org
CC: Chris Lilley <chris@w3.org>
Hi Chris,

Some comments on the Color stuff (hooray for merging it in!):

SVG Working Group repository:
> +  <div class="ready-for-wider-review">

I think this should be ready-for-wg-review (i.e., yellow background) 
since the WG hasn't signed off on it for publication yet.

> +    <div class="requirement" id="assert_taggedImages">
> +      <p>
> +        If a referenced image contains color profile information, a
> +        Color-managed User Agent MUST use that profile to render the image
> +      </p>
> +    </div>

These dark teal boxes with requirements in them -- I'm wondering if it 
is sustainable to have them styled like this.  The rest of the 
specification doesn't use RFC2119 keywords much, but if we increase 
their use across the document then there will be many such teal boxes.

Perhaps we can keep this styling in a separate style sheet, for readers 
who need to quickly identify where RFC2119-keyworded requirements are in 
the document?

> +    <div class="requirement" id="assert_untaggedImages">
> +      <p>
> +        If a referenced image contains no color profile information, a
> +        Color-managed User Agent MUST use the sRGB profile to render the image
> +      </p>
> +    </div>

Should "Color-managed User Agent" be replaced with one of the 
conformance classes we have in conform.html?  Or should a new 
conformance class be added to that appendix?

> +    <p class="note">See the CSS Color Module Level 3 specification for the
> +      definition of the color type.
> +      [<a href="refs.html#ref-CSS3COLOR">CSS3COLOR</a>]</p>

I was hoping that the <color> type in css3-color defined the grammar 
like you've included below, so that we could avoid duplicating it here. 
  But it doesn't look like it does.

> +    <div class="requirement" id="assert_base_syntax">
> +      <p>All the syntactic forms for an sRGB color, including the full set of color keywords, shall be supported by an SVG2 User Agent.</p>
> +    </div>

We should spell this "SVG 2" rather than "SVG2".  "SVG 2 User Agent" 
also isn't a conformance class in conform.html -- we probably need to 
take another look at that appendix and decide if we need so many classes 

> +    <p class="note">
> +      New in SVG2.</p>

If you could add a single sentence after the "New in SVG 2." to describe 
the reason we have added the feature that would be good.  (See the 
various "New in SVG 2" notes in painting.html for example.)

> +    <p>An SVG2User Agent directly uses the CIE LAB or CIE LCHab values, where the comma-separated list
> +      (with optional white space) of <strong>&lt;icccolorvalue&gt;</strong>'s is a set
> +      of Lightness, a and b or Lightness, Hue and Chroma values, expressed as <a href="http://www.w3.org/TR/SVGMobile12/types.html#DataTypeNumber">
> +      &lt;number&gt;</a>s. A color profile is not referenced in the SVG, although profile-based implementations may
> +    choose to implement this by providing and using an LAB profile.</p>

This is linking to SVG Tiny 1.2, but I think it should just be linking 
to our own <number> definition.  If you change the markup to just:

   ... expressed as <a>&lt;number&gt;</a>s. ...

then the build scripts will automatically link it to the right place. 
(Then when we eventually remove our own definition of <number> it will 
get updated to link to css3-values.)

(There are some other instances of linking to Tiny types too.)

> +    <p>Example:</p>
> +    <div class="example">
> +    <pre >
> +      &lt;color-profile name="FooColors" href="http://swatches.example.com/Foo"/>
> +      &lt;circle fill="#CD853F icc-color(FooColors, Sandy23C"/></pre>
> +      </div>

Missing a ")" in the example.

>   <h3 id="ColorProfileAlternatives">Alternative ways of defining a color profile description</h3>

While I'm replying about this chapter, I want to ask whether we want to 
keep the <color-profile> element, or if we can just stick to having the 
@color-profile rule.  We already decided to drop the <font-face> element 
which was the analogue of @font-face.  I don't think there is much 
benefit to having two ways to declare a color profile.

>   <edit:elementsummary name='color-profile'/>
>       <div class="adef-list">
>         <p><em>Attribute definitions:</em></p>
>         <dl>
> -        <dt id="ColorProfileElementHrefAttribute"><span class="adef">xlink:href</span> = "<span
> +        <dt id="ColorProfileElementHrefAttribute"><span class="adef">href</span> = "<span
>           class="attr-value"><a
>           href="types.html#DataTypeIRI">&lt;iri&gt;</a></span>"</dt>
>           <dd>The location of an ICC profile resource.<br />

If we do keep the <color-profile> element, should we be including both 
an xlink:href="" attribute (for existing content) and an href="" 
attribute?  We will probably be doing this for other more popular 
elements, and I think it would be good to treat all of the 
xlink:href=""s the same.

> -<h3 id="ColorProfile">The <span class="property">'color-profile'</span> property</h3>

Are we dropping this property?

> diff --git a/master/style/default.css b/master/style/default.css
> --- a/master/style/default.css
> +++ b/master/style/default.css

If I understand correctly, the default.css here was just a copy of the 
CSS module default.css.  I think we should make our styling changes just 
to default_svg.css, so that we can reimport any updated CSS default.css 
without too much fuss.
Received on Tuesday, 21 August 2012 00:24:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:15 UTC