HTML 5 and XHTML 2 combined

[Molte]

Why don't you go together combining HTML 5 and XHTML 2 to one future language to avoid a web standard war?

You could take the advantages of both languages and drop the disadvantages. The only problem would be that people would probably not agree with each other in what's good and bad, I just still believe it's stupid wasting time developing two languages when only one of them will be used in the end.

With the combined knowledge of both working groups we could have an even better language.

--
Molte

CosSinCalc
http://cossincalc.com

[David Woolley (E.L)]

Molte wrote:
> Why don't you go together combining HTML 5 and XHTML 2 to one future
> language to avoid a web standard war?

I think the cultures behind the two standards are so different that
trying to combine them would basically only leave you with the mass
market one.



--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Ian Hickson]

On Sat, 3 Jan 2009, Molte wrote:
>
> Why don't you go together combining HTML 5 and XHTML 2 to one future
> language to avoid a web standard war?
>
> You could take the advantages of both languages and drop the
> disadvantages. The only problem would be that people would probably not
> agree with each other in what's good and bad, I just still believe it's
> stupid wasting time developing two languages when only one of them will
> be used in the end.

As far as I'm aware all the advantages of XHTML2 that are not incompatible
with the goals of HTML5 have already been taken into HTML5 (e.g.
<section>, <a href=""> can contain blocks, <abbr> and <acronym> are merged
into one, compatibility with XML, etc).

Did you have any specific advantages of XHTML2 in mind?


> With the combined knowledge of both working groups we could have an even
> better language.

As the HTML5 spec's acknowledgements section indicates, the HTML5 working
group is already using the feedback and knowledge of many of the members
of the XHTML2 working group.

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jim Jewett]

On Sat, Jan 3, 2009 at 4:06 PM, Molte <molte93@...> wrote:
> Why don't you go together combining HTML 5 and XHTML 2 to one future
> language to avoid a web standard war?
>
> You could take the advantages of both languages and drop the disadvantages.

To make David's and Ian's comments more explicit:

One of the biggest advantages of XHTML2 is the cleaner model, which
they get by discarding legacy cruft.  HTML5 can't discard that cruft,
and XHTML2 wouldn't benefit by importing that cruft.  So combining the
standards wholesale won't work.

That said, there are some good ideas in XHTML2, such as <section>.
These generally have been combined into HTML5 on a piecemeal basis.

(XHTML2 could also import from HTML5, if they found something clean
enough to be worth importing.)

-jJ

[Molte]

If I've understood you well, what, I hear you all say, is that XHTML 2 and HTML 5 is not combinable because, they are based on two different "ideologies".

But as I said, I still believe it is stupid to develop them both when only one of them is going to be used; we must all agree on how we want the web to be.

I would like to quote Mr Hickson's signature, "Things that are impossible just take longer."

--
Molte

CosSinCalc
http://cossincalc.com

[Shavkat Karimov]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I agree with Molte, rather than trying to explain why it's not working, we need to concertrate on making it happen one day.

Dreamers are moving the world forward to the progress and success!

Kindest regards,

Shavkat

http://www.seomanager.com

---

Monday, January 5, 2009, 9:25:35 PM, you wrote:

If I've understood you well, what, I hear you all say, is that XHTML 2 and HTML 5 is not combinable because, they are based on two different "ideologies". But as I said, I still believe it is stupid to develop them both when only one of them is going to be used; we must all agree on how we want the web to be. I would like to quote Mr Hickson's signature, "Things that are impossible just take longer." --  Molte CosSinCalc http://cossincalc.com

[d1fvb]

On Mon, Jan 5, 2009 at 17:25, Molte <molte93@...> wrote:
>
> But as I said, I still believe it is stupid to develop them both when only
> one of them is going to be used;

I am not sure only one of them will be used. XHTML 2 is a generic
document language which may become a foundation for document-centric
apps that need an unambiguous way to include domain-specific data (via
RDFa). You may not see a lot of it on the open web, but it may well be
used a lot in specific technology domains.

So, maybe there will be a place for both?

Regards,

Peter

[Molte]

Are you saying that both might be W3C Recommendations?

Should we not only have one standard to show web pages on the web? Isn't it the reason for a standard?

2009/1/5 Peter Krantz <peter.krantz@...>

On Mon, Jan 5, 2009 at 17:25, Molte <molte93@...> wrote:
>
> But as I said, I still believe it is stupid to develop them both when only
> one of them is going to be used;

I am not sure only one of them will be used. XHTML 2 is a generic
document language which may become a foundation for document-centric
apps that need an unambiguous way to include domain-specific data (via
RDFa). You may not see a lot of it on the open web, but it may well be
used a lot in specific technology domains.

So, maybe there will be a place for both?

Regards,

Peter

--
Molte

CosSinCalc
http://cossincalc.com

[Shane McCarron]

We fully expect both to be W3C Recommendations.  They address different
needs and have different schedules.

Molte wrote:

> Are you saying that both might be W3C Recommendations?
>
> Should we not only have one standard to show web pages on the web?
> Isn't it the reason for a standard?
>
> 2009/1/5 Peter Krantz <peter.krantz@...
> <mailto:peter.krantz@...>>
>
>     On Mon, Jan 5, 2009 at 17:25, Molte <molte93@...
>     <mailto:molte93@...>> wrote:
>     >
>     > But as I said, I still believe it is stupid to develop them both
>     when only
>     > one of them is going to be used;
>
>     I am not sure only one of them will be used. XHTML 2 is a generic
>     document language which may become a foundation for document-centric
>     apps that need an unambiguous way to include domain-specific data (via
>     RDFa). You may not see a lot of it on the open web, but it may well be
>     used a lot in specific technology domains.
>
>     So, maybe there will be a place for both?
>
>     Regards,
>
>     Peter
>
>
>
>
> --
> Molte
>
> CosSinCalc
> http://cossincalc.com

