M8R-cyc3n3 wrote:

if this is about color properties within the style attribute being
interpreted as the start of an ordered list (on account of they both
begin with "#") this is another duplicate of bug 12974.

an regularExpression like that:
replace(/[\s\n\r\t]+, " "); //I'm not an expert
Also   and Co are not likely seen by some browsers.

you mean use this: http://php.net/manual/en/function.trim.php

\s by itself means all the above, just so you know.
exposing trim as a parser-function wouldn't be a bad idea either.

a.d.bergi wrote:

if this is about color properties within the style attribute being
interpreted as the start of an ordered list (on account of they both
begin with "#") this is another duplicate of bug 12974.

No, its about every property. Of course it could help with the color problem if the replace is executed before the rendering to lists, but bug 12974 is about all functions that begin with "{{" and not only in the style attribute.

an regularExpression like that:
replace(/[\s\n\r\t]+, " "); //I'm not an expert

you mean use this: http://php.net/manual/en/function.trim.php

No, trim just does it in the beginning and end of a string. I would like to use http://www.php.net/manual/en/function.preg-replace.php for every whitespace _in_ the string, between style properties and their values, wihin the values and among the diverse properties.

exposing trim as a parser-function wouldn't be a bad idea either.

You can already use {{#if:true| <many blanks> }}, and the returned value (also works with ifeq, ifexpr and switch) is automatically trimmed.

\s by itself means all the above, just so you know.

Thanks, Im never sure. Better to much than to less...

M8R-cyc3n3 wrote:

the mw parser already replaces consecutive spaces by a single space:

<span style="font-size: larger;">HELLO 1</span>

outputs cleanly as:

<span style="font-size: larger;">HELLO 1</span>

however it does not remove single undesired interior spaces, including
those before the colon and semi-colon in the following:

<span style=" border : 1px solid red ; ">HELLO 2</span>

either of which cause the parser to reject the above as a malformed css
property, rather than attempting to clean it up. the outputted html is
in fact:

<span style="">HELLO 2</span>

no use of the php trim feature or of a tautological parser function as in
your example would prevent this invalidation if the spaces are not at the
beginning or end of user input.

i suppose you could have the parser do some tidying like this inside the
aggregate style attribute (carefully to avoid removing needful spaces as
within "1px solid red"):

$style = preg_replace('/\s*(^|[\:\;]|$)\s*/g', '\\1', $style);

13 years later, do browsers we support still behave this way?