- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Mon, 01 Nov 2004 02:27:59 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-svg@w3.org
This is probably the last post I can make on this subject. I think I am starting to repeat myself. At 08:57 AM 11/1/2004 +0000, Ian Hickson wrote: >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). No, it is a bad thing and that is exactly what we are trying to fix. It is bad, not exactly for the reasons that you mention, though: most of the time explicit line-breaking mark-up is used where there should be none. (BTW, it would help if you provided links to the documents that you reference). > > 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. It does not remove the need for flowTRef, flowRegionExclude and flowRef by any means. flowRegion indeed maps to your long-term proposal (but nothing for the next several years). flowRoot and flowRegion are actually needed for flowRef to work properly. > > > > 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. CSS is way bigger than that. Even CSS box model is way bigger than that. CSS is about styling and document-level layout. It does include flow layout, but that's not something which is peculiar to CSS: _anything at all_ that handles text does it (including SVG). The only thing that SVG did not have before was line breaking. You cannot say that line breaking was bread and butter of CSS. This is a relatively simple feature that was not included in SVG 1.1, even though more complex features (say, bidi for vertical text with automatic glyph orientation) are there. This situation does not make any sense and needs to be fixed. We still do not have document structure (blocks, tables, lists, etc.) nor should SVG have it, because your argument does apply quite well in that area. > > 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. Hmm, have you seen Unicode Standard Annex No. 14 (that SVG 1.2 references)? It is actually quite simple and easy to implement. Most of the hard work (classifying cases) was done in compiling the character classes and break table. >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. Ian, I have a feeling that you misrepresent the facts. Please correct me if I am wrong, but W3C did (and does) not have in REC that whould define _any_ of the following: - what are the possible spots to break the line - how to determine text metrics - how to determine in which spot line breaking has to be done - how to break lines for text in arbitrary shapes In other words it did not (and still does not) have any single reliable line breaking spec. Moreover, from what I know, there is very little interest in document (i.e. non-drawing) community to define these issues because different engines implement that differently. Indeed, versions of the same engine do it differently. This is simply viewed as not a bad thing (because for text-dominated documents it mostly is not). SVG defines all of the above. > > > 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. Ah, OK, that is more like of "accidental integration". The reason I asked is that I have never heard of CSS WG defining anything that would specifically integrate or leverage SVG in any way and I thought maybe that is changing. Too bad it is not. > > > > 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? Nice stunt! Ian, do you think that by testing them (even assuming you did a lot of SVG 1.2 text layout testing) you gain a lot of knowledge about if it can or cannot it be implemented by the same engine? >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 No, since these are not XHTML and I am not doing HTML. I looked into several of them and I do not see anything in these tests that would collide with SVG 1.2 features, can you be more specific? >(Is there a product I can download somewhere to test this?) You can look at ASV6 preview, but that code is fairly prototypish and certainly it is missing a lot of features. I cannot give you anything newer today. This is not the point though, you always can find a bug - I think for any today's CSS implementation it is possible to write a test that it won't pass. > > > > 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? That would be my initial suggestion, but I would need to see what others would say to cast even my vote. Certainly, I cannot speak for other members of the WG. However, I see basically only two possible outcomes: - keep SVG 1.2 line breaking and reject your proposal - drop SVG 1.2 line breaking and make a submit proposal for some future version of CSS (CSS 4?) or XSL:FO We cannot make use of your proposal for SVG 1.2 in any meaningful way and that what I meant by "unlikely that we have enough time to review it". > > > > 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 Yep, that is clarification that I was looking for. I just want people to realize that in SVG 1.2 timeframe it is not "existing proposal" vs. "Ian's proposal", it is "existing proposal" vs. "nothing". >[snip] > > > > > - 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? Ability to do clipping, masking, stroking, gradient and pattern filling/stroking, filter effects on per-span and per-region basis. > Are you saying that it is a requirement that all multiline text glyphs > support being drawn on a path? No. >Are you saying that multiline text glyphs must support being drawn using >gradients for the fill colour? Yes - and more above. > > > 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. That won't work. We need to have control over individual elements _inside_ foreignObject. > > 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. In ideal world all of them would have made a heavy use of SVG. They are just as much drawings as documents. Name anything that uses just gradients. My assertion is that there are not many. > > 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. You did not answer my question. How about drawings? Maps, schematics, diagrams - pure drawings - use multiline text more often than not. >[snip] > > > >> 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? Because doing it would mean CSS producing something radically different than it has now. There is nothing that we can reuse as of today. See four things that CSS is missing above. Plus integration in SVG drawing pipeline. > > 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. It is, but Unicode defines how to break lines. You are saying CSS has to do that. > > 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? This is wrong analogy. General shapes are central to SVG and very peripheral for CSS, whereas line breaking is something that happens just as often in drawings as in documents. I do not see CSS having exclusivity on this issue. We should work together (and we did), but it is incorrect for CSS to claim total control over line breaking (and CSS spec does not). CSS includes rectangular shapes, border styles, colors, font matching, image references, simple effects - all of this stuff could have been claimed to be drawing-specific and "owned" by graphics language, but it is unreasonable, because even simplest documents would require graphics language then. Line breaking is needed even in simplest diagrams and is done with a single API call in many graphics APIs. Telling graphics language that it cannot break lines does not seem reasonable to me. Peter >[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 10:28:11 UTC