Xhtml menu

Discussion in 'HTML' started by Paul Coker, Jul 31, 2005.

  1. Paul Coker

    Paul Coker Guest

    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.
    Paul Coker, Jul 31, 2005
    #1
    1. Advertising

  2. Paul Coker

    Adrienne Guest

    Gazing into my crystal ball I observed "Paul Coker"
    <> writing in news:42ec1d9c$:

    > 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

    --
    Adrienne Boswell
    http://www.cavalcade-of-coding.info
    Please respond to the group so others can share
    Adrienne, Jul 31, 2005
    #2
    1. Advertising

  3. Paul Coker

    Spartanicus Guest

    "Paul Coker" <> wrote:

    >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.

    --
    Spartanicus
    Spartanicus, Jul 31, 2005
    #3
  4. Paul Coker

    Neredbojias Guest

    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.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
    Neredbojias, Jul 31, 2005
    #4
  5. Paul Coker

    Toby Inkster Guest

    Spartanicus wrote:

    > 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.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Jul 31, 2005
    #5
  6. Paul Coker

    Andy Dingley Guest

    On Sun, 31 Jul 2005 18:21:09 +0100, Toby Inkster
    <> wrote:

    >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.
    Andy Dingley, Jul 31, 2005
    #6
  7. Paul Coker

    Spartanicus Guest

    Toby Inkster <> wrote:

    >> 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.


    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.

    --
    Spartanicus
    Spartanicus, Jul 31, 2005
    #7
  8. Paul Coker

    Toby Inkster Guest

    Andy Dingley wrote:

    > 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 A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Aug 1, 2005
    #8
  9. Paul Coker

    Toby Inkster Guest

    Spartanicus wrote:

    > 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.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Aug 1, 2005
    #9
  10. Paul Coker

    Spartanicus Guest

    Toby Inkster <> wrote:

    >> I see no justification for ignoring it.

    >
    >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

    --
    Spartanicus
    Spartanicus, Aug 1, 2005
    #10
  11. Paul Coker

    Guest

    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)
    , Aug 1, 2005
    #11
  12. Paul Coker

    Neredbojias Guest

    With neither quill nor qualm, 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.

    > *snip*
    > This is not an appropriate task for JavaScript or PHP.


    --
    Neredbojias
    Contrary to popular belief, it is believable.
    Neredbojias, Aug 1, 2005
    #12
  13. Paul Coker

    Andy Dingley Guest

    On Mon, 1 Aug 2005 12:04:45 -0700, Neredbojias
    <> wrote:

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


    >> This is not an appropriate task for JavaScript or PHP.


    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.
    Andy Dingley, Aug 2, 2005
    #13
  14. Paul Coker

    Neredbojias Guest

    With neither quill nor qualm, Andy Dingley quothed:

    > On Mon, 1 Aug 2005 12:04:45 -0700, Neredbojias
    > <> wrote:
    >
    > >Even though I disagree with your last statement (below), this is the way
    > >I do it. Why?

    >
    > >> This is not an appropriate task for JavaScript or PHP.

    >
    > 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.

    >
    >
    > >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.


    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.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
    Neredbojias, Aug 2, 2005
    #14
  15. Paul Coker

    Toby Inkster Guest

    Neredbojias wrote:
    > Andy Dingley quothed:
    >
    >> 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


    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

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Aug 3, 2005
    #15
  16. Paul Coker

    Neredbojias Guest

    With neither quill nor qualm, Toby Inkster quothed:

    > Neredbojias wrote:
    > > Andy Dingley quothed:
    > >
    > >> 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

    >
    > 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.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
    Neredbojias, Aug 3, 2005
    #16
  17. Paul Coker

    Guest

    That's a very clueless article.
    , Aug 3, 2005
    #17
  18. Neredbojias wrote:
    > Toby Inkster wrote:

    <snip>
    >>> 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.

    <snip>
    > 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.
    Richard Cornford, Aug 4, 2005
    #18
  19. Paul Coker

    Guest

    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.
    , Aug 4, 2005
    #19
  20. Paul Coker

    Neredbojias Guest

    With neither quill nor qualm, Richard Cornford quothed:

    > Neredbojias wrote:
    > > Toby Inkster wrote:

    > <snip>
    > >>> 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.

    > <snip>
    > > 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.


    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.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
    Neredbojias, Aug 4, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    7
    Views:
    867
  2. chronos3d
    Replies:
    9
    Views:
    761
    Andy Dingley
    Dec 5, 2006
  3. Usha2009
    Replies:
    0
    Views:
    1,118
    Usha2009
    Dec 20, 2009
  4. xhtml champs
    Replies:
    0
    Views:
    448
    xhtml champs
    Aug 1, 2011
  5. xhtml champs
    Replies:
    0
    Views:
    1,014
    xhtml champs
    Aug 2, 2011
Loading...

Share This Page