| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| ideas:functional-notation [2012/02/06 07:11] – [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). | - 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). |
| : ''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. |
| |
| |
