Xhtml menu

[Paul Coker]

How can I add a menu bar that is at the top of all my page in vaild Xhtml
1.1 without using frames?

Not one that stay up the top when you scroll down the page just on that is
up the top when the page loads.

 

[Adrienne]

Gazing into my crystal ball I observed "Paul Coker"

How can I add a menu bar that is at the top of all my page in vaild
Xhtml 1.1 without using frames?

Not one that stay up the top when you scroll down the page just on that
is up the top when the page loads.

Why do you have to use XHTML 1.1? Why not plain old HTML Strict? If you
read this group you will see reasons why XHTML is not a good idea.

Anyway, to answer your question, you can use server side includes, or a
preprocessor.

http://www.allmyfaqs.com/faq.pl?Include_one_file_in_another

 

[Spartanicus]

How can I add a menu bar that is at the top of all my page in vaild Xhtml
1.1 without using frames?

Apart from XHTML generally being a poor choice over HTML, serving XHTML
1.1 as text/html violates w3c guidelines, the exemption that XHTML that
conforms to appendix C guidelines may be served as text/html only
applies to XHTML 1.0, *not* XHTML 1.1.

 

[Neredbojias]

With neither quill nor qualm, Paul Coker quothed:

How can I add a menu bar that is at the top of all my page in vaild Xhtml
1.1 without using frames?

Not one that stay up the top when you scroll down the page just on that is
up the top when the page loads.

A server-side scripting method such as PHP is your surest and best bet.
Can also be done with javascript.

 

[Toby Inkster]

Apart from XHTML generally being a poor choice over HTML, serving XHTML
1.1 as text/html violates w3c guidelines, the exemption that XHTML that
conforms to appendix C guidelines may be served as text/html only
applies to XHTML 1.0, *not* XHTML 1.1.

I think this "rule" about not serving XHTML 1.1 as text/html is blown out
of proportion by a lot of people.

It is mentioned in this document http://www.w3.org/TR/xhtml-media-types/
but the document only has a status of a "Note" -- not a Standard, nor even
a Recommendation.

It is perfectly possible to produce XHTML 1.1 documents that are
compatible with HTML to the same extent as an XHTML 1.0 document would be
-- indeed many XHTML 1.1 documents can simply have their DOCTYPE changed
to XHTML 1.0 Strict and will continue to be valid.

With an XHTML 1.1 document that is reasonably compatible with existing
HTML user-agents, I would feel no compunction about serving it as
text/html; particularly to user-agents that would barf when confonted by
an XML content-type.

 

[Andy Dingley]

It is perfectly possible to produce XHTML 1.1 documents that are
compatible with HTML to the same extent as an XHTML 1.0 document would be

Agreed.

But why use XHTML 1.1 at all? There's a benefit of getting your
content into XML, because it can have benefits for content management
(threads passim) However 1.1 is no more "XML friendly" that 1.0.

 

[Spartanicus]

I think this "rule" about not serving XHTML 1.1 as text/html is blown out
of proportion by a lot of people.

You're welcome to argue with w3c that you don't agree with their
guidelines.

It is mentioned in this document http://www.w3.org/TR/xhtml-media-types/
but the document only has a status of a "Note" -- not a Standard, nor even
a Recommendation.

Which is why I said "w3c guidelines". Afaik content types and their use
are not and never have been formalized in a normative specification.
IIRC content types used to be "registered" by iana, but afaik that's no
longer the case. W3c has no authority to declare any content type a
"must". These matters are therefore contained in a non normative note. I
see no justification for ignoring it.

 

[Toby Inkster]

But why use XHTML 1.1 at all? There's a benefit of getting your
content into XML, because it can have benefits for content management
(threads passim) However 1.1 is no more "XML friendly" that 1.0.

And 1.1 is no more HTML-UA-hostile than 1.0 -- there is very little real
difference between them, except for the dropping of Frameset and
Transitional DTDs, which people shouldn't be using anyway.

 

[Toby Inkster]

I see no justification for ignoring it.

By ignoring it, you can increase the client support for XHTML 1.1 by about
500%. That is enough justification for me.

 

