Re: [compositing] More feedback on property definitions

On Thu, Jan 10, 2013 at 8:37 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Can the 'mix' property syntax get simplified more from:
>
>         <mixarea> = <area>? && <blendmode>? && <composite>? && <isolation’>? && <knock-out’>?
>
> to:
>
>         <mixarea> = <area> || <blendmode> || <composite> || <isolation> || <knock-out>

This is not only simpler, but also more correct.  The current spec
allows you to specify *none* of the possibilities, so that "mix: , , ,
,;" is valid according to the grammar.  ^_^

(Also, <mixarea> should be called <mix-area>, to be consistent with
our treatment of multi-word grammar terms.)

> ?
>
> There are some typos
>         s/<isolation’>/<isolation>/
>         s/<knock-out’>/<knock-out>/

This appears to be a typo, but not in the way you suggest.  He's
trying to refer to the value of the named property, which is written
<'isolation'> (contrast with <isolation>, which would be an
explicitly-defined grammar term).  It's possible that this was a
mistake caused by whatever preprocessor he used?

> And mistakes:
>         <blendarea> = <area>? && <blendmode> on 'mix-blend-mode', but both are listed in the 'mix' property syntax (<area> should be removed there).
>         <isolate> and <knock-out> are not specified (should be done on the longhand properties).
>         ‘knock-out' property syntax should change from: preserve | knock-out to <knock-out>#
>         'isolate' property syntax should change from: auto | isolate to <isolation>#

Given these latter two (which are correct), though, the spec does
indeed need to explicitly define an <isolation> and <knock-out> term,
so that the grammar of the property can be "isolation: <isolation>#",
and the grammar of "mix" can use the <isolation> token.

>         Value keywords on 'isolate' and 'knock-out' property are not in quotes, the value in Initial is, should be consistent (think it is usually not in quotes in definition tables).

Yes, we don't put quotes around keywords in the definition tables.

>         "In SVG, only ‘element’ is supported." This distinction can not be done on parsing CSS. So it should say that for SVG 'element' is used independent of the author specified value.

Correct.

>         "In SVG, it applies to all container elements except ‘mask’" this is a repeating pattern. Looking at the definition of 'container element' (‘a’, ‘defs’, ‘glyph’, ‘g’, ‘marker’, ‘mask’, ‘missing-glyph’, ‘pattern’, ‘svg’, ‘switch’ and ‘symbol’.), there seems to be more elements where it does not make sense.

Yes, I suggest defining a term (or seeing if SVG already has such a
term defined) and using that to restrict the definition.  That way, in
the future we can simply extend that term, rather than having to
correct every instance of the limitation.

> Question (snippets):
>         Does the blend mode value description stay <blendmode>, or should it be <blend-mode>? The same question for a bunch of other value definitions. IIRC other CSS specifications use a dash (<blend-mode>, <mix-area>, <knock-out>,...).

Yes, dashes should be used.  ("knockout" versus "knock-out" is more
controversial, because it might be one word.  I leave that up to Rik's
discretion.)

>         Should <composite> be <composite-mode> for consistency, or <alpha-compositing>?

Given that the corresponding token for blending is called <blendmode>
(should be <blend-mode>), yeah, I'd go with calling it
<composite-mode>.

~TJ

Received on Thursday, 10 January 2013 18:45:02 UTC