Re: SVG's future

The last WG telcon was held December 22. Their frequency has dropped since
this discussion last October [1], and some discussions in the following
telcons were alarming, and even defined as “depressive reading”. Following
which, on December 9  Amelia eagerly proposed three avenues for community
members wanting to move SVG forward [2]. Nice, but unfortunately useless in
the absence of political will –or, worse, in the presence of antagonist
strategies– from the authorities and the vendors.


There were two threads and seven posts on this list in January, three of
which related to this thread.


So far there has been only one thread in February (this discussion), and
the totality of the posts relates to it.


There are five participants in this discussion.


I propose (before we look like fools) that either we take a resolution,
like for example decide to contact ECMA or whatever, or split from this
empty room (we can always jump back in if the sudden drop in activity is
just an unfortunate coincidence).

Final question: are we willing to concretely try to secure the SVG
specification and its destiny into better hands?


[1] https://lists.w3.org/Archives/Public/www-svg/2016Oct/0033.html
[2] https://lists.w3.org/Archives/Public/www-svg/2016Dec/0005.html

On Tue, Feb 7, 2017 at 5:04 AM, グルチヤンラミン <ktecramin99@gmail.com> wrote:

> I am wondering when people from svg will finally comment on this.
> For sure there must be a 'need' for writing standards.
>
>
> 2017-02-06 5:00 GMT+09:00 Domenico Strazzullo <
> strazzullo.domenico@gmail.com>:
>
>> Sebastian,
>>
>> I read you. But please believe that all that kind of debating does at
>> this point is shift the focus from the essential point. Olaf is basically
>> complaining, and he's just right to do so. People have the right to know.
>>
>> For the adoption of SVG over the years you can take a look at the number
>> of members of different lists, and how those figures grew, sometimes
>> exponentially following constructive announcements.
>>
>> Domenico Strazzullo
>>
>> PS: your vision on the sax is funny :) the keys were designed to normally
>> be under the fingers! I'm not so sure it would be easier to play
>> reshuffling the keys... Plus, more than the physical difficulty to get a
>> sound, to be able to play a jazz solo requires to know music well, harmony,
>> etc. Lots of study, and in no way that can be made easy. The same with any
>> scientific or artistic discipline, it's not a question of easy or
>> difficult, you study hard and with passion, and with miles of practice it
>> eventually becomes easier. Nobody is forced to do that. There are easier
>> activities available.
>>
>>
>>
>> On Sun, Feb 5, 2017 at 8:06 PM, Sebastian Zartner <
>> sebastianzartner@gmail.com> wrote:
>>
>>> Hi Domenico,
>>>
>>> On 5 February 2017 at 14:26, Domenico Strazzullo <
>>> strazzullo.domenico@gmail.com> wrote:
>>>
>>>> Sebastian,
>>>>
>>>> On Sat, Feb 4, 2017 at 11:02 PM, Sebastian Zartner <
>>>> sebastianzartner@gmail.com> wrote:
>>>>
>>>>> On 3 February 2017 at 12:07, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
>>>>> wrote:
>>>>> >  Sebastian Zartner:
>>>>> >
>>>>> >>
>>>>> >> The authors should identify why there is no strong interest in
>>>>> >> implementing SVG 2's features.
>>>>> >>
>>>>> > ...
>>>>> >
>>>>> >
>>>>> > My impression was, that for example Opera gave up Presto (with the
>>>>> currently
>>>>> > still best SVG implemention, including parts of SVG tiny 1.2 - here
>>>>> we have
>>>>> > already the mentioned vector effects defined and in SVG tiny 1.2
>>>>> viewers
>>>>> > implemented as far as defined), because they had no money anymore and
>>>>> > not enough users for their commercial products.
>>>>> > This was not related to SVG itself, but maybe it was related, they
>>>>> tried to
>>>>> > follow standards, but other vendors had more success with
>>>>> proprietary stuff and
>>>>> > control of their customers ;-)
>>>>>
>>>>> Sure, companies live from their customers. And it's the decision of
>>>>> the customers which products they use.
>>>>>
>>>>> I have the impression you are trying to imply that the eventual
>>>> removal of SVG should be simply considered, and accepted as, a fatality.
>>>>
>>>
>>> Not at all. I was actually advocating for the implementation of SVG 2
>>> features in different places already.
>>>
>>>  SVG is not a product, and its users are users, not customers. SVG is
>>>> an open source specification, and we don’t need to reiterate here the
>>>> advantages of open standards vs proprietary, nor their very reason of
>>>> existence, which you seem to put back in question with expired
>>>> argumentation.
>>>>
>>>> > Companies like Microsoft, Apple, Google,  Adobe, Amazon etc obviously
>>>>> prefer
>>>>> > their own products and formats to ensure, that they can control and
>>>>> abase
>>>>> > their customers and addicted people, therefore it is natural to
>>>>> undermine and
>>>>> > erode independent standards.
>>>>>
>>>>> It's clear that the big players have the most influence on the
>>>>> standards. But, as said above, it's up to the users which products to
>>>>> use.
>>>>
>>>>
>>>> Not quite so. The users, as consumers, use what is proposed to them.
>>>> But not even that! The question here is not what is proposed to them, it is
>>>> about a widely adopted tool that is being dropped for reasons that are
>>>> contrary to the commitment the vendors had agreed to make toward standards.
>>>> By keeping explaining the market mechanisms you are not helping resolve the
>>>> question on the legitimacy of this move, which is one of the core
>>>> questions. Olaf is expressing his opinions on what he thinks is *right* or
>>>> *wrong*, *ethical* or *illicit*
>>>>
>>>
>>> There is no instance in telling whether it is right or wrong, ethical or
>>> illecit keeping to the standards defined by the W3C specifications or not.
>>> To get a higher, independent institution to take over the
>>> standardization, you may initiate a petition.
>>>
>>> while you keep replying *why* that happens. We all know *why*, since a
>>>> few thousand years back. If we always accepted the *why* as a fatality,
>>>> humanity would have remained locked into one single paradigm. That is not
>>>> exactly the spirit of democracy and progress.
>>>>
>>>>
>>>>> So, in the end, it's up to the users who has the most influence.
>>>>> Back in the days when Mozilla released the first versions of Firefox,
>>>>> it was successful enough that it took more and more people away from
>>>>> IE, so that in the end Microsoft could not push its proprietary
>>>>> standards anymore and had to start opening up to keep to the standards
>>>>> of others.
>>>>>
>>>>> So on the grounds of market share we are supposed to accept and
>>>> justify it if Microsoft puts up its act again?
>>>>
>>>
>>> Of course not. And Microsoft also wouldn't have a chance anymore if it
>>> made its own thing again. Microsoft has to cooperate and keep with the
>>> standards to stay competitive in the browser market.
>>>
>>> > The HTML5 tag soup specification instead of only defining a simple new
>>>>> XHTML
>>>>> > variant with a thought out concept to markup text in a semantic way
>>>>> is a good
>>>>> > example, intentionally it is designed so complex, that new vendors
>>>>> are
>>>>> > frustrated to attack the oligopoly with an independent new and own
>>>>> viewer.
>>>>>
>>>>> Well, Mozilla is still there as the only independent choice. But, of
>>>>> course, it's hard for new vendors to get into this market and get
>>>>> enough user base to have something to say regarding the standards.
>>>>>
>>>>> > Trying to jam in SVG with obfuscated notation into the HTML5 tag
>>>>> soups,
>>>>> > removing XLink syntax, SMIL, SVG fonts is an attempt to get the same
>>>>> situation
>>>>> > for SVG.
>>>>>
>>>>> I claim removing the XLink syntax is a step forward regarding
>>>>> simplicity
>>>>
>>>>
>>>> Why should SVG be simple?
>>>>
>>>
>>> Because a simple format is more likely to be accepted. Asked the other
>>> way round. What would have been the benefit of keeping the XLink syntax?
>>>
>>>
>>>> How could that be? Things can be simple or complex, their degree of
>>>> difficulty is subject to the fluency of the executant. Would you think that
>>>> removing one key from a sax will allow a non-musician to play a jazz solo?
>>>>
>>>
>>> That comparison is incorrect. A better comparison would be that the key
>>> of the sax is placed on a better reachable position, so it's easier to play
>>> the instrument.
>>>
>>> Likewise, if anyone thinks that SVG becomes any simpler by not having to
>>>> write xlink, he/she will be deceived.
>>>>
>>>> and acceptance of SVG.
>>>>
>>>>
>>>> To the best of my knowledge SVG has been widely accepted, do you have
>>>> different figures?
>>>>
>>>
>>> I don't have numbers, but since SVG can be embedded into HTML now, it's
>>> easier for authors to work with it. So, I'm sure this step made it wider
>>> used as before.
>>> Do you have any numbers?
>>>
>>>
>>>> If not, why do you advance such an argument? Here too you are
>>>> obfuscating the salient point in Olaf’s sentence. Are you doing this on
>>>> purpose?
>>>>
>>>
>>> Olaf claims that HTML5 is a "tag soup", which is an opinion, which is
>>> definitely not shared by everyone. Also, he doesn't explain why he thinks
>>> that allowing to embed SVG inside HTML is generally bad. Authors can still
>>> decide against mixing SVG and HTML, if they want to keep a clear structure.
>>>
>>>
>>>> SMIL is still supported in four of
>>>>> the five main browsers. Google rescinded their removal of the SMIL
>>>>> implementation.[1] Only Microsoft doesn't have plans to implement
>>>>> it.[2] But in the long term it seems that, at least browser vendors,
>>>>> rather want to switch over to CSS animations, which is a proper static
>>>>> declaration equivalent. SVG fonts obviously didn't have much support
>>>>> among implementors, but got replaced by WOFF, also an open standard.
>>>>>
>>>>> > Well and CSS - there are mainly only drafts, but vendors propagate
>>>>> > nevertheless to authors already to use their prefixed own properties
>>>>> and syntax
>>>>>
>>>>> (Browser) vendors moved away from prefixed properties years ago in
>>>>> favor of preferences to avoid incompatibilities. They do not propagate
>>>>> their prefixed own properties and syntax (anymore).
>>>>>
>>>>
>>>> It would be difficult for a vendor to “propagate” a proprietary prefix
>>>> (??). In any case, look well into CSS and JavaScript implementations.
>>>>
>>>
>>> Could be that "propagate" is not the right word here. I'm not a native
>>> English speaker. What I mean is that vendors now implement new experimental
>>> features behind preferences instead of exposing them by default using a
>>> prefix. Of course, there are still proprietary prefixed parts in CSS and
>>> JavaScript, but they now cannot be removed anymore without breaking
>>> websites, because vendors formerly made the mistake to expose them by
>>> default.
>>>
>>> Sebastian
>>>
>>
>>
>