--
Shane P. McCarron                          Phone: [phone] x120
Managing Director                            Fax: [phone]
ApTest Minnesota                            Inet: shane@...

[Molte]

I think both languages have advantages. I'll list some of the greater ones (after my opinion) below.

First of all HTML is from the time where you didn't use XML, but now nearly all major non-scripting languages to show something on the web is based on XML (of topic: why isn't CSS? It could use XPath to access the (X)HTML tags). And so should HTML be. Therefore you made up XHTML.

Having many languages based on XML is good, because then you can easily use more than one language in one document (for instance MathML in a XHTML document). It's also good that XML doesn't allow any slacking with the code like not making it well-formed. That makes it more device-independent and easier for browsers and applications to parse it without it would need a lot of error handling.

That the HTML 5 Working Group thinks they can rebirth HTML is without good reason in my eyes (why use an old, deprecated language when the newer is just better?).

In XHTML 2 all elements (nearly) can serve as a hyper link or an image. I would never have thought of that idea myself, but when I think about it, what is the reason to have the img and a tags? Then it's just crazy they keep the tags around when they're no longer needed...

Also a good thing about XHTML 2 is that it distances between structure and layout. That should make the job easier for screen-readers and such (and just make nicer code).

XHTML 2 uses XForms. After my opinion there is both pros and cons about that. That the layout is not defined makes the user able to choose which method to fill in a form he/she would prefer. But it also mean that you (as the web developer) can't control the layout, and therefore I think it might be triggy getting the input field to fit on the page when you don't know how it is going to look like. So I think you might keep the HTML Forms for now (alternatively you could allow both).

XHTML 2's role attribute might help defining your code and should be to prefer compared to HTML 5's predifined classes (you should be free to choose whatever you want for class names).

Now it should be time to see the good things about HTML 5...

Let's start off with the figure element; it's cool you finaly will be able to make a description to an object or image.

input is improved with support for e-mail, date, time, numbers, and URLs. Perhaps that is a better solution than the XForms?

Having tags like heading, footer, and so will better structurise the data.

And now, to end the good...

Of some reason HTML 5 includes old deprecated layout-tags like font used when there was nothing called CSS yet.

HTML 5 believes a language needs to be backwards compatible. I wonder if the persons behind that idea have ever though about, why you include the version number in the (X)HTML document... The browser should be able to parse many language versions differently.

In HTML 5 when using a WYSISYG editor you NEED to include which editor in the page. Why do everyone have to know what I'm using to make my code? The rule is probably there so the browser can avoid some errors, it knows, that particular editor always creates, but why not just make the editor generate valid code?

Waww... That was quite an e-mail. No matter I couldn't sleep this night, if that was what had to get out. Maybe I should publish it... :O

--
Molte

CosSinCalc
http://cossincalc.com

[bhawkeslewis]

On 6/1/09 15:24, Molte wrote:

> I think both languages have advantages. I'll list some of the greater
> ones (after my opinion) below.
>
> First of all HTML is from the time where you didn't use XML, but now
> nearly all major non-scripting languages to show something on the web is
> based on XML (of topic: why isn't CSS? It could use XPath to access the
> (X)HTML tags). And so should HTML be. Therefore you made up XHTML.
>
> Having many languages based on XML is good, because then you can easily
> use more than one language in one document (for instance MathML in a
> XHTML document).

> It's also good that XML doesn't allow any slacking with
> the code like not making it well-formed.

This is debatable.

> That makes it more
> device-independent and easier for browsers and applications to parse it
> without it would need a lot of error handling.

This is also debatable.

(See the recent discussions on www-tag about the importance of defining
how things are to be parsed.)

> That the HTML 5 Working Group thinks they can rebirth HTML is without
> good reason in my eyes (why use an old, deprecated language when the
> newer is just better?).

text/html has never been "deprecated" in the W3C sense.

For why HTML5 became a W3C effort, I refer you to Tim Berners-Lee:

http://dig.csail.mit.edu/breadcrumbs/node/166

> In XHTML 2 all elements (nearly) can serve as a hyper link or an image.
> I would never have thought of that idea myself, but when I think about
> it, what /is /the reason to have the img and a tags? Then it's just
> crazy they keep the tags around when they're no longer needed...

This isn't in HTML5 because browser vendors believed it would be too
complicated to actually implement IIRC.

> Also a good thing about XHTML 2 is that it distances between structure
> and layout. That should make the job easier for screen-readers and such
> (and just make nicer code).

This isn't an advantage peculiar to XHTML 2.

>
> XHTML 2 uses XForms. After my opinion there is both pros and cons about
> that. That the layout is not defined makes the user able to choose which
> method to fill in a form he/she would prefer. But it also mean that you
> (as the web developer) can't control the layout, and therefore I think
> it might be triggy getting the input field to fit on the page when you
> don't know how it is going to look like. So I think you might keep the
> HTML Forms for now (alternatively you could allow both).
>
> XHTML 2's role attribute might help defining your code and should be to
> prefer compared to HTML 5's predifined classes (you should be free to
> choose whatever you want for class names).
>
> Now it should be time to see the good things about HTML 5...
>
> Let's start off with the figure element; it's cool you finaly will be
> able to make a description to an object or image.
>
> input is improved with support for e-mail, date, time, numbers, and
> URLs. Perhaps that is a better solution than the XForms?
>
> Having tags like heading, footer, and so will better structurise the data.
>
> And now, to end the good...
>
> Of some reason HTML 5 includes old deprecated layout-tags like font used
> when there was nothing called CSS yet.
>
> HTML 5 believes a language needs to be backwards compatible. I wonder if
> the persons behind that idea have ever though about, why you include the
> version number in the (X)HTML document... The browser should be able to
> parse many language versions differently.
>
> In HTML 5 when using a WYSISYG editor you NEED to include which editor
> in the page. Why do everyone have to know what I'm using to make my
> code? The rule is probably there so the browser can avoid some errors,
> it knows, that particular editor always creates, but why not just make
> the editor generate valid code?
>
> Waww... That was quite an e-mail. No matter I couldn't sleep this night,
> if that was what had to get out. Maybe I should publish it... :O
>
> --
> Molte
>
> CosSinCalc
> http://cossincalc.com

