Re: Proposal: Nesting SVG Graphics Elements

On Fri, Nov 30, 2012 at 8:38 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Thu, Nov 29, 2012 at 11:08 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>> Rik Cabanier:
>>> do you think extending the box model to SVG will make it faster to
>>> render?
>>> As soon as you allow <rect><text>..</text></rect>, people are going to
>>> want that rect to fit the text.
>>
>> Obviously it will take some computation to apply CSS layouts to SVG
>> content, but I wouldn't want content that doesn't use it to be slower.
>>
>> Whether the <rect><text>...</text></rect> syntax makes the rect fit the
>> text (as I understand Doug's proposal it doesn't), it makes a lot of sense
>> to me to be able to have a rectangle sized according to some text.  SVG
>> diagrams now just don't respond well different fonts available, localised
>> text, available space for rendering, etc.
>
>
> Maybe it doesn't, but judging by Tab's reaction, that is the first thing
> that people are going to want.
> They will want sizing/fitting/clipping of parents and children.
>
> As others in this thread have remarked, this is also changing the semantics.
>
> <rect><text>...</text></rect>
>
> implies that the rect contains the text.

While I do think that we should have more declarative
sizing/positioning in SVG (right now you are required to run script to
get anything but the bare minimum of responsiveness), I don't think
it's connected to this at all.  While it does seem attractive to
import something like the CSS box model, it's both not enough and too
much.  This kind of thing should be addressed by a constraint-based
system specialized for SVG.

(In any case, you can get boxes fitting around text by dropping a <p>
into your SVG, once we write up the text for direct inclusion of HTML
in SVG without an intervening <foreignContent>.  You still can't have
anything else react to the *size* of the box, but at least it'll
contain its text.)

This proposal is just an alternate, more easily-understandable, syntax
for grouping elements.  I've always found it bizarre, since I first
started working with SVG, that to tie the position of two elements
together you have to go through a <g> intermediary (which usually
means rewriting your markup to shift the original positioning from the
x/y attributes into a transform="translate()" on the <g> as well), and
that there is literally *no* way to tie together the sizes of two
elements without script.  Both of these make hand-authoring a
non-trivial SVG very fiddly, with a lot of repetition and possibility
for error as you edit things (and have to cascade that edit into a ton
of other related elements that are manually positioned/sized relative
to the first element).

Your and Dirk's argument that this somehow makes SVG slower to render
seem false.  In most cases (every case but <path>), the size and
position are trivially obtainable from the attributes.

~TJ

Received on Friday, 30 November 2012 17:35:42 UTC