Validating <script> tags

[Toni Mcintyre]

i'm having 2 problems with the http://validator.w3.org

1. if i have:
<meta http-equiv="Content-Script-Type" content="text/javascript">
then why do i need <script type=text/javascript> everywhere???
i'm writing most of my code by hand, so this is a lot of extra typing or
global search and replace later

2. the other problem is with my include files:
i usually <script src="foo.js"></script>
but, the validator doesn't like this. after very much searching, i found
<script src="foo.js" />, but my browser (IE6) doesn't like this

i'd really like to get my pages validated because what i've written works at
home, but now that i'm someplace i can get them online, they don't all work
correctly - especially in Netscape
Toni Mcintyre
http://wildprop.sasktelwebsite.net/

[David Dorward]

Toni Mcintyre wrote:

i'm having 2 problems with the http://validator.w3.org

1. if i have:
<meta http-equiv="Content-Script-Type" content="text/javascript">
While servers may read HTML documents to look for such headers, I'm not
aware of any that actually do. You should configure your server to send
this as a real HTTP header.
then why do i need <script type=text/javascript> everywhere???
The Content-Script-Type header applies, IIRC, to those attributes relating
to intrinsic events (onclick, onmouseover and so on)
i'm writing most of my code by hand, so this is a lot of extra typing
or global search and replace later
Write a macro for your text editor to convert <script> to <script
type="text/javascript"> whenever you type it.
2. the other problem is with my include files:
i usually <script src="foo.js"></script>
but, the validator doesn't like this.
Aside from that lack of type attraibute, I don't see why it doesn't like it.
after very much searching, i
found
<script src="foo.js" />, but my browser (IE6) doesn't like this

No, IE 6 doesn't support XHTML yet.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

[David Håsäther]

Toni Mcintyre <ed***********@sasktel.net> wrote:

i'm having 2 problems with the http://validator.w3.org

1. if i have:
<meta http-equiv="Content-Script-Type"
content="text/javascript"> then why do i need <script
type=text/javascript> everywhere???
Because the type attribute is required for the script element. Also,
since the value contains a slash, it must be quoted.
2. the other problem is with my include files:
i usually <script src="foo.js"></script>
but, the validator doesn't like this.

Again missing a required type attribute.

--
David Håsäther

[Steve Pugh]

"Toni Mcintyre" <ed***********@sasktel.net> wrote:

i'm having 2 problems with the http://validator.w3.org

1. if i have:
<meta http-equiv="Content-Script-Type" content="text/javascript">
then why do i need <script type=text/javascript> everywhere???
Because the type attribute is required in whatever DTD your validating
against. That's all that validators do - they compare the code with
the DTD.

Actually you need <script type="text/javascript"> as the / character
is not one that can be unquoted in an attribute value.
i'm writing most of my code by hand, so this is a lot of extra typing or
global search and replace later
How many script elements do you have?
2. the other problem is with my include files:
i usually <script src="foo.js"></script>
but, the validator doesn't like this.
Beacuse it's missing the type attribute? What's the actual error
message the validator gives?

<script src="foo.js" type="text/javascript"></script> is perfectly
valid.
after very much searching, i found
<script src="foo.js" />, but my browser (IE6) doesn't like this
<element /> is fine if your writing XHTML (are you?) but can really
only be recommended for elements that are by nature empty (hr, img,
etc.).
i'd really like to get my pages validated because what i've written works at
home, but now that i'm someplace i can get them online, they don't all work
correctly - especially in Netscape

What's the URL of the pages your validating?
What DTD are you validating against?
What problems are you having in which versions of Netscape?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Brian]

In addition to what Steve Pugh about validation, I'd like to add the
following:

Toni Mcintyre wrote:

<meta http-equiv="Content-Script-Type" content="text/javascript">
That's to declare the script type for intrinsic events (onclick, etc.).
then why do i need <script type=text/javascript> everywhere???

To define the script type for the script contained in that particular
element.

http://www.w3.org/TR/REC-html40-9712....html#h-18.2.2

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Brian]

David Dorward wrote:

Toni Mcintyre wrote:

i have:
<meta http-equiv="Content-Script-Type" content="text/javascript">

While servers may read HTML documents to look for such headers, I'm
not aware of any that actually do. You should configure your server
to send this as a real HTTP header.

