Re: Status of connectors for SVG2

Hi, Juergen–

I'm not sure how that's simpler… you're proposing changes to several 
existing elements (with all the issues of backwards compatibility and 
testing), rather than simply introducing a new element with the 
dedicated functionality.

The issue is not the complexity of the specification (it's not that 
complex), it's the lack of commitment from browser vendors to support 
it; they aren't opposed to it, but they aren't likely to implement it 
soon, either, so it's a matter of priorities in moving it forward.

Regards-
-Doug

On 7/10/14 9:45 AM, Juergen Roethig wrote:
> Hello world,
>
> Tavmjong Bah wrote:
>> On Wed, 2014-07-09 at 22:05 +0200, Juergen Roethig wrote:
>>>
>>> I was just missing something like a "connector" in SVG, and thus I
>>> checked whether there had been some porposals for that, before. I
>>> found one in
>>> [http://dev.w3.org/SVG/modules/connector/SVGConnector.html], but
>>> obviously this is not part of the current editor's draft of SVG 2,
>>> and it's rather old, although some newer proposal might be available
>>> in [http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml] (although the
>>> latter is not that "official" as the former). So, what's the official
>>> state of and/or opinion about something like a "connector" for/in
>>> SVG[2]?
>>
>> Connectors are being worked on as a separate module. There is support
>> for connectors within the working group but it is not a priority at the
>> moment (basically a lack of resources).
>>
>> The minutes from the last time we discussed connectors are at:
>>
>>     http://www.w3.org/2013/09/12-svg-minutes.html
>
> Thanks a lot for the information about the connectors' state! As far as
> I understood from reading, the "big" problems are the definition of the
> points ("ports") within a graphical object (<g>, <symbol>, whatever,
> ...), their relationship to that object (e.g. automatic positioning), as
> well as the routing of the connectors.
>
> My approach would be somewhat simpler: Make a new <point> element, with
> coordinates "x" and "y" as well as an "id" attribute (with a value of
> "point_id"), which might be used inside or outside of another graphical
> object (inside as a "port" for the object, and outside as a simple means
> for reference), and which will not be rendered (similar to "<symbol>"),
> and enhance the syntax of the "points" attribute (of "<polyline>" and
> "<polygon>"), and of the "d" attribute (of "<path>"), to allow a
> "pointref(point_id)" (or similar) to be used instead of a pair of
> coordinates, where applicable. Thus, I would not need a "<connector>"
> element, and the routing and design of the connector would be up to the
> author. And the "pointref" might be used everywhere within the path,
> even as a control point of a bezier curve, and not just as the start
> point or end point of a "connector" for which the shape would still have
> to be defined.
>
> Of course, the "<line>" element would also be a candidate to use such a
> "pointref", but in that case, a new attribute for <line> would be needed
> (or two new attributes, one for each endpoint 1 and 2, similar to
> "x1"/"y1" and "x2"/"y2"). I might be able to live without that ;-)
>
> Well, in that case, the implementation cost for the "connectors" should
> not be that huge ... basically, it's a new element "<point>" and a new
> form of giving point coordinates (as a "pointref") within "points" and
> "d" attributes.
>
> One might create a simple prototype for that by using XSL transformation
> to the "connector-enhanced" svg file ... maybe I will do that as an
> example, if time permits.
>
> Any opinions?
>
> Regards,
>
> Juergen Roethig
>

Received on Thursday, 10 July 2014 18:29:30 UTC