Re: svg2: merge in content from SVG Color

On Wednesday, August 22, 2012, 2:13:06 AM, Cameron wrote:

CM> Chris Lilley:
>> 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.

CM> That is true.  I had actually copied the SVG 2 files for publication 
CM> before your colour changes were merged in.  Do you think we should 
CM> include them (now that I have to do some pubrules fixes to get the 
CM> document in order anyway)?

Yes, very much so.

CM> Actually, reading your later comments I think you did expect it to be 
CM> part of the FPWD.  I'll include it then, unless there are objections. 
CM> (Sorry for the obstinacy -- just trying to follow my rules for "did the
CM> WG review this section for publication".)

We did review the SVG Color material before deciding that it would be merged in. That was a while ago, admittedly.

>> 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> OK.  I will work on the styling.

A styling that I used in WOFF was a very faint, subtle background color change o hover - but also a more pronounced styling triggered by :target. So if you link to a particular conformance requirement then it is immediately clear which one was linked to. This avoids a lot of clutter. 

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

CM> OK.  (I must have forgotten.)

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

CM> Yes I think we can do that at our leisure.

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

CM> No, that's not critical.

OK good. (I was not disagreeing with adding rationale, by the way).

>>>>    <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> Let's discuss it in a telcon.

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

CM> That might well be how we define it.  (See my other thread which you've
CM> replied to...)

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

CM> OK. :)

The old property, which was dropped from CSS3 Color due to lack of implementations and also because experts told us it was a bad idea, applied to elements that reference an image (only) and allowed you to override the profile on a tagged image with a different profile.

This is a rare requirement, and it has been argued that if is bad practice (if the profile in the image is wrong, fix the image; it also means that images display one way in an image editor or viewer and a different way in SVG.

In its place though, and vastly more useful, is the conformance requirement that if an image is tagged, *use the profile in the image*. This is simple and obvious but needs to be explicitly stated so it is testable. It was not previously stated!

CM> Let me know if you're able to make the small changes (like the 1.2T 
CM> links) before tomorrow (Thursday being the current scheduled publication
CM> date, if I can get it in shape by then), otherwise I can do them.

Due to our timezone differences I'm catching up on the email exchange. Its Wednesday here and i will do them today.




-- 
 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 Wednesday, 22 August 2012 12:12:10 UTC