Hi David, Many thanks for the list. May I add: L. The ability to perform text selection operations as well as below markup navigation using the keyboard.
Pranav -----Original Message----- From: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com] On Behalf Of David Dailey Sent: Saturday, June 08, 2013 7:56 AM To: 'Doug Schepers'; svg-developers@yahoogroups.com Subject: RE: [svg-developers] Wrapping Text in SVG 2 Hi Doug, You've made a lot of good points here about CSS being more popular than SVG: more people care; more people can edit the spec; the range of applicability (to HTML as well as SVG and other domains) is greater. And I appreciate the effort to expand the dialogue to svg-developers, since www-svg tends to be less about the philosophy of where SVG ought to go and more about how to get to wherever it is already known to be going. It sounds like we share the frustration about the sluggishness of progress with SVG text. As you know I've been teaching lots of folks to learn SVG, through both the W3C, in accredited educational channels and other venues, in most of the world's continents. Frustration about text handling in SVG is something, as an educator, I hear from a lot of folks. It's a shame that there is not an easier forum to let those frustrations boil up to the point that implementers might actually hear it! You mention frustrations with other like SMIL, and the list can be extended to include other topics as well, but text is the issue I'm fussing about here, so let me just respond to a couple of your questions. DS: What do you mean by "much more"? Wrapping text to arbitrary shapes? That is also coming, but as part of a more complex proposal that will also hopefully be part of SVG 2 (but may be deferred a bit, since we are trying to be have an aggressive schedule to move SVG 2 forward). <br> Simple CSS text wrapping is meant for the most common case, a basic rectangular area. Well, it is good to be able to confine and flow text into rectangles and into arbitrary shapes. Maybe I am not understanding the proposal. Confining text to a rectangle is something that is pretty easy to do with about 3 lines of JavaScript; even beginning students can do that in exercises. I suppose it wouldn't matter too much if browsers implemented SVG in HTML or HTML in SVG consistently, but consistency in <foreignObject> <iframe> <object> <embed> <frame> all seem to be areas that implementations have decided to ignore. There are lots of examples of inconsistency reported over the years here and at www-svg. Maybe they've all been fixed, but I rather doubt it, since my personal experience as a seasoned developer is that browsers are diverging rather than converging in consistency in their implementations, for the complicated stuff. Happily, the simple stuff is reaching consolidation! Text handling should include a) methods to select text through dragging, double clicking etc. b) ability to click between characters and allow insertion of new text at the position of the cursor c) the ability to copy and paste from and into text areas d) the ability to delete through delete and backspace (defined relative to current selection be it a null character or multiple characters) e) scrollbars that appear when the text overflows the available rectangle f) methods for querying the scrolling position and currently selected text g) ability to build autolinks to continuation shapes (as in Aldus Pagemaker where a text could be continued in other shapes appearing elsewhere in a document or page) h) the ability to measure glyphs -- currently browsers do not agree on what is the bounding box associated with a glyph. It looks like only Adobe ASV plugin does it right. i) text alignment features from SVG1.1 -- most browsers decided not to implement this. Does that mean the browsers are right and the spec is wrong? When browsers decide to deviate from the spec is this really a signal that the spec should be weakened? I'm thinking of kerning, text-decoration, individual vertical and horizontal spacing and sizing of substrings, top alignment, directionality of text flow, etc. SVG 1.1 has a microzillion things there, many of which just don't work, at least as of my most recent tests. j) allowing text to be aligned to both a bottom and a top curve. k) allowing individual glyphs to be warped according to shapes A lot of this has been on the table for more than a decade and what is new, since the proposals of 2009-2012 is important so that authors won't keep warping text using Photoshop, Inkscape, Gimp and Illustrator and then saving or exporting as bitmaps to produce the sorts of artsy textual effects that are, in fact, commonplace on the web, in defiance of accessibility both textual and graphical. This practice by authors is commonplace and it damages accessibility. I remember reading something in the W3C's planning docs that treatment of text is one of the most commonly encountered complaints about SVG. It certainly is among the practitioners whose paths have crossed my own. The paper that Dr. Whitfield and I presented at SVG Open2011 http://cs.sru.edu/~ddailey/svg/GeometricAccessibility.html makes a lot of these concerns more graphically. I also remember submitting a lot of these ideas some time ago, in one of the SVG WG's call for public input. Hopefully, this answers at least a part of the question of what I mean by "much more." Regards David -----Original Message----- From: Doug Schepers [mailto:d...@schepers.cc <mailto:doug%40schepers.cc> ] Sent: Wednesday, June 05, 2013 1:41 PM To: svg-developers@yahoogroups.com <mailto:svg-developers%40yahoogroups.com> Cc: David Dailey Subject: Re: [svg-developers] Wrapping Text in SVG 2 Hi, David- Thanks for the honest response. I'll try to address your comments as best I can, and I hope you can bear with me in detailing your issues so we can arrive at a mutual understanding of the situation. On 6/5/13 10:41 AM, David Dailey wrote: > > I suspect you already know that I’ll not be happy until much more is > accomplished What do you mean by "much more"? Wrapping text to arbitrary shapes? That is also coming, but as part of a more complex proposal that will also hopefully be part of SVG 2 (but may be deferred a bit, since we are trying to be have an aggressive schedule to move SVG 2 forward). Simple CSS text wrapping is meant for the most common case, a basic rectangular area. > and am rather dismayed that it has taken more than a > decade to get even rudimentary text areas into SVG in a way that will > work across browsers. Same here, which is why I'm trying as hard as I can to push this forward, and trying to drum up support for it, to illustrate to the browser vendors that this should be a priority. > Coupling the fate of SVG with developments in CSS seems like putting > the cart before the horse and seems to be slowing down progress in > SVG. In my view, it's just the opposite (as I may have mentioned to you before). Here's a rationale: 1) We have limited people editing the specs for SVG; having people from the CSS WG edit specs increases both the number and the range of expertise of people available to edit (for example, Alan Stearns is an expert in arbitrary text-wrapping from years of work on InDesign, etc., and is editing the CSS Shapes spec, which SVG will use); 2) SVG is *much* less popular than CSS, and is therefore a much lower priority for implementers; by piggybacking on features defined in CSS, we increase the likelihood and the speed of initial implementation, and decrease the cost and improve the rate of maintenance; this may also make the browsers more favorably disposed toward SVG in general, because it's less work for them; 3) By sharing features with CSS/HTML, we dramatically increase the number of authors (developers and designers) who are familiar with and excited by the feature, decreasing the barrier to entry for people just starting out with SVG who are already familiar with CSS and HTML (e.g., the overwhelming majority). The downside, of course, is that there is a little bit of adjustment up front... growing pains. The SVG WG is doing extra work to clean up SVG 2 and make sure things are defined in a way that works well with CSS (and working with the CSS WG to ensure that they define things in a way that works for SVG). Some implementations are being adjusted. But on the whole, it shouldn't affect authors that much (mostly the aforementioned delays on new features), and it should pay big dividends going forward. And I don't really see many other downsides. On the particular topic of this thread, text-wrapping, there is no evidence to support the notion that coordinating with CSS is slowing us down (in fact, the CSS WG's advice was extremely helpful), and explicit evidence to show that this feature would not have moved forward if it were SVG-only: SVG Tiny 1.2 has had a very well-defined <textArea> element [1] for text wrapping that has been around for 4.5 years (!), and has only one browser implementation, Opera (and it's possible Opera's implementation may go away as they move their engine from Presto to Blink... a real shame...). By contrast, within a day of suggesting this to Cameron MacCormack, he had a rough first-pass implementation of text wrapping using 'width', precisely because it came for nearly free by using CSS. I suspect that part of your frustration is not "moving features to CSS" in general, but rather the specific topic of SMIL (and maybe also SVG Fonts). This was not so much a matter of CSS, as it was the specific decisions of Microsoft, Google, Apple, and to some degree Mozilla, all disliked SMIL, and some refused to implement it (or planned to remove existing code bases); it was simply not going to be interoperable, and for most authors, that's a deal-killer. The good news is that, in addition to all the script libraries out there that let you animate in SVG, the new Web Animations 1.0 spec [2] was approved for First Public Working Draft; it is generally more powerful and easier to use than SMIL [3], and a declarative syntax for SVG is planned that should mimic SMIL as much as possible for backwards compatibility. If I've misinterpreted or misunderstood the nature of your concerns, please set me straight. > I suspect my sentiments on such matters are already well known, but I > would be remiss in my obligation to other authors who share this > perspective if I did not say it again. Forgive my ignorance, but is this a common sentiment? I don't hear it expressed much; most of the time when I mention that SVG is deferring to CSS on functionality, it's met with relief, because more people know CSS than SVG. I'd be happy to discuss this more on a dedicated thread. I'm curious what the detailed concerns are, and how many people feel the way you've expressed. [1] http://www.w3.org/TR/SVGTiny12/text.html#TextAreaLayout [2] https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html [3] https://wiki.mozilla.org/images/f/f6/CSS-SVG-Web-Animations.png Regards- -Doug ------------------------------------ ----- To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: svg-developers-dig...@yahoogroups.com svg-developers-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: svg-developers-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
