XHTML for teaching

[Pierre Senellart]

I am going to teach a basic Web design course (fundamentals of HTML/CSS,
plus some basic client-side (JavaScript) and server-side (PHP, perhaps
XSLT) scripting). Most of the students do not have any previous knowledge
of all of this.

I am strongly considering teaching XHTML 1.0 Strict instead of HTML 4.01
strict, for the following reasons:
- XML syntax is far more simple to teach than HTML/SGML, simply because
there are not as many exceptions and subtleties.
- The stricter the language is, the stricter they are compelled to be
when writing webpages.
- It will be easier to use XSLT if they only know about XML and if they
remain the whole time in an XML world.
- They will have some other courses where XML is used, so that they
should be in familiar territory.
- XML is the future (rather lame argument, I know, but one I believe in
;-).

They would be required to validate all their webpages, obviously, so that
it will not be tag soup. Webpages would be served as text/html for IE
support (or I might try to install some content negociation mechanism)
and I would talk about respecting Appendix C compatibility rules (by the
way, is there an on-line tool for checking conformity with these?).

One of the major drawback I see is the obligation to remove the XML
prolog, to be sure IE is in strict mode for CSS, and therefore to make
sure that all webpages are in UTF-8.

Does anybody see any other reason not to use XHTML in this very specific
context?

--
Pierre Senellart

[Spartanicus]

Pierre Senellart <in*****@invali d.org> wrote:

Does anybody see any other reason not to use XHTML in this very specific
context?

There's nothing specific about your context.

Check out the current thread "XHTML 1.0 / 1.1 / 2.0" in this group, and
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

--
Spartanicus

[Pierre Senellart]

Spartanicus ,comp.infosyste ms.www.authoring.html:

Does anybody see any other reason not to use XHTML in this very specific
context?
There's nothing specific about your context.

Yes, there is. I provided a number of arguments in favor of XHTML in this
specific context. The main one is that it is much easier for
students to learn XML syntax than HTML syntax (all the more since the
HTML dialect that user agents understand is not formally described by
anything, and is definitely not described by SGML rules). The more
simple, the better.
Check out the current thread "XHTML 1.0 / 1.1 / 2.0" in this group, and
http://www.spartanicus.utvinternet.ie/no-xhtml.htm
I am familiar with these arguments, but I am still not convinced in
contrast with the arguments in my original message.

In particular:
# It's stricter.
There's nothing to stop an author from applying the same "strictness "
to HTML. This is purely down to the author, it doesn't need a stricter
DTD. You prefer having closing paragraph tags? What's stopping you from
using them? They are valid under HTML. For those that like the idea
that validation warns them if they for example forget to close a
paragraph element, it's not difficult to validate using a custom HTML
DTD that is as strict as the XHTML DTD. A short guide to validating
against a custom DTD.

I definitely do not want to make them validate against a cutom SGML DTD
they (and I, for that matter!) will not understand anything of.

[Henri Sivonen]

In article <dg***********@ nef.ens.fr>,
Pierre Senellart <in*****@invali d.org> wrote:

I am going to teach a basic Web design course (fundamentals of HTML/CSS,
plus some basic client-side (JavaScript)
Client-side JS interacts differently with application/xhtml+xml and
text/html.
I am strongly considering teaching XHTML 1.0 Strict instead of HTML 4.01
strict, for the following reasons:
- XML syntax is far more simple to teach than HTML/SGML, simply because
there are not as many exceptions and subtleties.
But if they send it as text/html, the subtleties are worse than learning
HTML.
- It will be easier to use XSLT if they only know about XML and if they
remain the whole time in an XML world.
TSaxon: http://mercury.ccil.org/~cowan/XML/tagsoup/tsaxon/
and I would talk about respecting Appendix C compatibility rules (by the
way, is there an on-line tool for checking conformity with these?).
http://qa-dev.w3.org/~bjoern/appendix-c/validator/
I don't know if it really works.
therefore to make
sure that all webpages are in UTF-8.
Using UTF-8 is the best practice that should be taught anyway.
Does anybody see any other reason not to use XHTML in this very specific
context?

The issues related to Appendix C are likely more confusing that HTML.
See also: http://www.hixie.ch/advocacy/xhtml

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Martin Honnen]

Pierre Senellart wrote:

I am going to teach a basic Web design course (fundamentals of HTML/CSS,
plus some basic client-side (JavaScript) and server-side (PHP, perhaps
XSLT) scripting). Most of the students do not have any previous knowledge
of all of this.

