Re: Rename 'd' property

On 17 February 2016 at 20:57, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> [Replies to Sebastian Zartner's comments]
>
> I like the idea of the 'geometry' property, though I dislike the
>> overlapping of function and keyword names for circle, ellipse and rect.
>> I believe it would be better to reuse the functions defined in the CSS
>> Shapes module[1].
>>
>> E.g. the UA stylesheet rule for <circle> elements may look like this
>> then:
>>
>> circle {
>>   geometry: circle(attr(r) at attr(cx) attr(cy));
>> }
>>
>
> The `cx`, `cy`, `r` properties, etc., have already shipped in at least two
> browsers (WebKit & Chromium). So any new property would need to reference
> them.
>

The requirements for using the above syntax is in what extent the 'cx',
'cy' and 'r' properties are already used by content and whether
implementors are willing to replace them in favor of 'geometry' and
allowing shape functions in it.
Btw., 'cx', 'cy', 'r', 'rx' and 'ry' are also good candidates for renaming
(or aliasing), as their meaning as CSS property names (outside of the
context of their related SVG elements) is unclear.

Regarding the 'geometry' property, if it's not possible to reuse the shape
functions, the keywords should be changed to resolve the naming conflict
with the shape functions.

We then need one final master property to turn on all these SVG-specific
>>> rendering commands. Something I've talked with Tab about previously is to
>>> do this with the `display` property.
>>>
>>
>> I assume this discussion is related to the CSS Display module[2], right?
>> It sounds like this point is out of scope of this discussion to be talked
>> about separately.
>> ...
>> Can you elaborate a bit more on this? What is the problem of being able
>> to toggle the display off without changing the box model?
>>
>
> Yes, it is related, and definitely stretches outside of the scope of SVG.
> A different approach than the `box-suppress` method described in CSS
> Display, but it would address the same goal. But it would also address the
> issue that most of the `display` values are completely irrelevant and
> ignored for SVG, while providing a way for SVG-namespaced elements to
> "opt-in" to the CSS box layout model as part of an alternative textual
> display.
>

Ah, right. Now I remember the discussion and the obstacles about 'display'
currently serving multiple purposes.

Sebastian