Re: Rename 'd' property

On Sun, Feb 14, 2016 at 11:53 PM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
> A new property "geometry" defines the shape which will be filled and
> stroked.  It can accept a shape function, such as path(…) or polygon(…) or
> ellipse(…), but it can also take simple keywords `circle`, `ellipse`, or
> `rect`, which mean "use the computed values for the
> cx/cy/r/rx/ry/x/y/width/height properties, as appropriate". Geometry can
> also be `text` or `children`, the final value being appropriate for <g> or
> <svg> elements.

Can't do it, or at least not in any sane way.  A <circle> isn't just
rendered as a circle, it's also backed by an SVGCircleElement object.
If you changed the 'geometry' for an element, its backing object no
longer makes any sense, and its JS properties no longer correspond to
anything useful (except perhaps by accident, if both shapes share a
given attribute).  (And we can't swap out the backing object based on
CSS, believe me, or else Custom Elements would be a lot easier in many
ways.)

So as much as I like the idea of 'geometry' theoretically, the shapes
of SVG elements and the properties they use are based on the element
name, nothing else.

> 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. `display` is currently a hodgepodge of two
> different concepts: (1) is an element rendered or not, and (2) if the
> element is rendered AND it uses a CSS box model, which box model type should
> it use.

Three, actually - whether it generates a box, how it lays out its
children, and how it interacts with the layout of its parent.  We've
already split out the "do you generate a box" property in the Display
module <https://drafts.csswg.org/css-display/#box-suppress>, and have
decided to only semi-split the latter two - they're split at the value
level, but still operate in a single property so we can control the
combinations a little better.

When I write the SVG Layout module (eventually) we will need a
property to opt an element into it - SVG layout is just a slight
variant on abspos. Unfortunately this can't be 'display', for legacy
reasons - right now, you can set any 'display' value on an SVG element
and it sets the property but has no effect.  We'll need to invent
something new, unfortunately, which sucks. :/

> It would also enable the original plan from SVG 1.1, that an alternative
> stylesheet should be able to make SVG title+desc text visible instead of
> graphics.

Once the SVG Layout spec is done, this shouldn't be too hard
theoretically. It should be okay to swap a SVG element to generating a
CSS box instead of an SVG shape, because we don't expect any SVG
properties to affect CSS layout.  (In other words, this doesn't suffer
from the same problem that 'geometry' does. The backing object will
have some useless properties, but the element can still be fully
controlled with CSS as usual for CSS boxes.)

> This may all be too different and complicated for SVG 2, but I would at the
> least like to consider the possibility, so we don't create new conflicts
> like using a single `d` property to define completely different features on
> <path> versus <textPath>

>From now on we'll just never reuse an attribute unless it's identical.

~TJ

Received on Tuesday, 16 February 2016 02:38:48 UTC