Comments (late) on XHTML MIME

My apologies for the lateness of this mail. I promised to pass on the
following comments, which I believe we should review, but work got in
the way of doing so before yesterday's meeting.

The following is from David Dorward; and I must say I quite agree with
the comments he has made, now that he has drawn my attention to them :)



Regarding "XHTML Media Types - Second Edition", specifically the "W3C
Editor's Draft 21 November 2008".

Section 1 - Introduction

"explcitly" is misspelt.

1. Introduction

Paragraph four links to "#summary" (as do a number of other links in
the document), but no element has the id summary in the document.

Appendix A. Compatibility Guidelines

"It contains no absolute requirements, and should NEVER be used as
the basis for creating conformance nor validation rules of any sort.
Period."

I believe the second part of this should be struck or reworded.

Use case:

Entity A hires Web Developer B to write some XHTML. A wants the XHTML
to be compatible with as many user agents as possible, but you've
forbidden A from requiring that B follow some or all of the guidelines
in the document. It also forbids A from using the advice to create
their own internal coding standards!

Additionally, it forbids testing tools from being written that could
explain why a document does not work as expected.

Perhaps something along the lines of:

"It should not be treated as an update to any XHTML specification."

would achieve, what I assume is, the intended purpose without those
side effects.

A.3. Elements that have no content

Elements that are empty but which may have content are usually used
for styling purposes. Could a generic element such as div or span be
used for this example rather than p, which should rarely, if ever, be
free of content?

A.4. Embedded Style Sheets and Scripts

Avoiding ]]> in a script or style sheet has no effect unless you
use CDATA in a script element, but that is only necessary if the <
or & is used (and the rest of the guideline says to use external
scripts in that case).

Avoiding -- in a script or style sheet has no effect unless you
are wrapping the contents of the script or style element with <!--
and --> (which you should not do since ...)

The recommendation doesn't mention the old hiding script with comment
method, but the rationale does.

The rationale starts out talking about said comments, and then
blends into CDATA without explaining why CDATA is needed or
really covering the comment issue in detail.

I suggest something along the lines of:

DO use external style sheets and scripts if your style sheet or script
uses < or &.

DO NOT use HTML comment syntax around embedded style sheets or scripts.

Rationale:

<script> and <style> elements in HTML documents contain CDATA, but in
XHTML documents they contain PCDATA. This overrides the meaning of
special characters such as < (start of tag) or & (start of entity) in
documents delived as text/html but not in documents delivered using an
XML mime type.

When <script> and <style> elements were first introduced, most user
agents did not support them and treated the content of <script> and
<style> elements as text to be rendered. Comment syntax was permitted
inside those elements to hide that text from user agents that did not
support them. In XHTML those comments are treated as real comments and
hide the script from XHTML user agents making the syntax harmful,
while those user agents where it was beneficial are no longer in use
on the WWW.

Note that if you really need to embed scripts or style sheets, the
following technique can be used providing the comment syntax for the
language is not incompatible with the CDATA markers.

* Surround the content of the script or style element with CDATA
  markers for XHTML user agents

* Use the comment syntax of the script or style language to comment
  out the CDATA markers for HTML user agents

* DO NOT use the end of CDATA marker (]]>) within the script or
  style sheet.

For JavaScript:

<script type="text/javascript">
/* <![CDATA[ */
  window.alert('Scripting Enabled');
/* ]]> */
</script>

Alternate method for JavaScript:

<script type="text/javascript">
// <![CDATA[
  window.alert('Scripting Enabled');
// ]]>
</script>

For CSS:

<style type="text/css">
/* <![CDATA[ */
  body {
    background: white;
    color: black;
  }
/* ]]> */
</script>

A.5.

This sounds like generic advice for writing markup, rather then
something relevant to the differences between XHTML and HTML. I could
be mistaken and would welcome pointers to the relevant parts of the
specifications if so.

A.11.

Perhaps an example showing how to convert to lower case before
checking would help clarify this for some people?

A.25.

This is a new one on me. How is the content of the element treated
differently?

A.26.

The content of an iframe element should be alternative content for user
agents
that do not support, or have disabled, iframes.

What differences are there between how it is handled in HTML and XHTML? To
justify removing an accessibility feature I would expect them to be very
significant.

Appendix B. An Example Document

Until an update to RFC 2854 is published, I suggest not using XHTML
1.1 for examples of documents that may be served as text/html.

There is no "bad stuff" to escape in the <style> element. I suggest
removing the CDATA markers and placing that comment before the <script>
element.

I suggest using a grouping selector to apply the background colour,
not a copy and paste of the rule-set.


-- 
 - Tina Holmboe       siteSifter                  Greytower Technologies
            http://www.sitesifter.co.uk          http://www.greytower.net
      Website Quality and Accessibility Testing

Received on Thursday, 27 November 2008 16:51:47 UTC