- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 1 Nov 2004 09:24:59 +0000 (UTC)
- To: Peter Sorotokin <psorotok@adobe.com>
- Cc: www-svg@w3.org
On Mon, 1 Nov 2004, Peter Sorotokin wrote: >> >> If the SVG working group instead encouraged use of semanic HTML markup, >> authors could use the strong semantics of elements such as <cite>, >> <em>, <blockquote> and the like. > > I agree that this would be beneficial, but it has to be done in the > Compound document activity not in SVG WG. The compound document activity's charter is to specify profiles of existing specifications, not to create new features of this nature. It would be the responsibility of the SVG or CSS working groups to define features for flowing semantic content into arbitrary shapes. > So far I am not sure how exactly your proposal would differ in terms of > glyph positioning. It appears that your proposal effectively rephrases > SVG 1.2 algorithm. My proposal is merely an extension to the CSS model. It is quite different from the proposed SVG model, which is itself quite different from the CSS model (for example, the SVG model does not support 'line-height' or 'vertical-align', and doesn't support the CSS box model on inlines). > Everyone I know agrees that there should be only a single text layout > engine in a well-designed UA and that exact syntax is not very relevant. In that case, why does SVG 1.2 introduce a new text layout algorithm that is radically different from the CSS model, using an entirely new syntax? If it really is true that the SVG working group wants there to only be one text layout algorithm, then it would make the most sense to simply reference the existing algorithm normatively. If it really is true that the exact syntax is not very relevant, then it would make the most sense to simply reference the existing syntax normatively. > Translating it to more practical language you proposing to DROP line > breaking features in SVG 1.2 and wait several more years before these > integration issues are resolved Again, you are attacking a straw man. There is no reason why my simple proposal should take years. There _are_ no integration issues (at least, nobody has yet named any). > even though there is a strong implementation feedback that there is > nothing in the current SVG 1.2 proposal that would negatively impact > integration in future. Please consider my feedback to be implementation feedback from Opera to the effect that the current SVG 1.2 proposal would negatively impact integration in future (in fact, it would negatively impact any effort to have a single text layout algorithm right now, if we started implementing SVG today.) I have also heard similar complaints from Apple and Mozilla engineers. Indeed, Apple sent implementation feedback on this very matter to the SVG working group list only a few days ago: http://lists.w3.org/Archives/Member/w3c-svg-wg/2004OctDec/0701.html ...so it is patently untrue that "there is a strong implementation feedback that there is nothing in the current SVG 1.2 proposal that would negatively impact tegration in future". > Moreover, SVG WG specifically defined line breaking in such a way that > it is compatible with CSS and a single engine can be used to do line > breaking for both specs (which is much more important than exact syntax) > and the success of this design goal has been validated in > implementations. I'm sorry, but the current model is not compatible. Implementations that claim to implement both with a single engine are almost certainly incorrectly implementing the CSS inline box model. For example, the following: <div><span>this is a test</span></div> ...and the following: <flowDiv><flowSpan>this is a test</flowSpan></flowDiv> ...with the following styles: div, flowDiv { font: 20px/20px serif; } span, flowSpan { font: 5px/10px sans-serif; } ...would look different. Assuming a sans-serif font with a baseline 20% above the bottom of the em quad, the first would be 21px high with the baseline 5px above the bottom (16px below the top), whereas the second would be 5px high with no leading whatsoever. And that's just a very simple example. (These cases would even be different if the line-height equaled the font-size throughout, so I guess I could make it _even_ simpler and still have differences.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 1 November 2004 09:25:02 UTC