- From: Chris Lilley <chris@w3.org>
- Date: Tue, 21 Aug 2012 16:00:52 +0200
- 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? Sure. >> + <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><icccolorvalue></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"> >> + <number></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. OOps. CM> If you change the markup to just: CM> ... expressed as <a><number></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 > >> + <color-profile name="FooColors" href="http://swatches.example.com/Foo"/> >> + <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"><iri></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. OK -- 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