RE: [css-gcpm] order of text replace vs. whitespace processing

You know you can make me more agreeable by saying this doesn't apply to browsers...

*if* text replace were to be supported, I would strongly recommend whitespace processing both before and after. It is particularly important after -- if not, it would add a new complication to engines that collapse whitespace at render time (which is the right place to collapse for dynamic content). 

-----Original Message-----
From: Håkon Wium Lie [mailto:howcome@opera.com] 
Sent: Tuesday, March 31, 2009 11:18 AM
To: Alex Mogilevsky
Cc: Ludger Buenger; www-style@w3.org
Subject: RE: [css-gcpm] order of text replace vs. whitespace processing

Also sprach Alex Mogilevsky:

 > In my opinion it should never apply. Text replace is certainly a  > useful and powerful tool, but I don't think it belongs to a styling  > system, not where it deals with plain text content. Whitespace is  > just one thing that makes it more complicated. Next, we'll want to  > make sure it works over element boundaries... And writing an editor  > over it is something I don't look forward to.

I think these are valid concerns, and I believe all browsers would agree with you. For batch processors doing printed publications, it's different -- they have a requirement to make these kinds of fixes at the end of the production line.

I suggest we add text to this effect into the draft so that

 - browsers/editors don't have to deal with it
 - batch processors may deal with it 

After all, we do want CSS to work in all places. Even in Russia :-)

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome