Item8797: Foswiki term def syntax corrupts in-line CSS styles and JSON

I've discovered that CSS styles that are indented with 3 spaces "disappear". Two spaces works.

Co-worker theorizes that "since three leading spaces are significant to TWiki as a potential bulleted or numbered list, I think it’s anticipating the indentation as a list set-off and 'loses it' thereafter." It's certainly possible.

In any case, this code

<style>
 pre
{
   white-space: pre-wrap;       /* css-3 */
   word-wrap: break-word;       /* Internet Explorer 5.5+ */
}
</style>

shows up as

 pre {
 }

in the Firefox "Firebug" debugger. (And, therefore, the code inside the pre-block is absent and not used.)

Whereas this code

<style>
 pre
{
  white-space: pre-wrap;       /* css-3 */
  word-wrap: break-word;       /* Internet Explorer 5.5+ */
}
</style>

differing only in number of initial spaces, shows up as

 pre {
  white-space:pre-wrap;
 }

in Firebug.

-- VickiBrown - 29 Mar 2010

I don't see that behaviour. Testing both a style in the topic text and using ADDTOHEAD:

<style>
pre.style1 {
   color:green;
}
</style>

%ADDTOHEAD{text="<style>
pre.style2 {
   color:red;
}
</style>"}%

<pre class="style1">test text</pre>

<pre class="style2">test text</pre>

... results in:

test text

test text

-- ArthurClemens - 29 Mar 2010

It's the term definition syntax. It gets in the way of JSON too.

Arthur, your example didn't have a space after the colon in color:green. Inserted a space between color: green.

There doesn't seem to be a sensible way to inhibit the markup without introducing more formatting (eg. verbatim tags). So I can confirm, but not sure what to do about it.

This is really important for apps emitting JSON.

Example term definition:

   Green: Eggs and ham

Here it is:

Green

Eggs and ham

And the generated HTML:

<dl>
<dt> Green</dt><dd> Eggs and ham
</dd></dl> 

Firebug isn't enough, because it shows a parsed DOM view and it doesn't deal well with invalid syntax - you need to look at the raw html

Updated title of the bug

-- PaulHarvey - 29 Mar 2010

That's a known pitfall of inlining these things.

Wrap all inline style and script blocks into <literal> ... </literal>. I am not sure whether the renderer should do that automatically.

-- MichaelDaum - 30 Mar 2010

Of course, <literal> is the answer. I suppose this is no action after all.

-- PaulHarvey - 30 Mar 2010

See Item8929

-- PaulHarvey - 20 Apr 2010

Yep. No action.

-- CrawfordCurrie - 27 Jun 2010

Commenting is disabled while not logged in