[bhawkeslewis]

On 6/1/09 15:24, Molte wrote:
> It's also good that XML doesn't allow any slacking with
> the code like not making it well-formed.

Perhaps, though the utility of this is debatable. For example:

1. It makes integrating XHTML into the existing tolerant ecosystem of
the web, with tools that accept and emit tag soup and with much content
provision financed by incorporating arbitrary third-party code (ads),
very difficult.

2. Draconian error-handling reduces the chance that people will see your
ad, buy your products, read your content, or play your games, all
because of an unescaped ampersand (for example). Content producers tend
to prefer partial to total failure as an error state.

> That makes it more
> device-independent and easier for browsers and applications to parse it
> without it would need a lot of error handling.

Strictly defined processing requirements are more important than
arbitrary syntactical rigidity to making it easy to develop consuming
devices and applications, because it is processing requirements that
directly reduce the need for reverse engineering.

See also the current discussions along these lines on the www-tag
mailing list.

> That the HTML 5 Working Group thinks they can rebirth HTML is without
> good reason in my eyes (why use an old, deprecated language when the
> newer is just better?).

text/html has never been "deprecated" in the W3C sense.

As to why a new version of HTML is being developed by W3C, Tim
Berners-Lee has offered some reasons:

http://dig.csail.mit.edu/breadcrumbs/node/166

> In XHTML 2 all elements (nearly) can serve as a hyper link or an image.

Note this wasn't backported to HTML5 because browser vendors thought it
would be hard to implement.

> I would never have thought of that idea myself, but when I think about
> it, what /is /the reason to have the img and a tags? Then it's just
> crazy they keep the tags around when they're no longer needed...

If the more generic mechanisms can in fact be implemented, then yes the
specific mechanisms are likely redundant.

> Also a good thing about XHTML 2 is that it distances between structure
> and layout. That should make the job easier for screen-readers and such
> (and just make nicer code).

Can you explain what in a conforming HTML5 document might fail to
distance "structure" from "layout"?

> XHTML 2 uses XForms. After my opinion there is both pros and cons about
> that. That the layout is not defined makes the user able to choose which
> method to fill in a form he/she would prefer. But it also mean that you
> (as the web developer) can't control the layout, and therefore I think
> it might be triggy getting the input field to fit on the page when you
> don't know how it is going to look like.

I'm confused. Doesn't CSS apply to XForms, allowing authors to suggest
layout?

There are examples of applying CSS to XForms in the XForms 1.1 draft:

http://www.w3.org/TR/xforms11/

> XHTML 2's role attribute might help defining your code and should be to
> prefer compared to HTML 5's predifined classes (you should be free to
> choose whatever you want for class names).

HTML5 doesn't have predefined classes anymore.

I believe the role attribute is under consideration as part of ARIA.

> Let's start off with the figure element; it's cool you finaly will be
> able to make a description to an object or image.

I believe that's possible in XHTML2 too:

<img id="photo" src="cat.jpg">A black cat plays with a ball of string
beneath a Christmas tree.</img>
<p about="#photo" property="description">My cat Ernie fooling around
last Christmas.</p>

> input is improved with support for e-mail, date, time, numbers, and
> URLs. Perhaps that is a better solution than the XForms?

Note XForms includes these data types:

http://www.w3.org/TR/xforms11/#datatypes-xforms

> Having tags like heading, footer, and so will better structurise the data.

There is no "heading" element in HTML5 (I think you mean the "header"
element).

"header" is approximated by XHTML2's "role='banner'.

There's no approximation of the "footer" element AFAIK.

> Of some reason HTML 5 includes old deprecated layout-tags like font used
> when there was nothing called CSS yet.

"font" has been dropped from the conforming set of HTML5 elements.

HTML5 includes "b" and "i" with some semantic fig-leaves:

http://www.whatwg.org/specs/web-apps/current-work/#the-i-element

http://www.whatwg.org/specs/web-apps/current-work/#the-b-element

I'm dubious as to whether these meagre coverings guarantee media
independence, but I don't think their inclusion is going to make a major
practical difference to end-users, especially if the more specific
elements are used appropriately (e.g. heading elements for headings, em
for emphasis, strong for importance, mark for marked sections).
Conversely, their absence wouldn't guarantee the use of these other
elements. It's easy enough for a "WYSIWYG" editor to substitute:

<span class="italic">

and

<span class="bold">

in XHTML 2, for example.

Did you have any other elements in mind?

> HTML 5 believes a language needs to be backwards compatible. I wonder if
> the persons behind that idea have ever though about, why you include the
> version number in the (X)HTML document... The browser should be able to
> parse many language versions differently.

HTML5 attempts to define how browsers can interoperably parse the
existing text/html corpus such that the corpus is mostly usable;
previous HTML specifications do not do this. For example, they do not
define error handling - necessary for most of the corpus - in sufficient
detail.

As to why HTML5 tries to avoiding defining different parsing for a new
version, see:

