[whatwg] CDATA - white space handling for param element values

[Shadow2531]

CDATA - white space handling for param element values

<http://www.w3.org/TR/html4/struct/objects.html#h-13.3.2>
<http://www.w3.org/TR/html4/types.html#type-cdata>

The current CDATA spec is:

1. Replace character entities with characters,
2. Ignore line feeds,
3. Replace each carriage return or tab with a single space.
4. User agents may ignore leading and trailing white space in CDATA
attribute values

I think #2, #3 and #4 should be dropped for a param element's value
attribute when defining things for HTML5.

A plug-in loaded with the object element might expect and accept
parameter values with Carriage returns, Line Feeds and Tabs. The
plug-in might accept leading and trailing white space.  Normalizing
the white space can be undesired in these cases. Using entities
instead of physical white space does not help the situation because of
#1, but #1 is still very useful.

A use case for passing in newlines is the tcl plug-in.
<http://www.tcl.tk/software/plugin/>

You can load inline tcl scripts with:
<object type="application/x-tcl">
    <param name="script" value="script content which contains newlines
entities or physical newlines">
</object>

With tcl, it is common to separate commands with newlines (as opposed
to semi-colons, which works too.). If newlines are stripped, it can
cause the plug-in to receive broken code. The xstandard plug-in may
encounter this at some point, not sure.

For an example of how following CDATA rules breaks things, see the
following in Opera (with the tcl plug-in installed and set up):
<http://shadow2531.com/opera/testcases/plugins/tcl/000.xhtml>

The tcl plug-in will receive a broken script because the Line Feeds
are stripped. You can workaround *this* problem by using semi-colons
instead of newlines:
<http://shadow2531.com/opera/testcases/plugins/tcl/000-fix1.xhtml>

This problem could break other plug-ins too.  The only real workaround
is to have to encode the value, pass it to the plug-in and have the
plug-in decode it. (if it can)

Since object element attributes can be params to plug-ins also, the
white space in their values should also not be normalized. However,
exceptions should be made for reserved attributes like: data, classid,
type, codebase, id, name, archive and possibly width and height. The
same type of thing should also be applied to the embed element.

Now, the reason I said to test the inline tcl script with Opera is,
Opera is the only browser that I've found to follow the CDATA specs
for the param element's value attribute. IE, Konqueror and Safari just
do character entity replacement and that's it. Firefox does like IE
except that it normalizes leading and trailing newlines and tabs.
However, Firefox strips newlines and tabs everywhere when passing to
the java plug-in for some reason.

IE's way of just doing character entity replacement and leaving all
white space in tact is what is really desired here.

You can check <http://shadow2531.com/opera/testcases/cdata/000.html>
in different browsers to see the differences in the handling of white
space for the param element's value attribute.

Questions:

1. For which attributes, for which elements should we allow white
space to stay in tact.

2. What procedure should be followed to get the value of an attribute
that may contain white space that should not be normalized?

For question #2, my answer is, "Do what IE does.".

On a side note, anyone know why Firefox strips all newlines when
passing to java?

-- 
burnout426