Re: svg2: merge in content from SVG Color

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.

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

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

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

OK.  I will work on the styling.

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

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

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?

No, that's not critical.

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

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

That might well be how we define it.  (See my other thread which you've 
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.

OK. :)


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

Thanks,

Cameron

Received on Wednesday, 22 August 2012 00:13:37 UTC