http://wiki.whatwg.org/wiki/FAQ#How_are_pre-HTML5_documents_parsed.3F

> In HTML 5 when using a WYSISYG editor you NEED to include which editor
> in the page.

I believe you're referring to a requirement dropped from the draft a
long while ago. If not, could you please link to the relevant section of
the current draft?

http://www.whatwg.org/specs/web-apps/current-work/

--
Benjamin Hawkes-Lewis

[David Woolley (E.L)]

Molte wrote:
> I think both languages have advantages. I'll list some of the greater
> ones (after my opinion) below.

In practice, if W3C were to insist that there were only one combined
language, it would either be essentially the same as the current HTML5,
or the non-Microsoft browser developers would develop browsers for HTML5
and W3C would produce standards which they would ignore.

That's because HTML5 is basically a creation of the mainstream browser
developers, who are looking at what the mass market and marketing
businesses want.

With the XHTML2/HTML5 split, what you may well find is that there are
companies that implement tools for using XHTML2, but they will be sold
to businesses, particularly information based ones, rather than supplied
to the general public.

(Note Microsoft do not support XHTML either, but they would rather you
used their proprietary document languages.)

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Brett Patterson-5]

To throw my two cents worth, though after reading a lot of emails here, probably not worth 0.5 of a penny, I have to agree with Molte. Here are the questions I would like to know the answers of:

• What is the downside to having a mass market web coding standard?
• Why not use the disadvantages as well? If a coder is used to these disadvantages, then it will make it easier to develop a page, would it not? And how can you drop the disadvantages anyways? They're going to be there whether we like it not, right? Or are we all going to have to work overtime to help discuss and fix the disadvantages? I would say we should just leave them.
  
• So what if XHTML2 doesn't benefit from importing of the HTML5 "cruft," what would be the downside? How would it affect XHTML2, if it doesn't affect it in a good way, then how does it affect it in a bad way? If a bad point can be seen by all, could we not continue to use the Strict/Transitional models we have now. Where we don't import the "cruft" from HTML5 in the Strict Model, and do import it in the Transitional Model?I would see no difference in what we have now, unless you mean taking out Strict and Transitional period. Then where would be, especially when an unexpected and unseen problem arises? We can't, on a button, fix it when it needs to be fixed.
  
• So what if both languages are based on two different "ideologies"? To repeat Molte, "Things that are impossible just take longer." And this is ever so, undeniably, true. Just because there exists two "ideologies" does not constitute a "MUST keep it this way" attitude, does it? At any given instance, two "full-fledged" ideas can become one, all it takes is molding.
• As for "a foundation for document-centric apps that need an unambiguous way to include domain-specific data," could we not use what I stated in bullet 3? Only with the Strict portion of it?

I see no downside to combining the languages. After figuring out quick solutions to ALL that has been stated, not only from my e-mails but your own emails as well, are there really any downsides to combining them? Forgetting the plusses, but acknowledging the downsides, and the albeit major or smaller-than-should-be-considerable differences, I cannot, for the life of me, see why the languages have not already been combined, or even in the future why couldn't be combined.

--
Brett P.

On Tue, Jan 6, 2009 at 5:27 PM, David Woolley <forums@...> wrote:

Molte wrote:

I think both languages have advantages. I'll list some of the greater ones (after my opinion) below.

In practice, if W3C were to insist that there were only one combined language, it would either be essentially the same as the current HTML5, or the non-Microsoft browser developers would develop browsers for HTML5 and W3C would produce standards which they would ignore.

That's because HTML5 is basically a creation of the mainstream browser developers, who are looking at what the mass market and marketing businesses want.

With the XHTML2/HTML5 split, what you may well find is that there are companies that implement tools for using XHTML2, but they will be sold to businesses, particularly information based ones, rather than supplied to the general public.

(Note Microsoft do not support XHTML either, but they would rather you used their proprietary document languages.)

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[bhawkeslewis]

On 7/1/09 18:28, Brett Patterson wrote:

>     * Why not use the disadvantages as well?

Because they're _dis_advantages (i.e. bad) and XHTML 2 is intended as a
next-generation language?

>       They're going to be there whether we like it not, right?

They aren't going to be there in conforming XHTML 2 content, if any ever
gets produced.

>     * So what if XHTML2 doesn't benefit from importing of the HTML5
>       "cruft," what would be the downside?

A vastly more complex spec without any advantages that you've been able
to name?

If you want a backwards-compatible language with both text/html and
application/xhtml+xml serializations, and that can be reconciled with
the handling of existing web content, then you want HTML5.

If you want a next-generation language with an application/xhtml+xml
serialization that can specify completely different ways of handling its
content, even such that browsers would need to fork their code to handle
it, then you want XHTML 2.

HTML5 is premised on the constraints of supporting the existing web with
the same specification; XHTML 2 is premised on ignoring those constraints.

These goals aren't reconcilable, so the languages cannot be combined.
The best you could do is to find use-cases that one language meets but
the other does not and suggest solutions compatible with the goals of
that language to the relevant working group.

As the editor of the HTML5 spec noted earlier in the thread: "all the
advantages of XHTML2 that are not incompatible  with the goals of HTML5
have already been taken into HTML5".

I don't know if the editors of the XHTML 2 spec would say the reverse is
true.

If we try to extract the concrete suggestions to the XHTML 2 WG that are
not based on misconceptions about either spec, we find the following:

1. Drop "img" and "a" in favour of generic mechanisms ("src" and
"href"). HTML5 can't provide these mechanisms, although it can meet many
of the same use-cases through nesting inside "object" and "a". From what
I remember, the rationale given for preserving "img" and "a" in XHTML 2
was that it would help existing (X)HTML authors adjust to XHTML 2.

