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

 

> Also sprach Alex Mogilevsky:

> 

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

 

I definitely agree with your statement about it being particularly important after.

 

But applying whitespace processing both before and after makes things more complicated than I prefer things to be. I'd be happier if only once would suffice.

 

Is there a specific reason we need an additional whitespace processing step before replacement, e.g. in batch processors doing printed publications?

 

This actually leads in the direction at which level text replacement is supposed to be happening: upon the almost final rendered text or rather close to the original content of the dom requiring authors to be more aware of the spacings of their documents?

 

The current definition of the text-replace property already limits replacements to the content of an element but I can vividly imagine customers requesting it to work over element boundaries too.

 

 

And yes, text-replace for editors is definitely something I would consider evil because it makes the editor behave unpredictably strange for an non-replacement-aware user.

 

 

Ludger