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