2. Add a way to represent the semantic of header and footer, on both a
page and section level. HTML5 provides this semantic through the
"header" and "footer" elements. XHTML 2 probably provides this already
with role="banner" and role="contentinfo" (from the ARIA spec) - except
it's missing a way to specify a header area for a section rather than a
page. Possibly you could define your own role with RDF to directly
approximate HTML5's "header", though that's not exactly author-friendly!

... that's it, as far as I can tell.

I can imagine other requests based on new features in HTML5 but none of
them have been made in this thread.

--
Benjamin Hawkes-Lewis

[Mark Birbeck-4]

Hi Benjamin,

I have a couple of comments on some of the misconceptions that have arisen.

> If you want a backwards-compatible language with both text/html and
> application/xhtml+xml serializations, and that can be reconciled with the
> handling of existing web content, then you want HTML5.
>
> If you want a next-generation language with an application/xhtml+xml
> serialization that can specify completely different ways of handling its
> content, even such that browsers would need to fork their code to handle it,
> then you want XHTML 2.

A mark-up language and a MIME type are distinct things. Many
organisations choose to generate documents that are technically XHTML,
but deliver them to browsers using an HTML MIME type, so as to 'force'
the browser to use its HTML parser for rendering.

This gives them the best of both worlds; they can use one or more of
the enormous number of XML tools around to generate their documents,
but they can still have these documents rendered in existing browsers,
without having to worry about whether the browser supports XHTML or
not.

The important thing here is that this technique also means that in
principle, even if a 'new' language is created, it could still be
processed by existing browsers, provided that the new language paid
attention to HTML processing rules.

So XHTML 2 could be delivered with an HTML MIME type, just as HTML5
could be delivered with an XHTML MIME type -- in both cases the
languages are distinct from the delivery mechanism.

Obviously that says nothing about which language is 'better' -- it
simply says that either language could stake a claim to backwards
compatibility, provided that it was careful about how it approached
the question of new features.


> HTML5 is premised on the constraints of supporting the existing web with the
> same specification; XHTML 2 is premised on ignoring those constraints.

I think this is a little misleading.

First, HTML5 adds new features that are not backwards-compatible with
HTML 4, but it just so happens that the close relationship between
some of the browser implementers and the spec writers mean that
features are being added quite quickly. In effect, the 'existing web'
is changing, even as we discuss it.

Second, XHTML 2 is not based on ignoring those constraints, although
it would probably be true to say that it was at its inception. For a
long time now XHTML 2 has had a modular architecture, which means that
language designers can create languages that use one or more of the
XHTML 2 modules, and implementers can provide support for whichever
modules they deem appropriate. This makes XHTML 2 useful not just in
browsers and constrained devices, but also for creating Docbook-style
languages, news formats, and so on.

Best regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[bhawkeslewis]

On 7/1/09 22:13, Mark Birbeck wrote:
> Many
> organisations choose to generate documents that are technically XHTML,
> but deliver them to browsers using an HTML MIME type, so as to 'force'
> the browser to use its HTML parser for rendering.

Yep. They send output in such a way as its processing has no detailed
conformance requirements, save for those that HTML5 will hopefully provide.

> This gives them the best of both worlds; they can use one or more of
> the enormous number of XML tools around to generate their documents,

Since a serialization to HTML could be appended to any toolchain
producing XHTML, I don't agree that serving text/html gives them this
option.

> but they can still have these documents rendered in existing browsers,
> without having to worry about whether the browser supports XHTML or
> not.

But they do need to worry about all the ways in which text/html differs
from application/xhtml+xml (without any conformance criteria), and they
do need to forgo any benefits of having their markup processed by
browsers as XML.

> The important thing here is that this technique also means that in
> principle, even if a 'new' language is created, it could still be
> processed by existing browsers, provided that the new language paid
> attention to HTML processing rules.

Yes, but I didn't mean HTML5 wasn't a new language, I'm saying XHTML 2
is moving beyond the constraints of the text/html serialization in
devising a new language.

> So XHTML 2 could be delivered with an HTML MIME type, just as HTML5
> could be delivered with an XHTML MIME type -- in both cases the
> languages are distinct from the delivery mechanism.

Yes. You could deliver any byte stream as text/html.

>> HTML5 is premised on the constraints of supporting the existing web with the
>> same specification; XHTML 2 is premised on ignoring those constraints.
>
> I think this is a little misleading.
>
> First, HTML5 adds new features that are not backwards-compatible with
> HTML 4, but it just so happens that the close relationship between
> some of the browser implementers and the spec writers mean that
> features are being added quite quickly. In effect, the 'existing web'
> is changing, even as we discuss it.
>
> Second, XHTML 2 is not based on ignoring those constraints, although
> it would probably be true to say that it was at its inception.

While HTML adds new features with backwards-compatibility problems, it's
a requirement that the new features are at least not incompatible with
the supporting the current web corpus.

AFAIK the feedback from browser vendors like Opera seems to be that
implementing XHTML 2 even in text/html is not compatible with supporting
the current web corpus. I would of course welcome a correction on this
point from popular browser vendors. :)

Under "Backwards compatibility", the draft clearly states that XHTML 2
depends on XML parsing:

"Because earlier versions of HTML were special-purpose languages, it was
necessary to ensure a level of backwards compatibility with new versions
so that new documents would still be usable in older browsers. However,
thanks to XML and style sheets, such strict element-wise backwards
compatibility is no longer necessary, since an XML-based browser, of
which at the time of writing means more than 95% of browsers in use, can
process new markup languages without having to be updated."

http://www.w3.org/TR/2005/WD-xhtml2-20050527/introduction.html#backCompat

If XHTML 2 is not taking advantage of XML to break free of the past,
perhaps this needs rephrasing?

> For a
> long time now XHTML 2 has had a modular architecture, which means that
> language designers can create languages that use one or more of the
> XHTML 2 modules, and implementers can provide support for whichever
> modules they deem appropriate. This makes XHTML 2 useful not just in
> browsers and constrained devices, but also for creating Docbook-style
> languages, news formats, and so on.

I don't really see what this has to do with text/html backwards
compatibility. If you mean some XHTML 2 modules could be reconciled with
text/html processing, that's probably true. The following seem like
possible examples that might more or less work as is:

* XHTML Document Module
* XHTML Structural Module
* XHTML Text Module
* XHTML Hypertext Module
* XHTML I18N Attribute Module
* XHTML Bi-directional Text Attribute Module
* XHTML Role Attribute Module
* Ruby Module
* XHTML Style Attribute Module
* XHTML Tables Module

These modules reflect features in existing text/html implementations
(multiple web engines support 'role'; Trident and a Firefox plugin
support supports Ruby).

Then there's modules that would definitely require new implementation
work, but aren't obviously incompatible with supporting the existing
text/html corpus without code branching and where the fallback might be
acceptable:

* XHTML List Module
* XHTML Edit Attributes Module
* XHTML Image Map Attributes Module
* XHTML Metainformation Attributes Module
* XHTML Media Attribute Module: media-specific content would be shown in
every media
* XHTML Object Module: fallback content
* XHTML Style Sheet Module: disabled attribute wouldn't work.


Here are some simple examples, drawn from the list of important changes:

that would be difficult to make work in text/html:

"in earlier versions of HTML, a p element could only contain simple
text. It has been improved to bring it closer to what people perceive as
a paragraph, now being allowed to include such things as lists and tables."

This wouldn't work in text/html because a table or list start tag must
close a paragraph for compatibility with existing content.

"XHTML 2 takes a completely different approach, by taking the premise
that all images have a long description"

This wouldn't work in text/html because text following an <image> tag
must be treated as text following an image, not alternate text, for
compatibility with existing content.

I agree some XHTML2 modules that represent a change from the
functionality provided by HTML5 could perhaps be implemented in
text/html without breaking support for the existing web corpus. Examples
may include:






Non-functional:



Non-examples may include:

* XHTML Embedding Attributes Module: Browser vendors say to hard to
implement src on every element.
* XHTML Handler Module: This doesn't look backwards compatible since
downlevel text/html browsers will display raw script on the page.
* XHTML Image Module: Unacceptable degradation plus impossible to implement.
* XHTML Hypertext Attributes Module: Browser vendors say too hard to
implement href on every element.
* XHTML Metainformation Module: <meta> with content ends the <head>
element in text/html; they may even be web corpus content depending on
the behavior
* XForms Module: associations between fields and labels wouldn't work;
"select" contents can't even be parsed into the DOM
* XML Events Module: event handling wouldn't work since it depends on
the Handler Module.










>
> Best regards,
>
> Mark
>

[bhawkeslewis]

On 7/1/09 22:13, Mark Birbeck wrote:
> Many
> organisations choose to generate documents that are technically XHTML,
> but deliver them to browsers using an HTML MIME type, so as to 'force'
> the browser to use its HTML parser for rendering.

Yep. They send output in such a way as its processing has no detailed
conformance requirements, save for those that HTML5 will hopefully provide.

> This gives them the best of both worlds; they can use one or more of
> the enormous number of XML tools around to generate their documents,

Since a serialization to HTML could be appended to any toolchain
producing XHTML, I cannot agree that serving text/html gives them this
option.

> but they can still have these documents rendered in existing browsers,
> without having to worry about whether the browser supports XHTML or
> not.

Instead, they need to worry about whether the browser processes their
particular XHTML acceptably as tag soup. Authors don't have any
conformance criteria for the subset of XHTML that's processable. And
this also means they do need to forgo any benefits of having their
markup processed by browsers as XML, such as mixing in other languages.
And since HTML 4.01 can be parsed to roughly the same DOM as their XML -
typically by the same tools - they're not making it substantially easier
for third-parties to process their content in an automated fashion.

> The important thing here is that this technique also means that in
> principle, even if a 'new' language is created, it could still be
> processed by existing browsers, provided that the new language paid
> attention to HTML processing rules.

Yes, but I didn't mean HTML5 wasn't a new language, I'm saying XHTML 2
is moving beyond the constraints of the text/html serialization in
devising a new language.

> So XHTML 2 could be delivered with an HTML MIME type, just as HTML5
> could be delivered with an XHTML MIME type -- in both cases the
> languages are distinct from the delivery mechanism.

Yes. You could deliver any byte stream as text/html.

>> HTML5 is premised on the constraints of supporting the existing web with the
>> same specification; XHTML 2 is premised on ignoring those constraints.
>
> I think this is a little misleading.
>
> First, HTML5 adds new features that are not backwards-compatible with
> HTML 4, but it just so happens that the close relationship between
> some of the browser implementers and the spec writers mean that
> features are being added quite quickly. In effect, the 'existing web'
> is changing, even as we discuss it.
>
> Second, XHTML 2 is not based on ignoring those constraints, although
> it would probably be true to say that it was at its inception.

While HTML adds new features with backwards-compatibility problems, it's
a requirement that the new features are at least not incompatible with
the supporting the current web corpus. There's also a general attempt to
ensure that with a bit of serverside processing you could provide an
acceptable user experience to most existing user agents. There are some
exceptions that would require publisher CSS or JS for an acceptable user
experience (the "hidden" attribute springs to mind, though authors are
already widely using display: none; to the same effect, as does
"datagrid", though authors are already creating equivalent features
using JS). But, as you note, the existing web is changing to implement
these features (e.g. canvas and video) such that these graceful
degradation problems will be substantially reduced when HTML5 becomes a
recommendation.

AFAIK the feedback from browser vendors like Opera seems to be that
implementing XHTML 2 even in text/html is not compatible with supporting
the current web corpus. I would of course welcome a correction on this
point from popular browser vendors. :)

Under "Backwards compatibility", the draft clearly states that XHTML 2's
element set depends on XML parsing:

"Because earlier versions of HTML were special-purpose languages, it was
necessary to ensure a level of backwards compatibility with new versions
so that new documents would still be usable in older browsers. However,
thanks to XML and style sheets, such strict element-wise backwards
compatibility is no longer necessary, since an XML-based browser, of
which at the time of writing means more than 95% of browsers in use, can
process new markup languages without having to be updated."

http://www.w3.org/TR/2005/WD-xhtml2-20050527/introduction.html#backCompat

If XHTML 2 is not taking advantage of XML to break free of the past,
perhaps this needs rephrasing?

> For a
> long time now XHTML 2 has had a modular architecture, which means that
> language designers can create languages that use one or more of the
> XHTML 2 modules, and implementers can provide support for whichever
> modules they deem appropriate. This makes XHTML 2 useful not just in
> browsers and constrained devices, but also for creating Docbook-style
> languages, news formats, and so on.

If you mean some XHTML 2 modules could be reconciled with text/html
processing, that's probably true. The following seem like possible examples:

* XHTML Document Module
* XHTML Structural Module
* XHTML Text Module
* XHTML Hypertext Module
* XHTML I18N Attribute Module
* XHTML Bi-directional Text Attribute Module
* XHTML Role Attribute Module
* Ruby Module
* XHTML Style Attribute Module
* XHTML Tables Module

These basically reflect features in existing text/html implementations.
Another group of modules introduce new features with (arguably)
acceptable fallbacks in existing text/html browsers that could perhaps
be implemented without breaking support for the text/html corpus:

* XHTML List Module
* XHTML Edit Attributes Module
* XHTML Image Map Attributes Module
* XHTML Metainformation Attributes Module
* XHTML Media Attribute Module
* XHTML Style Sheet Module

But there's a whole set of important modules that don't have acceptable
text/html fallbacks and/or probably couldn't be implemented without
breaking support for the text/html corpus:

* XHTML Embedding Attributes Module: Undisplayed images are not an
acceptable fallback, and IIRC browser vendors say it's too hard to
implement "src" on every element.
* XHTML Handler Module: Displaying raw script on the page is not an
acceptable fallback.
* XHTML Image Module: Missing alternative texts and alternative text
displayed beside a visible image is not an acceptable fallback, and
treating text after an 'img' tag as alternative text is not going to be
possible to implement alongside supporting the existing web corpus.
* XHTML Hypertext Attributes Module: Links that don't work are not an
acceptable fallback, and IIRC browser vendors say it's too hard to
implement "href" on every element.
* XHTML Metainformation Module: text following a "meta" tag is displayed
in text/html; that's not an acceptable fallback for human-unfriendly
content and there is likely to be existing content in the corpus that
depends on this behavior.
* XForms Module: Existing assistive technology cannot associate labels
with fields, select controls don't work; there are likely further
practical problems that represent unacceptable failures.
* XHTML Object Module: You would need to use different markup to get
this working in the most popular browser.
* XML Events Module: Event handling wouldn't work since it depends on
the Handler Module.

(Doubtless other people's versions of these lists would be different; I
certainly don't know enough about the implementation problems to provide
any sort of strong opinion.)

I was talking about XHTML 2 in the round, not individual modules. I
submit that if XHTML 2 was designed with an eye towards text/html
compatibility and implementability, (a) these modules would have been
designed quite differently and (b) their specs would mention differences
in text/html processing so that authors could avoid certain markup patterns.

These modules include some of biggest changes from HTML4/XHTML1:

http://www.w3.org/TR/xhtml2/introduction.html#s_intro_differences

They are certainly important enough to say you cannot simply produce an
straightforward "strictly conforming XHTML 2 document", serve it as
text/html, and expect text/html browsers to provide an acceptable user
experience for it now, or indeed ever.

I think unacceptably broken forms, scripts, machine data, links, and
images are sufficient disincentive to trying to serve XHTML 2 as text/html.

On the other hand, the advantages provided by using the remaining XHTML
2 modules fashion instead of just using the XML serialization of HTML5,
and then serving the result as text/html, are hard to understand. For
one thing, the later would give you much the same featureset but working
better in existing browsers, and for another, the later would include
forms, scripts, machine data, links, and images that work in text/html.

If the basic idea of XHTML 2 has really stopped being about throwing
text/html to the winds and taking advantage of XML to rationalize
document markup and started being about merely paring down HTML into a
document format and using external XML facilities where ever possible,
I'd imagine subsetting the following HTML5 features into separate XML
Schema modules would accomplish 90% of the same use cases with 10% of
the work for spec-writers, implementors, and authors:

head, title, base, script, body, section, nav, article, aside, h1, h2,
h3, h4, h5, h6, header, footer, p, pre, dialog, blockquote, ol, ul, li,
dl, dt, dd, cite, q, em, strong, code, ruby, rt, rp, ins, del, figure,
object, table, caption, colgroup, col, tbody, thead, tfoot, tr, td, th,
div, span, object

Specifying, implementing, and learning another language just to use
"blockcode" instead of "<pre><code>" really doesn't seem worth it. ;)

