Re: Rename 'd' property

Are folks generally in favor of having 'd' be an alias, in addition to a
better name?

On Mon, Feb 15, 2016 at 6:37 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> 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
>
>