[Spartanicus]

By ignoring it, you can increase the client support for XHTML 1.1 by about
500%.

As with all XHTML served as text/html it does not result in XHTML being
"supported", it only means that browsers parse it as invalid tag soup.

It's delusional to think that there are any benefits to serving XHTML as
text/html instead of HTML to clients. There are nasty drawbacks to
serving XHTML, which makes HTML the sensible choice for many years to
come.

http://www.spartanicus.utvinternet.ie/no-xhtml.htm

 

[dingbat]

Copy the code between your page source code. This also allows you to
edit it for each page as needed, such as adding ...class="current"...
to the appropriate <li>

This is a simple and thus quick task. Just do it.

If you have a lot of pages then it's no longer quick. However in that
case you're probably looking at some sort of automated content
management and you can simply make the site generator / template do it
for you.

This is not an appropriate task for JavaScript or PHP. You might find
SSI useful and PHP might be one path to obtaining this feature, but
this still isn't "PHP programming".


(and drop the XHTML 1.1)

 

[Neredbojias]

With neither quill nor qualm, (e-mail address removed) quothed:

Copy the code between your page source code. This also allows you to
edit it for each page as needed, such as adding ...class="current"...
to the appropriate <li>

Even though I disagree with your last statement (below), this is the way
I do it. Why? Because it's faster and more reliable for the client.

 

[Andy Dingley]

Even though I disagree with your last statement (below), this is the way
I do it. Why?

So in what way is JavaScript useful here ? Unless you're running
ASP/JScript, then I assume you're loading a shared external .js file
with <script src="foo.js" > and having that execute when the page
loads, then using document.write() to generate the menu. This of course
fails when JS is unavailable.

And document.write() is itself the wrong way to modify the DOM

Because it's faster and more reliable for the client.

In what way is it "faster" or "more reliable"? It's worse on both
counts.

 

[Neredbojias]

With neither quill nor qualm, Andy Dingley quothed:

So in what way is JavaScript useful here ? Unless you're running
ASP/JScript, then I assume you're loading a shared external .js file
with <script src="foo.js" > and having that execute when the page
loads, then using document.write() to generate the menu. This of course
fails when JS is unavailable.

And document.write() is itself the wrong way to modify the DOM

Depends on how you define DOM. There's nothing any more wrong with
using javascript to modify a page than there is with using ASP, PHP,
Perl, or anything else as long as you have a viable fallback in case
javascript is deactivated.

In what way is it "faster" or "more reliable"? It's worse on both
counts.

I meant the "copy-and-paste" way, *not* using js/php, etc. What might
be termed "vanilla html (and css)" does seems to load faster and more
reliably overall.

 

[Toby Inkster]

Andy Dingley quothed:


Depends on how you define DOM. There's nothing any more wrong with
using javascript to modify a page

No, there is nothing wrong with using Javascript to modify a page.
However, there is something very wrong with using document.write to modify
an XHTML page.

http://ln.hixie.ch/?start=1091626816&count=1

 

[Neredbojias]

With neither quill nor qualm, Toby Inkster quothed:

No, there is nothing wrong with using Javascript to modify a page.
However, there is something very wrong with using document.write to modify
an XHTML page.

http://ln.hixie.ch/?start=1091626816&count=1

I dunno, TI. The author states that document.write doesn't work in xml
then proceeds to provide an example of invalid markup as proof.

Furthermore, the conclusion:

"So in order to remain compliant with XML, document.write() doesn't work
on documents that are parsed with an XML parser."

....is a double-talk way of *trying* to state that document.write isn't
complaint with the xml standard/official guidelines, which it fails to
do.

I think this whole thing is just an example of an invalid argument.

 

[dingbat]

That's a very clueless article.

 

[Richard Cornford]

Toby Inkster wrote:

I think this whole thing is just an example of an
invalid argument.

When scripting a web page you are scripting a document object model
created by the browser. If the document is an HTML document (including
tag soup) the browser will create an HTML DOM and when the document of
(real) XHTML the browser (assuming it can handle the document at all)
will create an XHTML DOM.