A "strictly conforming XHTML 2" conformance checker could simply verify
that the document was using only those features from HTML5, plus any
other non-HTML XML modules you want to include in XHTML2 (XForms, ARIA,
RDFa, XLink, XML Events, SVG, MathML, SMIL, whatever).

--
Benjamin Hawkes-Lewis

[bhawkeslewis]

On 8/1/09 19:52, Brett Patterson wrote:
> All in all, most of
> the same problems keep arising as an argument, and instead of trying to
> use the same arguments as, well, arguments, can we not try and figure
> out how those said arguments can be fixed?

Do you have any concrete suggestions?

e.g. You mentioned creating Transitional and Strict document types, but
it's unclear what user problems this would solve or how exactly it would
help merge HTML5 and XHTML2.

> As for some of the advantages I see, here goes:
>
>     * stops having to decide which language to go with.

Like with any other technology, people should evaluate whether it meets
their needs. I don't think that is a problem to be solved by creating
fewer technologies.

>     * it helps to ensure that most browser makers (not counting Internet
>       Explorer, as we all know how that goes) will not mix old languages
>       with the new or create their own languages, preventing page read
>       errors or hard coding times.

When you speak of browser vendors mixing "old languages with the new",
I'm not sure what you mean, or why it is a problem.

Why would combining HTML5 and XHTML2 would prevent browser developers
inventing their own language features?

>     * people can decide which is best for them to code with in general.
>       (if going with the Strict and Transitional subsets)

There are no plans to have a conforming subset of HTML5 including bad
features that it has any chance of persuading people not to use. That
approach to deprecation does not work, since people simply produce new
documents conforming to the bad subset. The failure of HTML 4.01
Transitional to be used only for old documents is testimony to that.

>     * less of a headache when coding applications, due mostly to less
>       rift-raft floating in the code. (if going with the cleaner code
>       from XHTML)

What sort of applications are you talking about?

What "rift-raft" are you talking about?

What "headache" are you talking about?

What "cleaner code" are you talking about? (And "cleaner" how?)

How would combining HTML5 and XHTML2 reduce this headache?

>     * makes requirements (or standards, specifications, whatever you
>       want to call it) for disabled people easier to cope with.

How?

>     * makes keeping requirements from the specifications of the code
>       itself easier.

I don't know what this means.

> I have a lot of other advantages, as well.

Rather than thinking up advantages, it might be worth trying to work out
what the goals of the two projects are and how it would be beneficial to
both projects to "combine" them and what "combining" them means in
practice. If you cannot be reasonably specific about why and how, it's
very difficult for anyone to evaluate such proposals.

Mark and I seem to be disagreeing about what the goals of XHTML 2 are.
I'm not part of the XHTML 2 WG (not sure about Mark's status), so I
don't feel I can speak with any authority on the matter. But I can point
you towards public documents describing what these projects are meant to
achieve.

+ HTML5

* HTML WG charter:
   http://www.w3.org/2007/03/HTML-WG-charter.html

* HTML WG Design Principles:
   http://www.w3.org/TR/html-design-principles/

* WHATWG Charter:
   http://www.whatwg.org/charter

* WHATWG FAQ:
   http://wiki.whatwg.org/wiki/FAQ

* HTML5 Introduction:
   http://www.whatwg.org/specs/web-apps/current-work/#introduction

+ XHTML 2

* XHTML 2 WG Charter:
   http://www.w3.org/2007/03/XHTML2-WG-charter

* HTML and XHTML FAQ:
   http://www.w3.org/MarkUp/2004/xhtml-faq

* XHTML 2 Introduction:
   http://www.w3.org/TR/xhtml2/introduction.html

I made a hypothetical proposal in the email you quoted, based on what
Mark seemed to be saying about XHTML2's goals. Does that merger match
what you're thinking of or not?

> But without knowing some of
> the more advanced features I will stop now before getting ahead of
> myself.

[snip]

> There is no true part of the two different languages that will prevent a
> language merger.

How can you say this with such certainty without "knowing some of the
more advanced features" that you are proposing be combined?

--
Benjamin Hawkes-Lewis

[Dustin Boyd]

Wow.  This is a rather interesting discussion!

I've chosen to try avoiding any debates about HTML 5 v.s. XHTML 2.0 as
well as any debates about the combination of the two.  Instead, I've
chosen to pose two simple questions:


- Different multimedia formats, different programming languages and
even different ways to deliver a package were all designed with
different goals in mind, so why is it that HTML 5 and XHTML 2.0 are
unable to coexist?

- HTML 4 and XHTML 1.x are currently used in mostly the same way.  An
author could use HTML 4.01 Frameset with deprecated markup to create a
page that looks the same as a page designed using XHTML 1.1 with CSS,
cross-browser rendering aside.  What might prevent HTML 5 and XHTML
2.0 from serving the same content with different markup, if anything?


It is my opinion that they should be able to coexist peacefully.  Who
said browser vendors COULDN'T or WOULDN'T support both?  Browser
vendors can support whatever specifications they choose.  The only
disadvantage that XHTML 2.0 has is that it relies upon other
specifications like Ruby, XForms, XML Events, etc. while HTML 5 is all
defined at once, which might also be considered a disadvantage itself.
 However, it isn't as if every browser MUST implement all of XHTML
2.0.  After all, text browsers like Lynx wouldn't necessarily need to
implement XML Events when implementing XHTML 2.0, right?  The same can
be said of AUDIO, VIDEO, OBJECT and CANVAS elements for a likewise
implementation of HTML 5.

As for them being able to serve the same content, why couldn't they?
MathML can be used to create the same rendering as LaTeX after all,
and they're vastly different languages!


Dustin