W3C home > Mailing lists > Public > www-style@w3.org > August 2011

RE: [css3-images] design of gradients and use of functions in CSS in general.

From: Brian Manthos <brianman@microsoft.com>
Date: Fri, 12 Aug 2011 20:34:26 +0000
To: Andrew Fedoniouk <news@terrainformatica.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D1711D6C2@TK5EX14MBXC264.redmond.corp.microsoft.com>
[1] I disagree.  Until the new before/after/start/end keywords were injected during the TeleCon, I was under the impression we were ready to move to WD and quickly to LC.  Brad, Tab, and I were on the same page at that point -- or so I thought.  [Minor editorial issues aside, I believe it was the 1.144 draft here: http://dev.w3.org/cvsweb/csswg/css3-images/Overview.src.html .]

[2] By design.  It's not designed to reimplement every possible syntax, or replace svg, etc.  That's my understanding at least.

[3] By design, see comment on [2].

[4] Incorrect.  There are multiple ways to address adding new fancy syntax in the future.  Such as...
	background-image: linear-gradient-named-parameters(...);

[5] My recommendation here is to propose some new syntax rules -- potentially available to all CSS properties -- that allow for naming the parameters.  If done cleverly, it might be extendable to shorthands as well.  Perhaps it's as simple as reserving colon (:) in parameter lists for functional syntax properties as a way of specifying which parameter is being set.  As long as the chosen syntax was explicitly invalid before these new syntax rules, there's no conflict / future-reliability issue.

[6] That sounds interesting for CSS4 (or later) consideration.  But let's not sacrifice CSS3 for it.

[7] We already can, see [4] and [5] comments.

[8] Looks like we agree on my comments to [5].  That doesn't imply we should rewrite (existing) or stall (pre-CR) properties that you find this alternative syntax useful for.

[9] There are many people to thank.  Many of them only chime in rarely with "hey, shouldn't we use a better rendering like this __". ;)

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Andrew Fedoniouk
> Sent: Friday, August 12, 2011 12:10 AM
> To: www-style@w3.org
> Subject: [css3-images] design of gradients and use of functions in CSS
> in general.
> 
[1]
> Looking on discussions around gradients in CSS I came up to conclusion
> that
> so high volume
> of issues and flames about it now will never lead to something solid in
> [nearest] future.
> 
[2]
> Problems as I see them:
> 
> 1. Chosen notation (function alike) is non-flexible and not adequate to
> the
> task of
>    defining such complex and multi-variant entity.
[3]
> 2. linear-gradient() covers only small subset of useful gradient cases.
> radial-gradient()
>    is in better shape but still not complete.
> 
[4]
> If we will accept the spec in the way it is written now we will
> probably
> solve some
> basic use cases but will create solution that will not be extendable in
> future due to
> #1 - bad, non-extendable notation.
> 
[5]
> Style definition as a collection of name/value pairs is "future-
> reliable" as
> we can extend
> set of properties without changing others. And gradient definition
> should
> use something
> like this as it is actually also a collection of orthogonal properties
> that
> define bunch of
> different color distribution functions.
> 
[6]
> I would suggest to consider functions with named arguments in CSS,
> something
> like this:
> 
>     gradient( type:linear,
>                     color-stops: red yellow green,
>                     from: top left );
> 
[7]
> This will allow to define what we want at the moment and to extend
> gradients
> in future.
> 
[8]
> In fact gradients are not the only things that require such extended
> function notation.
> Various layout methods - values of 'flex-flow' are better to be
> definable as
> such
> functions. Each flow may have its own and specific set of sub-
> properties -
> it
> is better to do not pollute main style properties name space. We are
> actually very
> close to the limit of meaningful names - we have at multiple properties
> with
> **-rows and **-columns names.  They cannot be applied at the same time
> -
> so they better to be sub-properties:
> 
>     flow: columns( column-widths: ... ; ruler: ... )
>     flow: template( 1 2, 4 3 );
>     flow: horizontal(dir:rtl);
> 
> and so on.
> 
[9]
> Brad did tremendous job with css3-images spec. We now better understand
> the
> problem. But means of implementation of the idea are not adequate.
> 
> 
> --
> Andrew Fedoniouk
> 
> http://terrainformatica.com
> 
> 
Received on Friday, 12 August 2011 20:34:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT