W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: [compositing] More feedback on property definitions

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 14 Jan 2013 12:22:02 -0800
Message-ID: <CAGN7qDA0cpOoRUobMiemNXp3_x_2tFs6pRU6YVFO7EJeXkqnJg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
Thanks for all the feedback!
I fixed all the typos and dashing problems. Let me know if you find more.

On Thu, Jan 10, 2013 at 10:44 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

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

I changed this to the following:

<mix-area> = <area>
<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#ltareagt>?
&& [<blend-mode>
<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#ltblendmodegt>
|| <composite-mode>
<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#ltcompositegt>
|| <isolation-mode>
<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#isolated-propid>
|| <knock-out-mode>
<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#knockout-propid>]

With your suggestion it's possible to write:

mix: element, background

which makes nonsensical.


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

I agree that SVG should define something like this.
In addition, it would be great if there was a up-to-date list of CSS
constructs that  create stacking contexts.


>
> > 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 Monday, 14 January 2013 20:22:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 January 2013 20:22:29 GMT