| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| ideas:functional-notation [2012/02/06 06:15] – [General Principles] fantasai | ideas:functional-notation [2014/12/09 15:48] (current) – external edit 127.0.0.1 |
|---|
| ====== General Principles ====== | ====== Functional Notation Systematization ====== |
| - Lowest operator is comma | |
| - Lists of parallel items are comma-separated | ===== General Principles ===== |
| - Functions group/namespace a set of CSS-like values, and so should abide by general CSS value syntax principles | - Functions group/namespace a set of CSS-like values, and so should abide by general CSS value syntax principles |
| - Optionality is handled per #3, as far as possible | - Optionality is handled as for CSS values, as far as possible |
| - Ordering should be flexible as much as possible/prudent | - Ordering should be flexible as much as possible/prudent |
| | - Lists of parallel items are comma-separated |
| | - Lowest operator is comma |
| - Backwards compat should be preserved unless there's a very good reason otherwise | - Backwards compat should be preserved unless there's a very good reason otherwise |
| | |
| | More explanation: |
| | |
| | - Functional notation is a way of wrapping a subset of a property's value for labeling or grouping purposes. As such, it should generally follow the same design principles that property values do. As much as possible/prudent of the value should be optional and re-orderable, as long as it doesn't affect parsing (by producing ambiguity, or introducing look-ahead). |
| | - The comma should be used as a separator between parallel values (similar to background-*) or fallback values (similar to font-family). |
| | - Otherwise, values should be space-separated, as normal for property values. In general, the comma is the lowest-precedence operator in the grammar for a property. |
| | - When a function is overtly math-y, it may make sense to use commas to separate arguments, even if there's no other good reason to use a comma, just because it matches standard usage so well. (We're not quite certain of this - we might want to drop it.) |
| | - In rare cases, keywords may be used to prefix sets of values to allow unambiguous parsing. This should be avoided when possible; often, fixing a particular order for the values or making some of the values required can remove ambiguity. Only when it's very valuable for the values to be optional or reorderable should this be considered. |
| | |
| |
| http://lists.w3.org/Archives/Public/www-style/2012Jan/0933.html | http://lists.w3.org/Archives/Public/www-style/2012Jan/0933.html |
| : ''translate(<x> <y>)'' | : ''translate(<x> <y>)'' |
| ; Rationale | ; Rationale |
| : The comma isn't needed for grouping or disambiguation. Other places in CSS that accept an x and y length space-separate, like 'border-spacing' and 'background-position'. (Principle 2) | : The comma isn't needed for grouping or disambiguation. Other places in CSS that accept an x and y length space-separate, like 'border-spacing' and 'background-position'. |
| ; Extra Note | ; Extra Note |
| : The same applies to ''scale()''. | : The same applies to ''scale()''. |
| : ''steps(<number> && [start | end]?)'' | : ''steps(<number> && [start | end]?)'' |
| ; Rationale | ; Rationale |
| : The comma isn't needed for grouping or disambiguation. The ordering constraint can also be relaxed without ambiguity. (Principles 2 and 3.1) | : The comma isn't needed for grouping or disambiguation. The ordering constraint can also be relaxed without ambiguity. |
| | |
| --- | --- |
| |
| |
| ===== Exclusions ===== | ===== Shapes ===== |
| ; Before | ; Before |
| : ''rectangle(<length>, <length>, <length>, <length> [, [<length>,] <length>])'' | : ''rectangle(<length>, <length>, <length>, <length> [, [<length>,] <length>])'' |
| : ''polygon([<fill-rule>,]? <length>{2}# )'' | : ''polygon([<fill-rule>,]? <length>{2}# )'' |
| ; Rationale | ; Rationale |
| : Same as ''cubic-bezier()'', but moreso - a list of points should be indicated with different separators between the components and the points, or else a long list becomes //unreadable// without writing conventions or manual counting. ''<fill-rule>'' doesn't need a comma for disambuation, but we left it in due to Principle 1 and to match the gradient functions. | : Same as ''cubic-bezier()'', but moreso - a list of points should be indicated with different separators between the components and the points, or else a long list becomes //unreadable// without writing conventions or manual counting. ''<fill-rule>'' doesn't need a comma for disambuation, but we left it in due to Principle 3 and to match the gradient functions. |
| |
| |
