W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-writing-modes] 'writing-mode' and deprecated SVG values

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 28 Jul 2015 17:57:42 +1000
To: Dirk Schulze <dschulze@adobe.com>, Koji Ishii <kojiishi@gmail.com>
Cc: www-style list <www-style@w3.org>, www-svg <www-svg@w3.org>, jfkthame@gmail.com
Message-ID: <20150728075742.GA11105@wok.mcc.id.au>
Dirk Schulze:
> I have two issues with this:
> 
> 1) Presentation attributes:
> 
> In CSS you can usually do things like
> 
> .class { 
> 	writing-mode: tb; /*old SVG values*/
> 	writing-mode: vertical-lr; /*new CSS values*/
> }
> 
> For SVG, this would add support for the old values and the new
> values. However, this is not a possibility in XML with presentation
> attributes:
>
> 	<text writing-mode=“tr” writing-mode="vertical-lr”>..</text>
>
> would cause an XML parsing error. A attribute can not be declared
> twice. From Adobe products we know that presentation attribute export
> is still very popular and you find multiple JS libraries (like SVGO)
> which transform properties to attributes (even by default).

If those SVG optimizing tools do not work with multiple, overriding
style values for other properties, and they translate them to multiple
presentation attributes with the same name, then I’d say that’s a bug
and they shouldn’t do that. :-)

In general, presentation attributes just don’t support that style of
property value fallback, and if you need to do that, you have to use
CSS.

> 2) Implementation complexity
> 
> The spec currently just allows the values for SVG documents. It can
> not be determined at parse time if a property inheriting element
> will be in an HTML or an SVG context. (See inline SVG.) So the first
> sentence is actually hard to implement since the parser needs to
> accept the SVG values initially and then needs to verify if they apply
> to a certain element or not. A valid parsing is prohibited at the same
> time by the spec though.

Unless it were limited to values that come from parsing presentation
attributes.  But yes, I agree that if support these old keyword values
at all then they should be allowed whereever you can supply a
writing-mode value.

> For backward compatibility (WebKit and Blink support the old property
> values for SVG text) I would like to suggest to make them deprecated
> but mandatory. All values must be mapped as suggested by the spec
> currently.
>
> For tool creators and libraries it is just not possible to address
> browsers with full CSS3 Writing Mode support, browsers based on
> current WebKit and Blink as well as older (often proprietary) SVG
> viewers at the same time.

That’s really only the case if you don’t want to use CSS to do the
fallback thing.

I don’t really want to add these value aliases if it can be helped.  Is
it really true that there is content on the web that needs them?  (If
there is, then it’s pretty simple for us to add the aliases.)

Koji Ishii:
> I'm good with the proposal. Gecko and Trident already handle them as value
> aliases. I'm still under planning of how to unprefix writing-mode in Blink,
> but I think what Gecko did is the only reasonable choice.

FYI, Gecko does not support the old keyword values in our new Writing
Modes implementation.

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 28 July 2015 07:58:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC