- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Mon, 01 Nov 2004 00:03:00 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-svg@w3.org
- Message-id: <5.2.0.9.2.20041031224330.031e9198@mailsj-v1.corp.adobe.com>
At 01:10 AM 11/1/2004 +0000, Ian Hickson wrote:
>On Sun, 31 Oct 2004, Peter Sorotokin wrote:
> >
> > I am puzzled. What exactly does it reinvent in HTML or CSS? Line breaks?
>
> SVG 1.2 HTML or CSS
> --------------------------------------------------
> <svg:flowDiv> <html:div>
> <svg:flowPara> <html:p>
> <svg:flowSpan> <html:span>
> <svg:flowRegionBreak> 'page-break-after: always'
> <svg:flowLine> :after { content: '\A'; }
> <svg:flowLine/> <html:br>
> <svg:flowImage> <html:img>
Out of how many HTML elements?! These are all purely presentational
elements and they fit SVG actually better than HTML (which is supposed to
be a semantic mark-up). And most of them already have SVG analogs for line
layout (e.g. flowSpan is just like tspan) which is already there. 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.
Also the table above is misleading: SVG elements are not the same as
HTML/CSS elements. For instance, HTML div and p a block elements, whereas
in SVG there are not block elements at all. Here is another table which I
think is much more accurate:
SVG 1.2 similar SVG 1.1
---------------------------------------------------------
flowDiv text and textPath
flowPara, flowLine, flowRegionBreak tspan with x and y
flowSpan tspan without x and y
flowTRef tref
flowImage (missing but needed, people hack
it with custom glyphs)
flowRoot, flowRegion, flowRegionExclude similar to xlink:href on textPath
flowRef use
You can get exactly the same visual effect in SVG 1.1 using the above
mapping if you know the font metrics. All we do in SVG 1.2 is allowing UA
to calculate the placement - this facilitates interchange and accessibility
and removes font metrics dependance.
You table conveniently ignores flowTRef, flowRoot, flowRegion,
flowRegionExclude and flowRef (because don't map to CSS/HTML by any
stretch, I guess).
> > 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. Line breaking is the
_only_ substantial addition to SVG 1.1 here in terms of text layout! This
is like saying that one cannot draw a circle and flow text inside it in
Illustrator and have to switch to Word because Word is the tool for text.
>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.
>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?
> > 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?
> > 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. You realize that it is
pretty late to make feature proposals.
> > 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.
> > - 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? 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.
> > - 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).
>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.
> > - it effectively forces SVG 1.2 implementor to implement full CSS box
> > model which is unwarranted
>
>On the other hand, the SVG 1.2 solution forces HTML+CSS implementors to
>implement the full SVG model,
This is wrong.
It does not force HTML+CSS implementors to do anything extra whatsoever.
It forces HTML+CSS+SVG implementors to implement combined model
It forces SVG implementors to implement line-breaking (but not anything else)
Your model forces SVG-only implementors to implement full CSS layout
(including box model which is a very big chunk of work).
> and doesn't provide any way for existing content to be restyled using
> SVG features.
>
>And like I said above, HTML+CSS UAs have to implement the whole SVG model
>to provide gradient backgrounds, so why shouldn't SVG UAs implement the
>whole CSS model to provide flowed text, which HTML and CSS have been doing
>since the mid 90s?
How many real-life documents do you have which use gradients? Most that I
have seen are more drawings than documents.
How many real-life drawings have you seen than use multiline text? Pretty
much all of drawings that use text at all.
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 had
a proposal before today.
> > Your proposal might be a good basis for integration between XHTML and
> > SVG, though.
>
>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" [1].
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). SVG references several specs normatively and reuses a lot of
features, probably more than any other W3C spec. I feel offended by the
above, should I say, inquisitive accusations. Somehow it was OK for SMIL
to reinvent box model. It was OK to do XSL:FO. It is even OK for pure
Unicode (with no mark-up at all) to spec out how to break lines in text.
However is not OK for SVG to do automatic line breaking in text. Go figure.
Peter
>[1] http://www.w3.org/2003/07/svgwg-charter.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:03:31 UTC