[whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML 1.1 (PR#9627)

[Matthew Raymond]

Ian Hickson wrote:
> I would be more concerned about how they are intending on making
> XHTML2 compatible with XHTML1 than with the WHATWG work.

   Hopefully they won't revive the |version| attribute, as John M. Boyer
has suggested.

> For example,
> XHTML2's <input> element has basically completely different semantics
> than XHTML1's.

   That's because XHTML 2.0 simply reuses XForms in the XHTML namespace,
so the HTML WG isn't the place to debate this, unfortunately. You really
need to catch up on the public-appformats mailing list when you have the
opportunity. There's lively debate about <input>, XForms and WF2 there.
(Should we be CCing those messages to this mailing list?)

> Even simple elements like <img> and <q> are
> incompatible across the two versions, in the current draft.

http://www.w3.org/TR/xhtml2/mod-image.html#edef_image_img

| The img element is a holder for embedding attributes such as src.
| Since these attributes may be applied to any element, the img element
| is not strictly necessary, but is included to ease the transition to
| XHTML2.

   Why are they even including it then, especially since <object> has
the same content model and supports images?


http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_q

| Visual user agents must not by default add delimiting quotation marks
| (as was the case for the q element in earlier versions of XHTML and
| HTML). It is the responsibility of the document author to add any
| required quotation marks, either directly in the text, or via a style
| sheet.

   So what's the use of <q> in XHTML 2.0? If there's no difference
between the default styling and standard text, what's the web author's
motivation to use it?

   Furthermore, putting quotation characters in the markup is useless if
you want to quote a quote. In HTML and XHTML 1.x, you could simply nest
<q> elements, but that's not the case with XHTML 2.0.

   Also, why get rid of <acronym>? It's more widely supported than
<abbr>. Granted, it's sort of a subset of <abbr>, but acronyms are
common enough to justify their own element.

   The <l> and <br> elements might be able to coexist, so long as we
specify them correctly. For instance, <l> should never contain a <br>.
Would <l> be styled as block, though, rather than inline? What happens
if it runs over?

   Well, enough for now...