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

Hello Amelia,


My first post was very sweet and the request very simple. In return so far
I got neither the same tone nor a good answer. In the doubt I will consider
your intervention positive, though the scolding bit is just a little over
the top...


Please trust that there’s no need for you to tell me much about what SVG
has or has not.


You say “I'm not sure exactly what you're asking for”, but then you propose
directives. Thank you anyway.


JavaScript is not at all a concern. The clipboard methods work in an
osmotic way across the browsers.


Regarding your redirections to specifications and drafts, the terms
“editable context” and “editing host” invariably and specifically refer to
HTML. In any case here:

https://w3c.github.io/clipboard-apis/# in the paste procedure section
(6.1.3) you can read

“If there is a selection or cursor in an editable context”.


Selection and ranges are indeed there and working for a regular SVG 1.1
text element, already. The editable context is not there in SVG. Why bother
then to update SVG with features that are context dependent, if that very
context is not there? I’m not trying to be sarcastic, I do know that the
update is in the scope of the greater design of things to come, like you
suggest. In the meanwhile some simple things could be done rather easily,
one of which being the object of my request.


It appears that the obstacle is represented by the fact that no SVG text
element (old or new) constitutes an editable context, yet. But that term
must be understood as a designation, it is nothing more than that in the
theory. In the practice it would possibly be followed by the concrete
implementation of full editing capabilities, or partial, or even
minimalist, however long that would take.


The sheer fact that the browsers already implement methods to
programmatically manipulate the clipboard, implies that the agent
establishes the editing capability, de facto, which hopefully doesn’t come
as a surprise to anyone.


Then when you say “SVG 2 updated the SVG model for text selection and
clipboard operations to be consistent with the Selection API and Clipboard
API”, that also implies that SVG has to be tributary of HTML (since the
primary target for those APIs is HTML), a thing that was denounced as a
dubious strategic choice in due time, and that was due to some obscure
design, to the detriment of true advancement.


A reality is instead that programmers needing to port their applications
from the desktop to the web realistically know now that they were misled to
use HTML-CSS. An ever growing number of them are finally starting to make a
proper assessment and see SVG as the natural platform by vocation, the one
that is truly close to the programming language-OpenGL paradigm. Let’s
leave momentarily this vast subject for a future debate in its own right.


I see then that the obstacle is only a protocolar obligation, or
bureaucratic if you prefer. In other words, SVG should have to patiently
wait for all the many HTML idiosyncrasies to be resolved (is it just an
impression that the more we advance in time the more they proliferate?).
When I read things like this: “ContentEditable is too complex and buggy to
be usable as-is. While we could solve this by spec'ing contentEditable's
behavior, the remaining issues here cause us to look in a new direction
instead.” (https://w3c.github.io/editing/#editing-host) then I’m scared,
not meaning to say that I’m not used to this. I could provide other
magnificent examples like the reinvention of keyboard events.


But if we try to see things from a different angle, SVG can very well, and
actually should, recover its total independence from miserable HTML
intestine wars, in every respect, including that of the editing model. If
it’s true that its specification would have to take its own course, I do
believe that nothing at the technical level would prevent the browsers from
implementing paste (and cut) along with copy somewhere along the line. Now
for example.


The only dependence that makes sense for SVG is the one towards its
bindings, notably SMIL and JavaScript with its SVG DOM. The HTML shadow
over SVG is just dogmatic, with no “real” or legitimate foundation, a
shadow that slows down progress, which is notoriously something that cannot
be done.


Please, do not propose any longer the argument of full editing
capabilities, unless you are absolutely positive that would be indeed the
condition sine qua non. If it’s the case, I would like to know who
officially takes responsibility for such a statement.


Let me try now to reformulate the request: in SVG the user should ideally
be able to paste (and cut) without any intervention from the developer
through JavaScript. Since selection and ranges are successfully implemented
in SVG, my guess is that implementing paste should be possible without the
need for full editing capabilities –a thing that, I reiterate, I never
asked, though I agree with you that would be a valid feature request for a
future version of SVG, and that I discussed here only because you and the
previous interlocutor brought it up.


To resume in a simple concept: require the agents to implement paste, and
possibly cut, along with copy.


Best regards,


Domenico Strazzullo



*From:* Amelia Bellamy-Royds
*Sent:* Tuesday, October 11, 2016 9:57 PM
*To:* nst@dotuscomus.com ; www-svg
*Subject:* 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
>
>
>
>
>