- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 1 Nov 2004 08:57:18 +0000 (UTC)
- To: Peter Sorotokin <psorotok@adobe.com>
- Cc: www-svg@w3.org
On Mon, 1 Nov 2004, Peter Sorotokin wrote: > > People _do_ multiline text today in SVG, but it is done with x and y > attributes. We just want this line breaks to happen automatically, > nothing more. No document-level (box) layout, no document structure > structure, no semantics, but reliable positioning and integrating with > SVG rendering pipeline. You say this as if it was a good thing, whereas it would seem to be a strong violation of both WCAG (checkpoint 3.1 in particular, but also 3.6 and 3.7) and AWWW (4.3, 5.1). > You table conveniently ignores flowTRef, flowRoot, flowRegion, > flowRegionExclude and flowRef (because don't map to CSS/HTML by any > stretch, I guess). I omitted those since, as I discussed in my comments, they were the additional feature for which the entire chapter seemed to exist, and I had proposed a simple addition to CSS that would remove the need for these separate elements. > > > Why is it somehow OK to have single line text flow with all complex > > > internationalization features (baselines, bidi, vertical text, glyph > > > orientation) and text-on-the-path and somehow not OK to have (much > > > simpler to implement!) text in the shape? > > > > Text, especially when there is more than just one line's worth, is > > content. Content should be marked up in a semantically-rich fashion > > for accessibility reaosns. HTML is the language for this. > > According to this logic, SVG should not have had text in the first > place. I do not see why this argument does not apply to a single line of > text anymore than it applies to text with line breaks. I explained why. It was the next paragraph of my e-mail: > > It is acceptable for a specification to introduce simple alternatives > > for complex specifications (for example, the way CSS2 allows authors > > to perform simple 'text-shadow' effects without using the full SVG > > model) but when it comes to reinventing large parts of other > > specifications, one has to draw the line. > > Look at the percentage of CSS spec that is _reused_ in SVG and the > persentage where there is no overlap. Overlap is tiny and IMHO it does > not actually grow from SVG 1.1 to SVG 1.2. Text is just as integral part > of drawings as it is of the documents. You cannot claim exclusive CSS > ownership of anything that is text-related. You are attacking a straw man here. My point was just that while it makes sense for SVG to define how to handle a single line of text (especially when this integrates tightly with SVG's other features, for example with text on a path, with exact length-mapping, glyph orientation, stroking and filling effects, and so forth), it does not make sense for SVG to then expand this all the way to fully-flowed aligned text, since that is something that has been the bread-and-button of an existing W3C specification (in this case CSS) for some 8 years now. > Line breaking is the _only_ substantial addition to SVG 1.1 here in > terms of text layout! Line breaking is a big thing. I am told that in the whole of the Safari rendering engine, for example, the most complex function is the one that determines line breaking opportunities. I have myself written dozens of test cases for line breaking issues in Web browsers. Also, I am concerned that this is just the thin edge of the wedge. It seems likely that if SVG 1.2 introduces line breaking and word wrapping, that authors will use this and then ask for control over it, e.g. with the CSS 'white-space' property. And then for control over vertical alignment, e.g. with 'vertical-align'. And so forth. It would be better to just re-use existing specifications right away than to slowly re-invent what the W3C has had in REC since 1996. > > For example, members of the SVG group frequently warn against CSS > > reinventing gradient effects. Gradient effects are a feature with much > > demand, but the CSS working group has accepted that HTML+CSS UAs must > > implement all of SVG's model to provide that feature. > > Can you provide a link? Where does it define how can you reference SVG > gradient from HTML CSS stylesheet? Just use the 'background-image' property and link to an SVG file that consists of a gradient: http://www.w3.org/TR/REC-CSS1#background-image People have complained that that is too complex and that they want to be able to do it from within CSS: http://lists.w3.org/Archives/Public/www-style/2004Aug/0092.html http://lists.w3.org/Archives/Public/www-style/2004May/0147.html SVG working group members are always quick to suggest SVG: http://lists.w3.org/Archives/Public/www-style/2004Aug/0093.html http://lists.w3.org/Archives/Public/www-style/2004May/0158.html ...thus the CSS working group has so far avoided defining explicit gradient support in CSS. > > > Note that SVG text features are designed in such a way that single > > > text engine can easily be designed to handle both CSS and SVG text > > > layout (this is what Adobe SVG Viewer 6 preview does). > > > > I don't really see how. The CSS inline box model and the SVG 1.2 text > > flow model are _radically_ different. > > You realize that you telling this to someone who has actually > implemented both of them, right? You realise that you are telling this to someone who has actually tested both of them, right? Does your CSS version pass all these tests? http://www.hixie.ch/tests/adhoc/css/box/inline/ http://www.hixie.ch/tests/evil/mixed/lineheight1.html http://www.hixie.ch/tests/evil/mixed/lineheight2.html http://www.hixie.ch/tests/evil/mixed/lineheight3.html http://www.hixie.ch/tests/evil/mixed/lineheight4.html http://www.hixie.ch/tests/evil/mixed/lineheight5.html http://www.hixie.ch/tests/evil/mixed/lineheight6.html http://www.hixie.ch/tests/evil/mixed/lineheight7.html (Is there a product I can download somewhere to test this?) > > > As for your proposal, given our experience on text layout feature > > > design, it is unlikely that we have enough time to review it before > > > PR. > > > > It is a W3C process requirement that you review all input before > > progressing from Last Call to Candiate Recommendation. (Process > > section 7.3.) Several people have already reviewed my proposal, it's > > actually pretty simple. I have no doubts that the SVG working group > > will be quite capable of reviewing my proposal. > > We'll certainly review your comments as "input" (I am doing just that). > We won't have time to review it as a proposal, though. Are you saying that the SVG working group is rejecting my suggestion for chapter 4? > > > These are problems I see immediately: > > > > > > - you proposing that we do exactly the thing (extending overflow > > > property) that you say is wrong in other places (extending cursor > > > property) > > > > I would recommend that the SVG group propose my suggestion to the CSS > > group, not that the SVG group incorporate it into the SVG spec. > > So you propose we drop it entirely from SVG 1.2 spec and wait for CSS WG > to produce its spec. Just to make it clear for other people on the > mailing list. I don't think anything could be more clear, to quote from my original last call comments [1] (for which detailed technical reasoning was given [2]): | Please drop the entire spec > > > - you propose different algorithm than is in the current draft > > > (which is based on SVG 1.1) - what is your justification for that? > > > > The algorithm currently in SVG 1.2 doesn't handle the CSS inline box > > model, floats, multiple containing blocks, full vertical alignment > > requirements, etc. My proposal is a simple extension to the existing > > CSS model so that any existing CSS-styled content can be poured into > > an SVG shape. For example, it would be possible to use my proposal to > > mould any existing HTML Web page using an SVG shape. > > Why did not you make this proposal to CSS WG directly (of which you are > a member)? What makes you think CSS WG would actually act on it? I personally have not seen much demand for this, and the CSS working group has not received many (any?) requests for it. However, if the SVG working group considers this feature to be a requirement, then I am sure the CSS working group would be happy to oblige by extending the CSS specifications in appropriate ways. > For instance, I see this is CSS2.0 > [http://www.w3.org/TR/CSS2/visufx.html#propdef-clip]: > > > Note. In CSS2, all clipping regions are rectangular. We anticipate > > future extensions to permit non-rectangular clipping. > > This was 6 years ago and nothing non-rectangular ever came out. The CSS working group has been focussing on increasing interoperability of existing implementations, first by releasing a thorough update of CSS2 in which every feature was examined for interoperability and every open issue was resolved, and second by working on test suites. New features have therefore been a low priority. > > > - it does not integrate with SVG drawing model (clipping, masking, > > > gradients, patterns, filter effects) > > > - it does not allow one to change order (and other properties, say, > > > opacity) in which regions are drawn > > > > In what way do you believe the text flow model should integrate into the > > above processes? > > Because current multi-line (absolutely positioned text) does and people > use above features (clipping in UI controls, the rest for visual > effects, e.g. on maps). I didn't ask why, I asked what. In what way do you believe the text flow model should integrate into the above processes? Are you saying that it is a requirement that all multiline text glyphs support being drawn on a path? Are you saying that multiline text glyphs must support being drawn using gradients for the fill colour? > > My understanding is that my proposal supports all the SVG integration > > features of <foreignObject>, which is an SVG 1.0 feature, and which, I > > believed, was fully part of the SVG drawing model. > > It only provides a way to take a blob of foreign content, render it by > foreign (not SVG!) rules and put it in as effectively bitmap image. This > is way coarser integration than we need. I would recommend increasing <foreignObject>'s capabilities then, instead of inventing a whole new mechanism to do multiline text. > How many real-life documents do you have which use gradients? Most that > I have seen are more drawings than documents. There are gradients on: http://www.adobe.com/ http://www.macromedia.com/ http://www.gamespot.com/ http://www.disney.com/ ...to name but 4. Most of these are done using bitmap graphics right now. > How many real-life drawings have you seen than use multiline text? > Pretty much all of drawings that use text at all. Most of the drawings I've seen that use flowed multiline text are really documents that happen to be styled with fancy backgrounds and borders, and are not what I would call drawings. > Besides this is not about "flow", SVG already has text that flows, but > it flows on a single line. This is about multiline text in a shape, the > feature that CSS at present does not have and for which it did not even > have a proposal before today. I am merely suggesting that instead of adding multiple new elements to SVG, and adding an algorithm which is radically different from CSS' inline box model, the SVG working group ask the CSS working group to extend the 'overflow' property (which SVG already uses) to cover the shaped text case. >> Are you suggesting that the SVG working group is not, in its >> development of SVG1.2, considering multiple document formats to be the >> primary use case? If this is the case, one is forced to question the >> extent to which SVG1.2 is addressing the SVG charter's requirement to >> produce "a modular XML tagset usable in mixed-XML namespace documents". > > I can assure you that not only SVG WG is always keeping in mind > integration with other document formats and W3C technologies, but have a > proven record of doing so (SMIL, FO, CSS/XHTML, XForms, XMLEvents come > to mind immediately). So why does SVG 1.2 not do so in this instance? > Somehow it was OK for SMIL to reinvent box model. It wasn't. I recall there being much complaining about that. However, SMIL is not positioned as close to HTML+CSS UAs as SVG is, and therefore it is less of an issue. (Few UAs are going to implement both with the same engine, for instance.) > It was OK to do XSL:FO. Nothing was OK for XSL:FO. The entire concept of XSL:FO is a violation of AWWW and myself and my employer are well known for being vocal opponents to XSL:FO as a technology. (It should be noted, though, that XSL:FO actually did use the CSS model verbatim, so it was not so much a reinvention so much as a different serialisation.) > It is even OK for pure Unicode (with no mark-up at all) to spec out how > to break lines in text. I'm not sure what you're suggesting here. Unicode is at a conceptual different level than CSS and SVG. > However is not OK for SVG to do automatic line breaking in text. Go > figure. Would you not suggest that the CSS working group was at fault if we introduced ways of creating vector graphic shapes using CSS? [1] http://lists.w3.org/Archives/Public/www-svg/2004Oct/0088.html [2] http://lists.w3.org/Archives/Public/www-svg/2004Oct/0144.html -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 1 November 2004 08:57:20 UTC