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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 28 Jul 2015 14:01:05 -0400
Message-ID: <55B7C361.3060201@inkedblade.net>
To: www-style@w3.org
On 07/27/2015 04:10 AM, Dirk Schulze wrote:
> Hi,
>
> The CSS3 Writing Mode spec currently says:
>
> "These values are deprecated in any context except SVG1 documents. Implementations
> that wish to support these values in the context of CSS must treat them as follows”
> <Table of mapping old value to new values>[1].
>
> 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).

I think it would be very easy for a UA to add a ua.css mapping of
   svg|*[writing-mode=tb] { writing-mode: vertical-rl; }
to support such content, now and into the future. And I'm happy to add
a note to Writing Modes clarifying that although these values are
deprecated in general, content that uses the presentation attributes
should continue to use the old forms as long as there are UAs out there
that need them.

> 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.

Hm, yes, the spec should not be requiring content-dependent parsing.

Does existing content need the CSS form of these aliases?

~fantasai
Received on Tuesday, 28 July 2015 18:01:45 UTC

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