Re: Comments on XHTML Media Types Note 20080827

Thanks for your clarifications.  I have updated the editors draft to 
address the items below as indicated:

Simon Pieters wrote:
> On Wed, 22 Oct 2008 17:31:34 +0200, Shane McCarron <shane@aptest.com> 
> wrote:
>
>>> Don't use CDATA sections (except in <script> and <style>).
>> Yeah.  Actually, I think you shouldn't use them at all.  Is there a 
>> specific syntax that you believe is portable to XHTML and HTML?
>
> If you want to use "<" or "&" in a <script> or <style> element, you 
> have to use
>
>    <script>//<![CDATA
>    ...
>    //]]></script>
>
> or
>
>    <style>/*<![CDATA[*/
>    ...
>    /*]]>*/</style>
>
> for it to work in both HTML and XHTML.

I added this to the guideline about not using embedded scripts or 
stylesheets.  Sort of a "if you must, you can do it this way".

>
>
>>> Don't use <noscript>.
>> Why not?  I am not aware of a compatibility issue,
>
> <noscript> is parsed as a CDATA element in HTML when scripting is 
> enabled, and PCDATA when scripting is disabled. In XML it's always 
> parsed as PCDATA. So if you have, e.g.
>
>    <form><noscript><input name="x" 
> value="y"/></noscript><button>OK</button></form>
>
> the input will be successful in XHTML but not in HTML (when scripting 
> is enabled). (This isn't limited to just forms, though.)

I was unaware of this.  I added a guideline to avoid this.
>
>
>>> Don't use markup in <iframe>.
>> Again, why not?  I am not aware of an issue between HTML and XHTML in 
>> this regard.
>
> Same as <noscript>.

I added a guideline for this as well.
>
>
>>> Use createElementNS if supported and fall back to createElement. 
>>> (createElement as specced doesn't match reality and there's no 
>>> interop.)
>> What does createElementNS do in an HTML context?
>
> The same as it does in an XML context.

Added
>
>
>> Or, in that context, do you believe it is not supported?
>
> IE doesn't support createElementNS, hence the advice to fall back to 
> createElement.

Yeah... I also came across it as being unsupported in some server-side 
DOM implementations. 
>
>>> When setting innerHTML, make sure the string is both well-formed and 
>>> "HTML 4 compatible".
>> Agreed, although if I remember correctly innerHTML is not really part 
>> of a W3C spec.
>
> http://www.w3.org/TR/html5/dom.html#innerhtml0
> http://www.w3.org/TR/html5/dom.html#innerhtml1

I misspoke - I should have said "Recommendation".  I basically added 
advice saying don't use this construct since it is non-standard.  If you 
must use it, use it portably.

Thanks again!

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Wednesday, 22 October 2008 17:27:22 UTC