- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 28 Jul 2015 08:33:43 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- CC: Koji Ishii <kojiishi@gmail.com>, www-style list <www-style@w3.org>, www-svg <www-svg@w3.org>, "jfkthame@gmail.com" <jfkthame@gmail.com>
> On Jul 28, 2015, at 9:57 AM, Cameron McCormack <cam@mcc.id.au> wrote: > > 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. Of course it is wrong to use the same attribute name multiple times. That was actually my point. It is not possible to use the fallback mechanisms for presentation attributes. > >> 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.) We would want to use the new values at Adobe as soon as possible. However, cross browser compatibility is most important for customers of authoring tools. Koji wrote that he is in the process of unprefixing 'writing-mode' in Blink. Even the prefixed property does not apply to SVG text in WebKit and Blink though. And the already unprefixed old writing-mode implementation is incompatible to the prefixed one (solvable implementation dependent issues). Point is, WebKit and Blink will certainly use the old values for a longer period of time. If Firefox just uses the new property values we run into the described conflict. As said, export with presentation attributes is an often used option for many authors. It would be great if Firefox would add support for those old values and just maps them to the new values. Btw. Illustrator and Photoshop always used "writing-mode: tb;”. More content might work with Firefox by supporting those values. Greetings, Dirk > > 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 08:34:19 UTC