Clipboard paste support in SVG documents (was: SVG 2 is a Candidate Recommendation!)

Hello Domenico,

I'm not sure exactly what you're asking for.  SVG does not have any native
text-editing capability.  If you want something equivalent to HTML's
contentEditable attribute, that is a valid feature request for a future
version of SVG, but definitely won't happen for SVG 2.  You could make a
GitHub feature request here: https://github.com/w3c/svgwg/issues

More generally, if you're using JavaScript to create SVG applications that
allow you to paste from the system clipboard, you should be able to use the
standard DOM APIs to do so.  SVG 2 updated the SVG model for text selection
and clipboard operations to be consistent with the Selection API and
Clipboard API:

   - http://w3c.github.io/selection-api/
   - https://w3c.github.io/clipboard-apis/

Both of those documents are still working drafts.  If you discover specific
areas where those APIs do not make sense when applied to SVG, or where the
implementation notes in SVG 2 contradict those documents, please file
issues on both SVG and on the API spec.

However, with these new APIs, you should be able to paste content into an
SVG document and respond to that paste event using JavaScript.  If you
find, in practice, that the clipboard paste event is not being fired when
the keyboard focus is on an SVG element, then that is a browser failing to
fully implement the Clipboard API.  Please file a bug on the corresponding
browser.

As I mentioned, the Clipboard API spec is still in progress, so I would not
be surprised if browser implementations are currently buggy.  I've never
tested it out with SVG myself. But according to spec, the paste events
should fire based on user action (such a Ctrl/Cmd+V), regardless of whether
the target element is natively "editable" or not. That means that the
events should fire within SVG documents, even though SVG does not have any
native text-editing capabilities.  You would then have to use JavaScript to
respond to the event and access the pasted data, whether it is text, image,
or other media.

If you discover any other limitations of the Clipboard API and paste event,
when applied to non-HTML documents, please file an issue on that spec.
It's more likely to be implemented by browsers if it is part of that API,
than if it is proposed as a new paste behavior that's unique to SVG.  If
discussion based on that API concludes that extra details are needed in the
SVG spec, that would be something different.

I hope that helps direct you to more constructively address the
difficulties you are finding when building SVG applications.

In future, please do not drag down your valid feature requests with
personal attacks.  Tab Atkins is an active SVG working group participant.
For all discussions, everyone's opinion is their individual opinion, unless
it's a formal resolution of the working group.  But people (myself
included) tend to speak casually about what "SVG" or the working group is
likely to do, based on their current understanding of the group's
priorities.  Those statements should only be seen as predictions, not
commandments.  Even resolutions often get over-turned as priorities
change.  We should all be more careful to emphasize this when talking about
future plans.  But everyone's busy, and no one is perfect.  Getting
outraged at possibly-accidental offences only derails the discussion.

Best regards,
~Amelia Bellamy-Royds


On 11 October 2016 at 12:11, <nst@dotuscomus.com> wrote:

> In reply to my post http://lists.w3.org/Archives/
> Public/www-svg/2016Oct/0000.html I received this private answer by Tab
> Atkins:
>
> "SVG does not have an input model; that's HTML's domain, and SVG isn't
> going to duplicate efforts there.  The correct solution is indeed to
> have a bunch of <foreignObject> containing <input> elements (or
> <textarea>, or what-have-you).
>
> ~TJ"
>
> I don't find this suitable in its form or its contents, and I decide to
> answer publicly, like it's supposed to be.
>
>
> Tab,
>
> I do know that SVG does not have an input model. And I’m not asking for
> one.
>
> That's HTML's domain, though nothing, nowhere says it should be a
> prerogative of HTML.
>
> I do learn instead that opposition comes from someone (other than that,
> total silence), not from something. To be honest I already know that
> technically nothing opposes the implementation of pasting. Certainly not
> the fact that “SVG isn't going to duplicate efforts there”, that’s no valid
> argumentation. Moreover, it doesn’t really require any effort, and in any
> case it’s an effort for the implementers, so you don’t need to worry too
> much. You’ll be able to consecrate your efforts to your elucubrations on
> commas and spaces in CSS functions (a diversion: programmers are used to
> all sorts of delimiter symbols; they code and cannot waste their time
> discussing on why and when this or that symbol was adopted by this or that
> language. If you get lost with a couple of commas and spaces in
> parenthesis, you can start worrying about your capabilities).
>
> You don’t seem to be among either Invited Experts or Team Members of the
> SVG WG, Your name is in the list of individuals participating. How do you
> explain your peremptory denial? You don’t seem to be accredited for that.
>
> I do know you are involved with the CSS WG, though there too, as a
> participant, not as an invited expert or team member.
>
> A question to whomever is concerned: is the hierarchical structure of
> those groups effective, or just nominal? It would be good to get this
> clarified.
>
> Pasting needs to be added to the spec in the text operations section,
> because it’s missing.
>
> If you think that a “bunch” of <foreignObject> containing <input> elements
> is a viable solution for a datagrid for example, it means you really don’t
> know. But concretely speaking, you may find interesting to know that in
> Chrome (as well as in Opera unfortunately) margin-top is ignored (in FO),
> it does not work, whether expressed as such or in the collection of values
> for margin, for at least the elements body and table (it does work for the
> input element). So, currently foreignObject, in spite of its universal
> adoption, is not quite usable yet. Borderless inputs may “seem” viable, but
> the disparate interpretation of the size attribute and other rendering and
> positioning differences between the implementations, make that it is not
> concretely viable, meaning that one would be forced to destroy a
> geometrically precise layout to accommodate for the different
> implementation-dependent renderings. One shouldn’t have to explains these
> things in 2016.
>
> Let me remind (to all) the mission statement for the SVG Working Group:
> “The mission of the SVG Working Group is to continue the evolution of
> Scalable Vector Graphics as a format and a platform, …”. It says “platform”.
>
> The pasting capability in SVG is a legitimate request.  As far as I’m
> concerned it shouldn’t even need a discussion, least of all a gross
> dismissal, and should be done eagerly.
>
> But perhaps I should see here the sign of Google’s almighty hand over the
> W3C. An anecdotal parallel: one or two years ago, seemingly unable to
> complete its implementation, a Google team announced the deprecation of
> SMIL, and their intention to replace it with their own thing. Remaining
> insensitive to the many protests and opposing opinions by notable or
> accredited persons (they only ever cared to reply to some inquiring about
> the alternatives), they proceeded, only to inevitably find themselves in a
> cul-de-sac, as it was anticipated. Then they recently made a new
> announcement stating that they will not deprecate SMIL after all, but that
> they will in the future! That kind of obsessive stubbornness is typical of
> immature people. If you add bad manners, and incommensurable arrogance and
> ego, will we have to cope with this for long?
>
> Perhaps the best way now for me to try to avoid a Sacra Rota type of
> retaliation with some off track argumentation, is to say that I expect it.
> Perhaps nobody will care for that, but just in case, we could skip that
> phase altogether and care about the good evolution of SVG rather than
> having to cater for idleness and laziness.
>
> Domenico Strazzullo
>
>
>
>
>