Oddly, the spec says that preference is given to the meta element, and
that a real http header should be used the absence of that meta element.

http://www.w3.org/TR/REC-html40-9712....html#h-18.2.2

In any case, I really don't understand why a default script type for
intrinsic events should not be in the markup itself. What purpose would
it server to put in a header? And, if it should be in the markup as the
spec says, why must it be in a <meta http-header...> element?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[David Dorward]

Brian wrote:

Oddly, the spec says that preference is given to the meta element, and
that a real http header should be used the absence of that meta element.

http://www.w3.org/TR/REC-html40-9712....html#h-18.2.2

This seems to contridict the part of the specification which describes meta,
which says:
,----
| The http-equiv attribute can be used in place of the name attribute and
| has a special significance when documents are retrieved via the Hypertext
| Transfer Protocol (HTTP). HTTP servers may use the property name specified
| by the http-equiv attribute to create an [RFC822]-style header in the HTTP
| response.
`----

and makes no mention that user agents should read it.

Which just adds to the evidence that <meta> is not somewhere to specify
anything important.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

[Albert Wiersch]

"David Dorward" <do*****@yahoo.com> wrote in message
news:c6*******************@news.demon.co.uk...

<script src="foo.js" />, but my browser (IE6) doesn't like this

No, IE 6 doesn't support XHTML yet.

Actually <script .../> is not valid XHTML. The script tag must have an end
tag in XHTML because it is not declared as EMPTY in HTML 4 (per XHTML
recommendation).

http://www.w3.org/TR/xhtml1/#h-4.3

--
Albert Wiersch
http://www.htmlvalidator.com/

[David Dorward]

Albert Wiersch wrote:

Actually <script .../> is not valid XHTML. The script tag must have an end
tag in XHTML because it is not declared as EMPTY in HTML 4 (per XHTML
recommendation).

http://www.w3.org/TR/xhtml1/#h-4.3

Actually, it is valid. However, I will concede, having reread that part of
the spec, that it is non-conforming.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

[Toni Mcintyre]

the url is
http://wildprop.sasktelwebsite.net/4sale/index.htm

the file i'm actually trying to validate is
file://Z:\wildprop.sasktelwebsite.net\4sale\album.htm but i don't think
it'll do you much good to know that ;-)

i'm still working on this offline, because i'm doing something rather
strange, but don't have any other resources available
- my "best" editor is wordpad
- my c compiler is TurboC 1988
- i have no dreamweaver or other code generator

so i'm writing a c program which processes the _header, content, and _tail
files and generates html and some javascript and using lots (way too
much???) of javascript so i can keep things consistent easily

1. using <meta http-equiv="Content-Script-Type" content="text/javascript">
and still <script type=text/javascript ...>
i've replaced all this
2. when i read everyone insisting on type="text/javascript" i went back
again and, wonder of wonders, i quit getting that particular error message
from the validator (end tag for element "SCRIPT" which is not open ) so it
seems that i should just listen to people who've been writing these
languages a lot more than i have

3. as for netscape: the pages are laid out with a banner along the top and a
few pictures in the left hand column and the menu all pretty in a table and
netscape wasn't doing any of that. BUT i had width=100% instead of
width="100%" (because i was too lazy to type the "), but i think that these
" are important and netscape will probably work when i change it all and
upload it again

so... thanks millions guys

toni mcintyre ed***********@sasktel.net http://wildprop.sasktelwebsite.net/

"we are the universe experiencing itself"

[Ashmodai]

David Dorward scribbled something along the lines of:

Albert Wiersch wrote:

Actually <script .../> is not valid XHTML. The script tag must have an end
tag in XHTML because it is not declared as EMPTY in HTML 4 (per XHTML
recommendation).

http://www.w3.org/TR/xhtml1/#h-4.3

Actually, it is valid. However, I will concede, having reread that part of
the spec, that it is non-conforming.

All not-EMPTY tags can contain content or nothing. Nobody stops you from
writing <script type="text/javascript"></script> or using the shorthand
which is <script type="text/javascript"/> (with an optional space before
the slash for backwards compatibility).
The validator WILL validate empty not-EMPTY elements like <p/> or <td/>
-- or <script ... />! It's valid because XML says so. XHTML cannot (and
does not) redefine that convention because it's a language using XML,
not another subset.

You just need to keep in mind that MSIE will not understand empty
elements but instead treat them as start tags as per HTML 4.01, i.e. all
elements that have a required closing tag in HTML 4.01 will NOT be
closed in MSIE unless you provide a closing tag. Shorthands might break
your layout or even the entire page (in the case of <script/> and
<style/> for example).

I don't know whether MSIE understands <img ...></img>, although this IS
valid as per XML (it just may not have anything enclosed by the tags --
it's just the expanded version of the self-closing tag you usually use).

I tend to use <td/> on unfinished pages (or for empty tds) rather than
<td></td>, just as I use <div/> for empty divs, because it saves
bandwidth and is also more pleasing to the eye when reading through
source code, IMHO.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Toni Mcintyre scribbled something along the lines of:
<snip/>

3. as for netscape: the pages are laid out with a banner along the top and a
few pictures in the left hand column and the menu all pretty in a table and
netscape wasn't doing any of that. BUT i had width=100% instead of
width="100%" (because i was too lazy to type the "), but i think that these
" are important and netscape will probably work when i change it all and
upload it again

<snip/>

Uhm... yes. The quotes are required by XML. If you want to omit the
quotes, use HTML 4.01, not XHTML. XHTML has very strict requirements and
things like omitting quotes can easily make XML-aware browsers (not
MSIE, MSIE doesn't care about XML when parsing what looks like HTML)
throw a blank page with a short error message instead of yer pretty layout.

In XHTML you need to follow all rules XML defines -- they aren't many
and they aren't utterly complicated, you just need to get used to them.
1. Write all predefined names (predefined attribute values like
"get"/"post" (in forms), all element names, all attribute names) in
lowercase (because they are defined in lowercase in the DTD)
2. Always use quotes (") or single-quotes (') to enclose attribute values
3. Always expand shorthands for boolean attribute values
('selected="selected"' instead of 'selected', 'disabled="disabled"'
instead of 'disabled', etc)
4. Use a Doctype header (<!DOCTYPE ... >) if you want to code by an
existing XHTML standard and set the namespace ('xmlns="..."' in the html
element)
5. (If using a doctype) only use elements and attributes that exist in
the XHTML standard you are using.
6. Always begin IDs with an alphabetical character, even if it seems
bothersome (#a1, rather than #1a)

There are most likely a few more but you just don't remember all the
rules if you apply them instinctively, which happens once you got used
to them.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Albert Wiersch]

"Ashmodai" <as******@mushroom-cloud.com> wrote in message
news:c6*************@news.t-online.com...

All not-EMPTY tags can contain content or nothing. Nobody stops you from
writing <script type="text/javascript"></script> or using the shorthand
which is <script type="text/javascript"/> (with an optional space before
the slash for backwards compatibility).
No, no one stops you, but it's not kosher per XHTML.
The validator WILL validate empty not-EMPTY elements like <p/> or <td/>
-- or <script ... />! It's valid because XML says so. XHTML cannot (and
does not) redefine that convention because it's a language using XML,
not another subset.
Just because it passes the validator, doesn't mean it's proper.
I tend to use <td/> on unfinished pages (or for empty tds) rather than
<td></td>, just as I use <div/> for empty divs, because it saves
bandwidth and is also more pleasing to the eye when reading through
source code, IMHO.

<td/> and <div/> are wrong according to the XHTML recommendation.

If you want to call them "valid" because it passes a validator, that doesn't
make it proper.

--
Albert Wiersch
http://www.htmlvalidator.com/

[Nick Kew]

In article <c6*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> writes:

( re XHTML)

All not-EMPTY tags can contain content or nothing. Nobody stops you from
writing <script type="text/javascript"></script> or using the shorthand
which is <script type="text/javascript"/>
True under XML rules.
(with an optional space before
the slash for backwards compatibility).
That "backwards compatibility" is the notorious Appendix C. And since
the shorthand <script/> is already in violation of that, adding a
space is - to put it mildly - an exercise in futility.
You just need to keep in mind that MSIE will not understand empty
elements but instead treat them as start tags as per HTML 4.01, i.e. all
MSIE isn't the only one. In fact it's normal and (arguably) perfectly
proper to treat XHTML served as text/html as tag-soup, and apply an
error-tolerant HTML parser.
I don't know whether MSIE understands <img ...></img>,
Error-tolerance suggests ignoring the HTML-bogosity </img>.
I tend to use <td/> on unfinished pages (or for empty tds) rather than
<td></td>, just as I use <div/> for empty divs, because it saves
bandwidth and is also more pleasing to the eye when reading through
source code, IMHO.

All of which is fine so long as you don't serve the pages as text/html.

--
Nick Kew

Nick's manifesto: http://www.htmlhelp.com/~nick/

[Bertilo Wennergren]

Albert Wiersch:

<td/> and <div/> are wrong according to the XHTML recommendation.

In my understanding there is nothing wrong with "<td/>" and "<div/>", if
the XHTML is served as "application/xhtml+xml". Only if you're serving
XHTML 1.0 as "text/html" wanting backwards compatibility, "<td/>" and
"<div/>" should be avoided - according to the XHTML recommendation as I
read it.

If that's not the correct reading, please quote what I've missed.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Steve Pugh]

Bertilo Wennergren <be******@gmx.net> wrote:

Albert Wiersch:

<td/> and <div/> are wrong according to the XHTML recommendation.

In my understanding there is nothing wrong with "<td/>" and "<div/>", if
the XHTML is served as "application/xhtml+xml". Only if you're serving
XHTML 1.0 as "text/html" wanting backwards compatibility, "<td/>" and
"<div/>" should be avoided - according to the XHTML recommendation as I
read it.

If that's not the correct reading, please quote what I've missed.

I think Albert already has:
http://www.w3.org/TR/xhtml1/#h-4.3
which says:
"All elements other than those declared in the DTD as EMPTY must have
an end tag. Elements that are declared in the DTD as EMPTY can have an
end tag or can use empty element shorthand"

The second sentence makes the distinction between having an end tag
and using the shorthad, so one presumes that the first sentence's
"must have an end tag" is unambiguous. However, if this is the case
then the appendix C.3 http://www.w3.org/TR/xhtml1/#C_3 is totally
pointless.

Of course, both section 4 and appendix C are informative rather than
normative.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Bertilo Wennergren]

Steve Pugh:

Bertilo Wennergren:

In my understanding there is nothing wrong with "<td/>" and "<div/>", if
the XHTML is served as "application/xhtml+xml". Only if you're serving
XHTML 1.0 as "text/html" wanting backwards compatibility, "<td/>" and
"<div/>" should be avoided - according to the XHTML recommendation as I
read it. If that's not the correct reading, please quote what I've missed.

I think Albert already has:
http://www.w3.org/TR/xhtml1/#h-4.3
which says: [...] Of course, both section 4 and appendix C are informative rather than
normative.

Indeed. Nothing in that text can override what's in the actual normative
text of the XML and XHTML recommendations.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Albert Wiersch]

"Bertilo Wennergren" <be******@gmx.net> wrote in message
news:c6*************@news.t-online.com...

Albert Wiersch:

<td/> and <div/> are wrong according to the XHTML recommendation.

In my understanding there is nothing wrong with "<td/>" and "<div/>", if
the XHTML is served as "application/xhtml+xml". Only if you're serving
XHTML 1.0 as "text/html" wanting backwards compatibility, "<td/>" and
"<div/>" should be avoided - according to the XHTML recommendation as I
read it.

According to my reading, if it's XHTML 1.0 then <td/> and <div/> and similar
should be avoided, regardless of how it's served. Where is the exception
made for how it is served? Neither does it say this is for backward
compatibility only. So my interpretation is that all documents claiming to
be XHTML 1.0 should adhere to this (XHTML 1.0 Section 4.3).

--
Albert Wiersch
http://www.htmlvalidator.com/

[Albert Wiersch]

"Bertilo Wennergren" <be******@gmx.net> wrote in message
news:c6*************@news.t-online.com...

Steve Pugh:

Indeed. Nothing in that text can override what's in the actual normative
text of the XML and XHTML recommendations.

Are you saying that you can throw out section 4.3 because it overrides a
normative section? If so, please tell me what you think it is overriding in
the normative text, because I don't see anything.

--
Albert Wiersch
http://www.htmlvalidator.com/

[Bertilo Wennergren]

Albert Wiersch:

"Bertilo Wennergren"

Albert Wiersch:

> <td/> and <div/> are wrong according to the XHTML recommendation.

In my understanding there is nothing wrong with "<td/>" and "<div/>", if
the XHTML is served as "application/xhtml+xml". Only if you're serving
XHTML 1.0 as "text/html" wanting backwards compatibility, "<td/>" and
"<div/>" should be avoided - according to the XHTML recommendation as I
read it. According to my reading, if it's XHTML 1.0 then <td/> and <div/> and similar
should be avoided, regardless of how it's served. Where is the exception
made for how it is served?
In the HTML Compatibility guidelines:

<URL:http://www.w3.org/TR/xhtml1/#guidelines>

Of course that's also just informative. It has meaning only as a
recommendation to those that want interoperability with old HTML user
agents.
Neither does it say this is for backward
compatibility only. So my interpretation is that all documents claiming to
be XHTML 1.0 should adhere to this (XHTML 1.0 Section 4.3).
It's just informative. It talks about the differences between XHTML 1.0
and HTML 4.01.
Indeed. Nothing in that text can override what's in the actual
normative text of the XML and XHTML recommendations.

Are you saying that you can throw out section 4.3 because it overrides
a normative section?
Wherever it says something that does not comply with what the normative
texts says, we should go by the normative texts.

In this particular case, since the context is a comparison with HTML 4,
it seems obvious that the "must" is based one the part about
interoperability in the XML recommendation (see below).
If so, please tell me what you think it is overriding in the normative
text, because I don't see anything.

You'll find it in the XML recommendation, that XHTML builds upon:

Empty-element tags may be used for any element which has no content,
whether or not it is declared using the keyword EMPTY. For
interoperability, the empty-element tag should be used, and should
only be used, for elements which are declared EMPTY.

<URL:http://www.w3.org/TR/2000/REC-xml-20001006#sec-starttags>

Thus, if there is no need for interoperability, "<element/>" and
"<element></element>" are completely equal. And that goes for any form
of XML (that does not override it in a normative part of its
specification). Here's the explicit meaning of "for interoperability" in
the XML recommendation:

[Definition: Marks a sentence describing a non-binding recommendation
included to increase the chances that XML documents can be processed
by the existing installed base of SGML processors which predate the
WebSGML Adaptations Annex to ISO 8879.]

<URL:http://www.w3.org/TR/2000/REC-xml-20001006#dt-interop>

For documents served as "application/xhtml+xml" there is hardly any need
for such interoperability. For documents served as "text/html" there is
indeed such a need.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Albert Wiersch]

"Bertilo Wennergren" <be******@gmx.net> wrote in message
news:c6*************@news.t-online.com...

In this particular case, since the context is a comparison with HTML 4,
it seems obvious that the "must" is based one the part about
interoperability in the XML recommendation (see below).

If so, please tell me what you think it is overriding in the normative
text, because I don't see anything.

You'll find it in the XML recommendation, that XHTML builds upon:

Yes, I see that, but XHTML builds upon XML and XHTML makes that additional
requirement, so to throw away the additional requirements of XHTML and go
back to just XML doesn't make any sense. You build upon something in that
manner in order to further define the requirements and specifics, and that
is what XHTML is doing.

I understand what you are saying, but I don't agree that you can write an
XHTML 1.0 document and call it valid and conforming and still use syntax
like <p /> and <div />. It is my interpretation that all XHTML 1.0 documents
should be written to be backward compatible.

Also, you said that in the HTML Compatibility guidelines, it gives
guidelines for interoperability. In my interpretation, that does not mean
that Section 4.3 may be thrown out if interoperability is not required.

It also says in section 1.3
"The XHTML family is designed with general user agent interoperability in
mind." And the clear wording of section 4.3 doesn't say that one can ignore
it under any circumstance. It clearly and strongly says "All elements other
than those declared in the DTD as EMPTY must have an end tag.". It doesn't
make any exceptions.

Thanks,
Albert

[Daniel R. Tobias]

"Toni Mcintyre" <ed***********@sasktel.net> wrote in message news:<10*************@corp.supernews.com>...

the file i'm actually trying to validate is
file://Z:\wildprop.sasktelwebsite.net\4sale\album.htm but i don't think
it'll do you much good to know that ;-)

That's not actually a proper URI, even for a local-system reference;
under the syntax rules, you need three slashes after the protocol to
represent an empty host element (or use "localhost" after the second
slash, alternatively), and forward slashes for all hierarchical levels
regardless of the local operating system convention. In other words,
the proper URI is:

file:///Z:/wildprop.sasktelwebsite.net/4sale/album.htm

Mozilla, for one, is pretty picky if incorrect "file:" URI syntax is
used.

--
Dan

[Jukka K. Korpela]

"Albert Wiersch" <mr************************************@wiersch.co m>
wrote:

Actually <script .../> is not valid XHTML.

It is. Maybe you should learn what "valid" means, and maybe use a
validator to help you there. Or maybe not - it can be instructive to see
that the salesman of a purported validator does not know such things.
People can then tune their expectations.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Toni Mcintyre]

"Ashmodai" <as******@mushroom-cloud.com> wrote in message
news:c6*************@news.t-online.com...

Uhm... yes. The quotes are required by XML. If you want to omit the
quotes, use HTML 4.01, not XHTML. XHTML has very strict requirements and
things like omitting quotes can easily make XML-aware browsers (not
MSIE, MSIE doesn't care about XML when parsing what looks like HTML)
throw a blank page with a short error message instead of yer pretty

layout.

So, in other words, MSIE is written for non-programmers so they can put
pages on MSN.
And, in totally other words, MSIE sucks -- now why doesn't that surprise me?

As for my problems: after argueing with the validator for awhile, things are
starting to work better. I may even have my slideshow do something more than
show a polar bear in a snow storm and require you to hit ctrl,alt,del a few
times to kill it.

Thanks for all the help.

Toni Mcintyre - ed***********@sasktel.net
http://wildprop.sasktelwebsite.net/4sale/

[Ashmodai]

Albert Wiersch scribbled something along the lines of:

"Bertilo Wennergren" <be******@gmx.net> wrote in message
news:c6*************@news.t-online.com...

Steve Pugh:

Indeed. Nothing in that text can override what's in the actual normative
text of the XML and XHTML recommendations.

Are you saying that you can throw out section 4.3 because it overrides a
normative section? If so, please tell me what you think it is overriding in
the normative text, because I don't see anything.

Don't mistake guidelines for rulesets. The appendix C is meant to
provide information for those interested in backwards compatibility
(XHTML is not really backwards compatible, you can just trick an HTML
parser into treating it as if it wasn't XHTML but HTML4). It doesn't
define any rules as to what is valid and what is not.
blockquotes as presentational markups is valid per the DTD but invalid
(or inapropriate) as per the recommendation. Element minimization of
non-EMPTY elements is valid as per the XML recommendation (an XML DTD
cannot influence this behavior as it's part of the subset (XML), not the
language (eg. XHTML)). The XHTML recommendation does not neglect that.
It only says what one should do or not do if one wishes backwards
compatibility with HTML 4.

Skipping the XML header is not really apropriate for XML files, but
XHTML mentions that this should be done for backwards compatibility.
However as of XHTML 1.1 the MIME type may not only but MUST be
application/xhtml+xml which voids all backwards compatibility already
because of the +xml suffix.
XHTML 1.0 is meant to ptovide means to allow a migration from HTML to
XHTML without droping backwards compatibility. However that doesn't mean
one has to follow the rules for backwards compatibility just because.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Albert Wiersch scribbled something along the lines of:

"Bertilo Wennergren" <be******@gmx.net> wrote in message
news:c6*************@news.t-online.com...

In this particular case, since the context is a comparison with HTML 4,
it seems obvious that the "must" is based one the part about
interoperability in the XML recommendation (see below).

If so, please tell me what you think it is overriding in the normative
text, because I don't see anything.
You'll find it in the XML recommendation, that XHTML builds upon:

Yes, I see that, but XHTML builds upon XML and XHTML makes that additional
requirement, so to throw away the additional requirements of XHTML and go
back to just XML doesn't make any sense. You build upon something in that
manner in order to further define the requirements and specifics, and that
is what XHTML is doing.

It doesn't have anything to do with "going back to XML". XHTML is a
language defined in XML. Part of the point is to allow combining XHTML
with MathML, SVG and other XML languages in one document via XML Namespaces.
The goal of XHTML is a "reformulation of HTML in XML". That means it
looks like HTML but it isn't. It is XHTML, which is an XML language --
although XHTML 1.0 in particular was designed to look like HTML for
XML-unaware parsers (like Microsoft Internet Explorer's).
I understand what you are saying, but I don't agree that you can write an
XHTML 1.0 document and call it valid and conforming and still use syntax
like <p /> and <div />. It is my interpretation that all XHTML 1.0 documents
should be written to be backward compatible.
Valid means it follows all rules defined in the DTD. Validity doesn't
have anything to do with "conforming with a recommendation". Blockquotes
as presentational elements are valid but they are not conforming to the
recommendation.

Element minimization of non-EMPTY elements is both valid and conforming
(to XML and XHTML), although it may be inapropriate for backwards
compatibility. One should follow either all rules for interoperability
or none. Mixing only causes problems.
If one wants to minimze non-EMPTY elements, one SHOULD use the
application/xhtml+xml MIME type and SHOULD NOT use the text/html MIME
type because element minimzation/extension breaks backwards
compatibility. However, if one already uses that MIME type anyway, one
could as well go ahead and write (XHTML 1.1|XHTML 1.0 Strict) rather
than XHTML 1.0 (Transitional|Frameset).
Also, you said that in the HTML Compatibility guidelines, it gives
guidelines for interoperability. In my interpretation, that does not mean
that Section 4.3 may be thrown out if interoperability is not required.
HTML compatibility is an informative section. Informative sections
discuss problems or provide solutions to problems (or even elaborate on
certain historical topics etc).
Note that the informative sections contain no normative definitions. As
for the occurance of must/should/may/etc in lowercase:
"Occurrences of these words in lowercase comprise normal prose usage,
with no normative implications." ("Terminology" section in almost every
recommendation and spec).

Informative guidelines are "techniques", normative guidelines are the
rules. If the techniques are not applied, but the rules are being
respected, there's no conformance problem.
It also says in section 1.3
"The XHTML family is designed with general user agent interoperability in
mind." And the clear wording of section 4.3 doesn't say that one can ignore
it under any circumstance. It clearly and strongly says "All elements other
than those declared in the DTD as EMPTY must have an end tag.". It doesn't
make any exceptions.

XHTML 2 drops all backwards compatibility and XHTML 2 is part of the
XHTML family. How does that go with what you are quoting? XHTML 1.0 is
meant as a transition from SGML HTML to XML XHTML. Thus one should
follow the interoperability rules if one wants to make a seamless
migration. If one doesn't want to, that's okay.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Albert Wiersch]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. .

"Albert Wiersch" <mr************************************@wiersch.co m>
wrote:

Actually <script .../> is not valid XHTML.

It is. Maybe you should learn what "valid" means, and maybe use a
validator to help you there. Or maybe not - it can be instructive to see
that the salesman of a purported validator does not know such things.
People can then tune their expectations.

When the XHTML recommendation says that <script ... /> must not be used
(<script> ... </script> must be used instead), most people would say that
<script ... /> is not valid. However, I understand that "valid" has only one
meaning when you use it, and that's if it passes validation by a DTD
validator. So in that case, you're right... but other may find it confusing
when you say that inappropriate syntax is valid. It may be technically
valid, but it's also inappropriate.

--
Albert Wiersch
http://www.htmlvalidator.com/

[Ashmodai]

Nick Kew scribbled something along the lines of:

In article <c6*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> writes:

( re XHTML)

All not-EMPTY tags can contain content or nothing. Nobody stops you from
writing <script type="text/javascript"></script> or using the shorthand
which is <script type="text/javascript"/>

True under XML rules.

(with an optional space before
the slash for backwards compatibility).

That "backwards compatibility" is the notorious Appendix C. And since
the shorthand <script/> is already in violation of that, adding a
space is - to put it mildly - an exercise in futility.

You just need to keep in mind that MSIE will not understand empty
elements but instead treat them as start tags as per HTML 4.01, i.e. all

MSIE isn't the only one. In fact it's normal and (arguably) perfectly
proper to treat XHTML served as text/html as tag-soup, and apply an
error-tolerant HTML parser.

I don't know whether MSIE understands <img ...></img>,

Error-tolerance suggests ignoring the HTML-bogosity </img>.

I tend to use <td/> on unfinished pages (or for empty tds) rather than
<td></td>, just as I use <div/> for empty divs, because it saves
bandwidth and is also more pleasing to the eye when reading through
source code, IMHO.

All of which is fine so long as you don't serve the pages as text/html.

The solution is to run your XHTML through a preprocessor like PHP. As I
only work with dynamic pages, I have no problem. All I need to do is
check if the browser understands XHTML (except for user agent strings
and accept headers there isn't much of a way to do that tho -- and both
of them do not guarantee that you're not simply sending backwards
compatible XHTML to a XHTML capable browser which is too shy to tell you
it does understand correct XHTML) and then send either pure XHTML (i.e.
not backwards compatible, but entirely valid XML) or run your XHTML
through a search and replace function which extends minimized non-EMPTY
elements, minimizes EMPTY ones, removes the XML header and optionally
sets an XHTML 1.0 Transitional doctype (I always use XHTML 1.0
Transitional for text/html XHTML-"tagsoup" and XHTML 1.1 for
application/xhtml+xml) and then pass it to the browser with a matching
MIME type.

If you do not have that option, you need to decide whether you want
"backwards compatibility" or use the real power of XHTML.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Toni Mcintyre scribbled something along the lines of:

"Ashmodai" <as******@mushroom-cloud.com> wrote in message
news:c6*************@news.t-online.com...

Uhm... yes. The quotes are required by XML. If you want to omit the
quotes, use HTML 4.01, not XHTML. XHTML has very strict requirements and
things like omitting quotes can easily make XML-aware browsers (not
MSIE, MSIE doesn't care about XML when parsing what looks like HTML)
throw a blank page with a short error message instead of yer pretty

layout.

So, in other words, MSIE is written for non-programmers so they can put
pages on MSN.
And, in totally other words, MSIE sucks -- now why doesn't that surprise me?

As for my problems: after argueing with the validator for awhile, things are
starting to work better. I may even have my slideshow do something more than
show a polar bear in a snow storm and require you to hit ctrl,alt,del a few
times to kill it.

In order to prevent a browser discussion, I would say MSIE doesn't suck,
it just doesn't treat XHTML as XHTML but as HTML tagsoup, which it
supports like nothing else.

Whether supporting tagsoup is a good thing or a bad one is a matter of
discussion (my personal and the opinion of most standards lovers is that
it is a very bad thing because one doesn't have to learn to follow
standards and thus stays unaware tagsoup will break in other browsers or
that there are any standards in the first place).

If you want to check whether your XHTML is correct XML, run it through a
Gecko browser (Mozilla, Firefox, ...) or another XML aware browser
rather than MSIE.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Albert Wiersch scribbled something along the lines of:

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn****************************@193.229.0.31.. .

"Albert Wiersch" <mr************************************@wiersch.co m>
wrote:

Actually <script .../> is not valid XHTML.

It is. Maybe you should learn what "valid" means, and maybe use a
validator to help you there. Or maybe not - it can be instructive to see
that the salesman of a purported validator does not know such things.
People can then tune their expectations.

When the XHTML recommendation says that <script ... /> must not be used
(<script> ... </script> must be used instead), most people would say that
<script ... /> is not valid. However, I understand that "valid" has only one
meaning when you use it, and that's if it passes validation by a DTD
validator. So in that case, you're right... but other may find it confusing
when you say that inappropriate syntax is valid. It may be technically
valid, but it's also inappropriate.

It's invalid in HTML 4 therefore it is not recommended if you are
following the HTML compatibility guidelines. That doesn't mean it's
inapropriate per se tho.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Brian]

Albert Wiersch wrote:

When the XHTML recommendation says that <script ... /> must not be
used (<script> ... </script> must be used instead), most people would
say that <script ... /> is not valid.
Well, they would be, from a technical standpoint, wrong.
However, I understand that "valid" has only one meaning when you use
it, and that's if it passes validation by a DTD validator.
Correct. And it would be good to stick with this; to mix up "valid" and
"well-authored" or "good markup" will only confuse matters even more,
especially for novices.
but other may find it confusing when you say that inappropriate
syntax is valid.
That's why I never recommend XHTML. There are things you can write that
are technically valid, but will cause problems with real-world browsers.
Well, ok, that's actually true of HTML, too.

<p/ anyone?

http://www.cs.tut.fi/~jkorpela/html/validation
It may be technically valid, but it's also inappropriate.

That's the sad state of XHTML for the most part. Even valid pages in
that language are inappropriate for most authors. Only if you're willing
to go to great lengths (as Mark Tranchant appears to have done) would it
be advisable. While HTML may have its own problems, it is a more robust
solution.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/