Re: Rename 'd' property

[replies to Tab Atkins' comments]

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

The DOM interfaces are definitely an obstacle, though not necessarily an
insurmountable one.

By upgrading the geometry attributes to CSS properties, we have already
effectively made the corresponding DOM properties into aliases for CSSOM
getComputedStyle calls with type coersion.  The CSSOM properties will be
available on all elements, whether or not the aliases are.

The only other unique properties/methods on SVG shape elements are those
that relate to getting data about path length, and I'd really like to see
those generalized to all shapes, anyway. (Also the now-deprecated methods
for building a path by segment; they're replacement could be generalized!)

In other words, once all data about the shape of a SVG element is in CSS,
all the meaningful DOM interfaces could also be defined on a generic
interface, with the existing interfaces (based on the element tag name)
defined as subclasses for backwards-compatibility.

So possible, but a complete model is not likely to be worked out and ready
to go in the next few months. Hence my main point: let's try not to do
anything now that will make it difficult to overlay a comprehensive logical
model in the future.



> > 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. :/
>
>
I *had* thought of this, but somehow overlooked the key detail when I wrote
up my "rough draft".  You need an `auto` default value for `display-mode`
that means set the mode based on element namespace.

That way, if you set display without specifying a display-mode keyword, you
get the auto value:

display: none;
/* equivalent to display-mode: none; display-box-type: inline;
   nothing is displayed, so box-type is irrelevant */

display: block;
/* equivalent to display-mode: auto; display-box-type: block;
   for SVG element, it's now in SVG mode, box-type is again irrelevant */

display: svg;
/* could be used to create an SVG shape out of an HTML element or box-model
pseudo-element, instead of generating an SVG data URI background image */

display: box-model block;
/* used to turn an SVG element into a block container */





> > 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 all would of course merge into the SVG Layout spec idea, based on the
parent element's display mode versus the child element. E.g., if a child
element with `display-mode: box-model` is inside a parent with
`display-mode: svg`, define what the containing block is, and how the
x/y/width/height properties affect it.

Another reason why this was just a rough sketch of an idea, which stills
need work to create a complete model.


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

That's an important part of ensuring clarity in the future, but gets us
back to the original question. Should we use a generic name like `d` as a
property, and if so should we use it for multiple different features (path
geometry, text-path baseline shape, possibly others)?