- From: Dirk Schulze <dschulze@adobe.com>
- Date: Sat, 20 Sep 2014 05:59:55 +0000
- To: L2L 2L <emanuelallen@hotmail.com>
- CC: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "www-svg@w3.org" <www-svg@w3.org>
On Sep 20, 2014, at 1:42 AM, L2L 2L <emanuelallen@hotmail.com> wrote: > I LOVE IT WHEN MY SIMPLE QUESTIONS ADD COMPLICITY TO THE SITUATION!!!! > > For get canvas!!! > > SVG tag itself is a canvas!!! And a easy one at that! -- you can attach event on the element and not have to pin point where the user mouse/finger are-- > > The problem is, there is no defined way to know--with out knowing SVG-- of what attribute to use... What I'm saying is, we design a spec that will act as a guide for developers to follow that will allow SVG programming in the scripting language all together.... Um, like adding all tag element via script, that way we avoid the ideal of having to parse every element to manipulate. We have a specification that defines the behavior of SVG. It is called SVG 1.1. You can easily create your own library on top of JS and SVG that has the design of HTML Canvas but the object orientation of SVG that you wish. Scripting is your desire after all it seems. This forum is open for questions, suggestions and discussions related to SVG, and more over, we very much welcome feedback. I am sure that the SVG community understood your request. And we are thankful for your contribution. Sending mails with the same content over and over again must be considered as noise though. Noise makes the mailing list less attractive. Sending the same request with different email titles and even hijack other threads for your idea is disrespectful. If you have new proposals or questions, you are welcome to ask them on this list. I kindly ask you to stick with your “canvas” idea to your original email thread you started weeks ago. Greetings, Dirk > > E-S4L > N-S4L > J-S4L > >> On Sep 19, 2014, at 5:44 AM, "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de> wrote: >> >> Tab Atkins Jr.: >> >>> >>>> SVG 1 refers only to CSS 2, no current draft. CSS 2 does not contain >>>> animation features, therefore it is nothing with a defined meaning for >>>> SVG 1 documents. >>>> SVG 1 clearly predates such drafts, implicating no defined relation. >>> >>> The use of such dated references is a spec bug; in reality, SVG uses >>> the latest CSS that is supported by the UA. >> >> It is the purpose of standards/specifications/recommendations >> about formats to say, what applies, not a bug. >> The only practical problem with this is, that implementors typically (always?) >> do not manage to implement completely and correctly what is >> specified, therefore if such bugs in implementations are fixed or newly >> introduced, presentations or interpretations of documents change, >> that does not mean, that die meaning or correct interpretation of >> the document changes ;o) >> >> ... >>> >>> Fortunately, none of what you just said is true, >> >> Unfortunately your claim about my findings/experience of the past ~17 years >> is completely wrong ;o) >> This is quite surprising, because we are talking about the same programs >> and computer languages - and surely you have tried to use them as well - >> but maybe never by following such recommendations? >> >>> and browsers don't >>> actually have to ship implementations of every version of every spec >>> they've ever supported (plus combinatorial amounts of glue code for >>> when the specs interact in different ways). >> >> I see, that this is obviously a practical problem, but if different versions >> of a format do not fit together, there is no other way to get a correct >> interpretation of documents following different, in parts incompatible >> versions of a language. >> >>> UAs use the latest >>> versions of whatever specs they implement, and web languages almost >>> never carry version indicators; the big ones (HTML, SVG, CSS, JS) >>> certainly don't. >> >> Of course, current recommendations for (X)HTML and SVG have >> version indications - you just have to look into them, you will find them, >> the problem mainly appeared with the HTML5 draft - this has no build >> in feature to indicate, that an author or document cares about this version >> at all ;o) >> SVG currently indeed has the problem, that there are a few bugs/incompatible >> changes in the version 1.1.2 compared to 1.1.1, but there is no new version >> indication for 1.1.2. If an author knows this, this is simply an indication >> not to use such an obfuscated feature. In doubt in such cases one has >> to use 1.1.1 to get the right interpretation, if it not precisely known, that >> an author uses alread 1.1.2, what is for older documents obviously not >> the case, therefore 1.1.2 cannot apply for them. >> CSS - this suffers as well from missing versioning, because it has some >> incompatible changes as well, with the same consequences as described >> for the few obfuscated features of SVG 1.1.2. >> JS/DOM - mad history, uncontrolled growth - the explanations of DOM >> extensions for example in SVG recommendations short and uncharitable >> and without examples - these sections do not really fit to the quality level >> of the rest of the recommendations. >> This language is not really a representable specimen of clarity, usability >> and precision - to get something really defined, one needs to replace it >> completely ;o) If one needs an example for something, where almost everything >> went wrong, JS is a good one ;o) >> It is more an example for something, one needs to avoid >> in development of a computer language designed to be applicable for >> quite different interpreters. >> >>> There is a certain theoretical purity to what you're saying, but it >>> has not and will not ever be true on the web. >> >> It is the daily experience of authors, that implementations fail - >> well thats natural (and nothing implementors have to feel guilty >> or assaulted about), therefore authors and users cannot rely on >> the presentation of a specific version of any viewer - one has to >> take into account, that it is incomplete or wrong for some issues, >> but it can be improved (or degenerated) in the future. >> The current daily business of 'web authors' is to work around bugs and gaps >> in the interpretation of already existing standards/recommendations. >> But if this results in serving tag soup just to please current viewer >> versions, soon they are really lost in nonsense (indeed, many are >> already). >> >> There is no other choice for authors of long living documents (more than >> 10 or 100 years) as to write digital documents according to some >> specific standard/specification and indicating which they used, >> behaviour of viewers can change every day and that of a specific >> one will not matter a few years in the future anymore. >> You cannot update, if you have thousands of such documents, >> you cannot update, if you are engaged in other projects, sick or dead. >> >> Just if you write content only relevant for the next few weeks, >> behaviour of some current viewers might be relevant - for >> such an application it might be ok to serve some arbitrary tag >> soup, that has some tested presentation just for today. >> Something without a version indication like HTML5 might be >> ok for just stiring, rewarming and styling up undefined tag soup >> to serve it as daily entertainment-meal, >> but it is quite useless for serious, long living documents. >> >> Olaf >> >> >> >
Received on Saturday, 20 September 2014 06:00:26 UTC