W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

xml:space="" UA style sheet rule

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 17 Jan 2013 22:36:24 +1100
Message-ID: <50F7E238.7040000@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>
During last week's telcon we talked a bit about xml:space=""  the topic 
was more about the IDL attributes to access that and other attributes, 
but we drifted to xml:space="" support in general.  My stated opinion 
was that, although we should be discouraging xml:space="" and promoting 
white-space, that we still do need to support it in some way.

I believe previously we had resolved as part of my text proposals to 
support xml:space="" with a UA style sheet rule:

   svg|*[xml|space="preserve"] { white-space: some-new-value; }

where "some-new-value" means "like pre but discarding newlines", to 
match the SVG behaviour.  We have this implemented in Firefox currently 
as -moz-pre-discard-newlines.

But we have a report of this breaking content that looks like this:

   <svg xml:space="preserve">
     ...
     <text> ... </text>
     <foreignObject>
       ...
     </foreignObject>
   </svg>

So previously, when xml:space="" wasn't being mapped to white-space, the 
<foreignObject> would have had its initial value for white-space, 
"normal".  Now, the above content has -moz-pre-discard-newlines for the 
<foreignObject>.

It would be nice to not break content like this.  One possibility would 
be to have an additional UA style sheet rule:

   svg|foreignObject { white-space: normal; }

to counteract the earlier one.  That might be a bit strange if you wrote:

   <!doctype html>
   <body style="white-space: pre-line">
     <svg>
       ...
       <foreignObject>
         ...
       </foreignObject>
      </svg>
   </body>

and found that your white-space:pre-line didn't inherit into the 
<foreignObject>.  We could even write it as:

   svg|*[xml|space] svg|foreignObject { white-space: normal; }

so it would only occur if you're using xml:space="" on an ancestor, but 
that might be even hackier.

Suggestions welcome!
Received on Thursday, 17 January 2013 11:36:50 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT