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

Re: svg2: merge in content from SVG Color

From: Chris Lilley <chris@w3.org>
Date: Tue, 21 Aug 2012 16:00:52 +0200
Message-ID: <35188085.20120821160052@w3.org>
To: Cameron McCormack <cam@mcc.id.au>
CC: public-svg-wg@w3.org
On Tuesday, August 21, 2012, 2:24:22 AM, Cameron wrote:

CM> Hi Chris,

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

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

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

Okay. But I had the action to merge it in and the WG resolved that it should be added. So it is not new text, and has been taken from a WD that the group has previously published.

>> +    <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>

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

I don't much care how they are styled, but I do care about marking up conformance requirements with a class and an id, and having tests link to them.

CM> Perhaps we can keep this styling in a separate style sheet, for readers
CM> who need to quickly identify where RFC2119-keyworded requirements are in
CM> 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>

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

Compared to SVG color, I changed Color-managed User Agent to SVG2 User gent. That one was missed, sorry.

>> +    <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>

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

No, it doesn't, and we previously agreed to include that grammar.

>> +    <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>

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

Okay, so it should be added (and perhaps some of the other classes dropped, although that dropping could occur after FPWD).

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

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

Do we need to add that for FPWD? 

>> +    <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>

CM> This is linking to SVG Tiny 1.2, but I think it should just be linking
CM> to our own <number> definition. 


CM>  If you change the markup to just:

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

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

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

OK I will look for those.

>> +    <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>

CM> Missing a ")" in the example.

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

CM> While I'm replying about this chapter, I want to ask whether we want to
CM> keep the <color-profile> element, or if we can just stick to having the
CM> @color-profile rule.

I wondered about that myself.

CM>   We already decided to drop the <font-face> element
CM> which was the analogue of @font-face.  I don't think there is much 
CM> 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 />

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

OK. I thought we were dropping xlink:href and then adding a note that it might be encountered in SVG 1.1 or in content that tries to be compatible with both 1.1 and 2; and should be treated like this ...

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

CM> Are we dropping this property?

Yes. It was dropped from CSS3 Color and was a really bad idea anyway.

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

CM> If I understand correctly, the default.css here was just a copy of the
CM> CSS module default.css.  I think we should make our styling changes just
CM> to default_svg.css, so that we can reimport any updated CSS default.css
CM> without too much fuss.


 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 Tuesday, 21 August 2012 14:00:53 UTC

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