I am strongly considering teaching XHTML 1.0 Strict instead of HTML 4.01
strict, for the following reasons:
- XML syntax is far more simple to teach than HTML/SGML, simply because
there are not as many exceptions and subtleties.
- The stricter the language is, the stricter they are compelled to be
when writing webpages.
- It will be easier to use XSLT if they only know about XML and if they
remain the whole time in an XML world. They would be required to validate all their webpages, obviously, so that
it will not be tag soup. Webpages would be served as text/html for IE
support (or I might try to install some content negociation mechanism)
and I would talk about respecting Appendix C compatibility rules

But with XHTML served as text/html and all those compatibility rules the
trouble starts:

- For instance you say you want them to use XML all the time and then
XSLT too. Have you considered how you get the XSLT processor then to
transform to XHTML that follows the compatibility rules? XSLT 1.0 as
specified by the W3C has no support for that, it has output methods
text, xml, and html where the last is suitable for HTML (4) output and
where the xml output method is simply a general XML output method that
has no clue about any XHTML as text/html compatibility rules. So to
generate XHTML with XSLT 1.0 you can of course use the xml method but
whether an empty element like br is then serialized as
<br></br>
or
<br/>
or
<br />
is not something you could configure with most XSLT processors. And to
be compliant with the compatibility rules you would need to enforce
<br />
There are some XSLT processor which provide an additional output method
xhtml, there are XSLT processor where you can, depending on your
programming skills, write your own serializer and plug that in to make
sure you get XHTML complying with the compatibility rules but of course
all that is becoming processor dependent then.

- For basic client-side scripting you would probably use document.write
then for instance but in your XHTML documents treated as text/xml or
application/xml or application/xhtml+xml the method is not working. And
that is only one example for client-side scripting where your
expectation "XML syntax is far more simple to teach than HTML/SGML,
simply because there are not as many exceptions and subtleties." blows
up because you need to fullfill not only XML syntax but SGML syntax too
(Appendix C compatibility) and deal with all those exceptions and
subtleties that treating your documents as both text/html and
application/xhtml+xml introduces.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[David Dorward]

Pierre Senellart wrote:

Yes, there is. I provided a number of arguments in favor of XHTML in this
specific context. The main one is that it is much easier for
students to learn XML syntax than HTML syntax (all the more since the
HTML dialect that user agents understand is not formally described by
anything, and is definitely not described by SGML rules).

Whereas XHTML is supported by very few user agents but it often served as
text/html in which case it is handled by those same HTML dialect rules you
mentioned.

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Pierre Senellart]

Henri Sivonen ,comp.infosyste ms.www.authoring.html:

Client-side JS interacts differently with application/xhtml+xml and
text/html.
I thought the differences were quite minor, but after reading
http://www.hixie.ch/advocacy/xhtml I saw it was a bit more complex.
You have a point here.
TSaxon: http://mercury.ccil.org/~cowan/XML/tagsoup/tsaxon/
Yes, Gnome's libxslt also does this kind of thing (XSLT on HTML
documents), but it is still something I use only when I don't have the
choice.
http://qa-dev.w3.org/~bjoern/appendix-c/validator/
I don't know if it really works.

Thanks, I'll have a look.

Thanks for the other comments too, I am still pondering it.

[Guy Macon]

Pierre Senellart wrote:

I am strongly considering teaching XHTML 1.0 Strict ....One of the major drawback I see is the obligation to remove the XML
prolog, to be sure IE is in strict mode for CSS, and therefore to make
sure that all webpages are in UTF-8.

Or US-ASCII. :) We members of the ASCII Preservation Society wouldn't
want you to teach your students that the new-fangled eye-candy Johnny-
come-lately bloatware UTF-8 is the *only* choice. What if we run into
a bit shortage and can no longer afford a whole 8 bits per character?
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)

--
Guy Macon <http://www.guymacon.co m/>

[Alan J. Flavell]

On Sun, 18 Sep 2005, Guy Macon wrote:

Or US-ASCII. :) We members of the ASCII Preservation Society
wouldn't want you to teach your students that the new-fangled
eye-candy Johnny- come-lately bloatware UTF-8 is the *only* choice.

Bzzzzt! US-ASCII *is* utf-8. Or, at least, a subset of it.

SCNR.

[Guy Macon]

Alan J. Flavell wrote:

On Sun, 18 Sep 2005, Guy Macon wrote:

Or US-ASCII. :) We members of the ASCII Preservation Society
wouldn't want you to teach your students that the new-fangled
eye-candy Johnny- come-lately bloatware UTF-8 is the *only* choice.

Bzzzzt! US-ASCII *is* utf-8. Or, at least, a subset of it.

Right, but there are occasions where you have to choose between
encoding="utf-8" and encoding="US-ASCII" or between charset=utf-8
and charset=US-ASCII... A true ASCIIphile such as myself will
always explicitly specify the subset. There is no good technical
reason to do so, but it is well known that ASCII makes one much more
attractive to members of one's preffered gender... :)