The two types of DOM are structurally similar but need handling in
different ways. HTML DOMs are case insensitive, disinterested in
namespaces, prefer direct setting of Element properties over the use of
the setAttribute method and provide numerous 'shortcut' properties. On
the other hand XHTML DOMs are case sensitive, require the use of
namespace qualified methods, prefer the use of setAttribute to property
assignment and tend not to provide 'shortcut' properties not explicitly
required by the W3C DOM specifications.

Very few non-trivial scripts are capable of operating with both HTML
DOMs and XHTML DOMs. One of the practical differences between the two
types of DOM is that in XHTML DOMs the document.write method is
unusable. It either fails silently (e.g. in Opera 7+) or they throw
exceptions (Mozilla). So it isn't really a question of whether
document.write is in some sense 'appropriate', but more a practical
consideration; it will not work in at least a significant proportion (if
not all) XHTML DOMs.

If mark-up is created as XHTML (preferably 1.0, Appendix C) and served
as text/html the browser (not unreasonably) assumes that the content
type is definitive and tag-soups the mark-up into an HTML DOM. The
result can happily be scripted as an HTML DOM (because it is), but that
script stands a really good chance of failing utterly in the event that
the same mark-up ever is interpreted as XHTML. And that is virtually
guaranteed to be true if the script uses document.write.

If the scripting of a document depends entirely on that document being
interpreted as an HTML document (and/or HTML tag soup), so that an HTML
DOM will be created to be scripted, many arguments for using mark-up
that resembles XHTML evaporate. For example, there is no 'future
proofing' in such mark-up because if the future ever allows the same
document to be served as XHTML its accompanying scripts would need to be
totally re-worked.

Richard.

 

[dingbat]

A well written explanation, thanks.

Would you mind taking hard-copies of it round to Doubleclick,
TangoZebra and friends and beating it into them with a clueiron. Thanks.

 

[Neredbojias]

With neither quill nor qualm, Richard Cornford quothed:

When scripting a web page you are scripting a document object model
created by the browser. If the document is an HTML document (including
tag soup) the browser will create an HTML DOM and when the document of
(real) XHTML the browser (assuming it can handle the document at all)
will create an XHTML DOM.

The two types of DOM are structurally similar but need handling in
different ways. HTML DOMs are case insensitive, disinterested in
namespaces, prefer direct setting of Element properties over the use of
the setAttribute method and provide numerous 'shortcut' properties. On
the other hand XHTML DOMs are case sensitive, require the use of
namespace qualified methods, prefer the use of setAttribute to property
assignment and tend not to provide 'shortcut' properties not explicitly
required by the W3C DOM specifications.

Very few non-trivial scripts are capable of operating with both HTML
DOMs and XHTML DOMs. One of the practical differences between the two
types of DOM is that in XHTML DOMs the document.write method is
unusable. It either fails silently (e.g. in Opera 7+) or they throw
exceptions (Mozilla). So it isn't really a question of whether
document.write is in some sense 'appropriate', but more a practical
consideration; it will not work in at least a significant proportion (if
not all) XHTML DOMs.

If mark-up is created as XHTML (preferably 1.0, Appendix C) and served
as text/html the browser (not unreasonably) assumes that the content
type is definitive and tag-soups the mark-up into an HTML DOM. The
result can happily be scripted as an HTML DOM (because it is), but that
script stands a really good chance of failing utterly in the event that
the same mark-up ever is interpreted as XHTML. And that is virtually
guaranteed to be true if the script uses document.write.

If the scripting of a document depends entirely on that document being
interpreted as an HTML document (and/or HTML tag soup), so that an HTML
DOM will be created to be scripted, many arguments for using mark-up
that resembles XHTML evaporate. For example, there is no 'future
proofing' in such mark-up because if the future ever allows the same
document to be served as XHTML its accompanying scripts would need to be
totally re-worked.

Richard.

Okay, I understand that (excellent) explanation much better. It would
seem (to me, at least) yet another good reason to stick with html unless
you have a really good reason to use xhtml/xml. Of course,
document.write probably isn't used on a high percentage of pages,
either, and has its own inherent limitations.