SitePoint Sponsor

User Tag List

Results 1 to 25 of 25
  1. #1
    SitePoint Evangelist cturner01's Avatar
    Join Date
    Jun 2006
    Location
    My computer
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Navigation issue

    I am have been trying to work out to prevent the navigation bar, which I have been working with, from having a thick blue line along the top of the navigation bar. Could someone please have a look at my css, and tell me how I can fix it?

    HTML and CSS

    Real navigation bar without the text

    Thanks in advance.

  2. #2
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Just remove the top padding on ".topnav"

    Since you have the image set to repeat (default) it will go up and down repeating until the entire width/height is filled. The padding is just part of the image
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  3. #3
    SitePoint Evangelist cturner01's Avatar
    Join Date
    Jun 2006
    Location
    My computer
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, RyanReese for your help. I have done that, and am onto another problem.

    The new problem is the spacing between each navigation link isn't right. My client wants to be able to add other pages to his website later on, so the spacing between each link not only needs to be equal, there needs to be space between the last navigation link and the end of the navigation bar, for the new pages to be added. I have uploaded the new problem to the link above. I will add the link to this reply, please see below for the link.

    HTML and CSS

    I must mention that the css must be cross-browser.

    Does anyone know of a good drop down menu, which I can use the product range navigation link?

  4. #4
    SitePoint Evangelist cturner01's Avatar
    Join Date
    Jun 2006
    Location
    My computer
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I have solved the spacing problem. I am not sure about the cross-browser thing though, I have uploaded the new version, so maybe someone can have a look and see.

  5. #5
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    If I might make a few suggestions:

    1) This is a new page, right? What are you working in tranny for? Transitional is for supporting old/outdated/half-assed coding practices, not for building new websites.

    2) never trust the default line-height. You change the font-size, set the line height.

    3) NEVER set a PX line-height on body, it prevents %/em from working properly on your content - and your content should ALWAYS be dynamic off the browser default.

    4) Use a reset to null margins and padding once, instead of dicking around saying it on every element.

    5) AVOID specifying height on your elements for no reason.

    6) AVOID styling LI to anything more than display:inline if you don't have to.

    7) Ever heard of sliding doors? You are using three images to do the job of ONE... if you add hover states and a active state you are looking at NINE images to do the job of one.

    8) Ditch the nonbeaking-space LI - those aren't actual items. You want that styling, handle it via padding, or by using a couple little tricks I'll show you in a moment.

    9) Lose the DIV that's around that UL for no good reason - particularly on a fixed width layout.

    10) there is NO reason to ever put a title attribute on an anchor that is identical to it's content.

    Taking all that into account, I suspect this is probably better for you:
    http://www.cutcodedown.com/for_other.../template.html

    as with all my examples the directory
    http://www.cutcodedown.com/for_others/cturner01/

    Is unlocked for ease of access to the bits and pieces. Valid XHMTL 1.0 strict, valid CSS 2.1, works in most every browser all the way back to IE 5.5.

    Uses just one image for ALL the states:
    http://www.cutcodedown.com/for_other...s/mainMenu.png

    That image is only 200 bytes larger than your three separate ones were, despite also containing the hover and current page states. That 200 bytes I guarantee will take less time and less bandwidth than the http response headers and server filesystem seek for two more file requests.

    As you can see I first cut down the markup to what's actually needed:
    Code:
      <ul id="mainMenu">
        <li class="current"><a href="index.htm">Home</a></li>
        <li><a href="about.htm">About</a></li>
        <li><a href="services.htm">Services</a></li>
        <li><a href="product-range.htm">Product Range</a></li>
        <li><a href="contact.htm">Contact</a></li>
        <li><a href="sitemap.htm">Sitemap</a></li>  
      </ul>
    In the CSS we have a reset, the page wrapping element is pretty much unchanged...

    #mainMenu - The overflow wraps the floats, and I used the holly hack to trip haslayout so legacy IE will wrap floats. Since #pageWrapper has no explicit height on it, that will change to height:auto automatically everywhere making it safe to send to all browsers.

    You seemed to want a top padding, so here you go, we just use background-position to slide the background down to match the top padding. The side padding pushes the LI and anchors in past the rounded edges.

    Since there is a image interaction it's 'safest' to use PX on the menu - just so long as the page content stays dynamic (%/em). I consider 12px the minimum if forced to use PX in this manner, and I'd seriously consider upping it to 14px or forcing it to text-transform:uppercase;

    #mainMenu li - LI are a pain in the ass cross-browser. Assuming you don't need dropdown menus there's little reason to do anything more with these than just set them to display:inline to get them out of the way.

    #mainMenu a - float 'em, pad 'em, style 'em. The background image we just slide to the left so that the rounded left corner isn't shown. We don't have to worry about the opposite corner since it's unlikely any of your buttons are going to be wider than the UL containing them! You'll notice I put a background-color on them so that images off the layout will still be usable.

    #mainMenu .current a - we just slide the background up 60px to reveal the bottom 30px, and again background-color for images off.

    #mainMenu a:psuedo - the hover/keyboard states also just slide the image up and set a images-off background-color.

    You'll also notice I avoid specifiying an actual height that would be obeyed - line-height plus padding lets it all add up automatically making it easier to deal with... oh, and I made them 30px instead of 29px since that's means even top/bottom padding on the anchors, and it's easier to think 30/60/90 on the background-position than it is 29/58/87... usually I work in multiples of 8, but 10's are just as good. When doing top/bottom padding and font-sizes, I try to stick to even numbers since browsers tend to round-off fractions and calculate odd-numbered line-heights differently.

    Pretty simple.

  6. #6
    SitePoint Evangelist cturner01's Avatar
    Join Date
    Jun 2006
    Location
    My computer
    Posts
    408
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks deathshadow60 for your help. I would love to learn about Strict, now you have got me started on it, I will go further.

  7. #7
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    There isn't that much that you have to know about strict, although you can find out a lot about what strict doesn't like by validating your page
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  8. #8
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    There isn't that much that you have to know about strict, although you can find out a lot about what strict doesn't like by validating your page
    For the most part correct, though really STRICT is about the separation of presentation from content and getting HTML back to what it's supposed to be for - saying what the content IS NOT how it is going to appear.

    You look at what's 'deprecated' and what's 'obsolete' in 4 Strict / X1.0 Strict, and most of it is presentation:

    TAGS you shouldn't be using:
    APPLET, BASEFONT, CENTER, DIR, FONT, FRAME, FRAMESET, IFRAME, ISINDEX, MENU, S, STRIKE and U

    Of those six are presentational - they say how something appears, APPLET is redundant to OBJECT, You want frames use a FRAMESET doctype...

    More interesting are the attributes that are invalid as this really shows the stuff that has NO BUSINESS being in the markup.

    alink, align, background, border, color, compact, face, height, language, link, name, noshade, nowrap, size, start, text, value, version, vlink and width.

    Of those, all but TWO are stuff CSS is supposed to be handling. (though I disagree on START being deprecated on OL's - to me the starting number IS content!)

    STRICT goes hand in hand with the concept of separation of presentation from content - an entirely different way of looking at building a page from the train wreck of outdated techniques developed at the peak of the browser wars. It's a simpler and cleaner way of doing things... Kind of what pisses me off about HTML5; It's UNDOING a lot of the progress that STRICT brought us... STRICT was less tags, condensing redundant tags down (the next gen was even supposed to deprecate IMG in favor of OBJECT) - it makes it simpler and better structured if you learn how to use heading tags properly. Adding all these new PRESENTATIONAL tags to the specification is NOT a good direction.

    As it sits right now most developers cannot be 'bothered' to write STRICT, much less use heading tags properly and remain blissfully unaware of tags like LEGEND, CAPTION, LABEL, FIELDSET, TH, THEAD, TBODY, etc, etc... Throwing even more tags at these same developers? NOT a good idea.

    It's like HTML5 has been hijacked by gaming munchkins and the people who never got the point of STRICT in the first place. Needless to say, I think I'm going to keep on using XHTML 1.0 Strict for a LONG time to come.

  9. #9
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,299
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Nice reply, deathshadow... although

    Quote Originally Posted by deathshadow60 View Post
    I think I'm going to keep on using XHTML 1.0 Strict for a LONG time to come.
    ...I'm surprised a purist like yourself hasn't gone off XHTML 1.0, given that it can only work in IE if served as invalid HTML.

    The only other thing I'd question is your use of CSS resets. I'm trying to wean myself off them. There are some very compelling arguments against them.

  10. #10
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Deathshadow, you know that even if you are using an XHTML doctype, you are actually using fake XHTML (I wish I had a link from Tommys site..I think his site anyway..) unlses you serve as XHTML?

    Ralphs links cover it. I personally like using HTML4.01 strict
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  11. #11
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    CHRISTMAS ON A CRACKER - NOT this bull again?

    The people who obsess on that crap miss the entire POINT of XHTML 1.0 - to be a bridge BETWEEN the two... To be entirely valid as EITHER and work as EITHER IS THE POINT!!! To be able to use XML's formatting while still working legacy - that's WHAT IT'S FOR!!!

    It's not "magically broken" in IE or anything else just because you are using a different mime-type - it works fine, it renders fine - end of story.

    NOW, if we were talking XHTML 1.1 - then FINE. You can make that arguement - But quite frankly that XML application bull isn't anything I want or need on my websites... or websites I use. Part of why if I were to send with an XML mime-type I'd probably be using TEXT/XML.

    The real reason I use it because the structural rules help me prevent making mistakes in the first damned place - because my code usually is well formed and can be run through PHP's XML parser if I want to scrape it.

    This whole 'it's not XHTML' BULL just pisses me off. The POINT is to have compatibility to BOTH, and to have better structural rules than HTML's rather half-assed approach to it. Long ago I disliked the idea of being forced to close tags like IMG - but I found that the consistent rules and the /> work great if you end up having to break up lines for being too long. (I hate wordwrap more than I hate scrolling sideways). I've come to really like being able to clearly see where I'm closing a completed element. I've come to really like being able to parse all my pages as EITHER...

    It's actually kind of funny, I was making those same arguements six to seven years ago and was being shot down for it - now that I've adopted the methodology I get the same shitstorm for it I did when I wasn't using it?!?

    Quote Originally Posted by ralph.m View Post
    The only other thing I'd question is your use of CSS resets. I'm trying to wean myself off them. There are some very compelling arguments against them.
    I wouldn't call those arguments compelling against USING a reset, so much as compelling against not using the fat bloated resets that reach the point of not even being a reset so much as a library unto itself.

    I only reset the the elements I use enough to make it worth it so I don't have to think about it. My reset is under a quarter k, and I guarantee that if I stated it on each and every element I needed to it would take a hell of a lot more bandwidth than that and be a lot harder to maintain.

    You cannot trust the defaults on some elements cross-browser; some defaults aren't what you want in the first place... a reset handles that once giving you a nice clean cross-browser baseline. The trick is to not go overboard setting manure you're either going to change anyways or aren't even going to use... like that bloated steaming pile known as Meyer's "reset reloaded".

  12. #12
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    CHRISTMAS ON A CRACKER - NOT this bull again?
    'fraid so

    It's not "magically broken" in IE or anything else just because you are using a different mime-type - it works fine, it renders fine - end of story.
    Yeah it renders just fine, but it's not right

    NOW, if we were talking XHTML 1.1 - then FINE. You can make that arguement - But quite frankly that XML application bull isn't anything I want or need on my websites... or websites I use. Part of why if I were to send with an XML mime-type I'd probably be using TEXT/XML.
    XHTML 1.1 was given up by the W3C (though if I believe so, they started up on it again). It's not even CLOSE to being done, or on RC

    The real reason I use it because the structural rules help me prevent making mistakes in the first damned place - because my code usually is well formed and can be run through PHP's XML parser if I want to scrape it.
    HTML 4.01 strict is about the best when it comes to coding good ol' HTML . You can still follow the laws of XHTML (though technically they are also part of HTML)
    This whole 'it's not XHTML' BULL just pisses me off. The POINT is to have compatibility to BOTH, and to have better structural rules than HTML's rather half-assed approach to it. Long ago I disliked the idea of being forced to close tags like IMG - but I found that the consistent rules and the /> work great if you end up having to break up lines for being too long. (I hate wordwrap more than I hate scrolling sideways). I've come to really like being able to clearly see where I'm closing a completed element. I've come to really like being able to parse all my pages as EITHER...
    But..it's not XHTML. It's fake XHTML, because to make it XHTML you have to serve it with a correct mimetype otherwise it's fake XHTML. We may have to agree to disagree because there is no way my opinion (though it's not really opinion) is changing
    It's actually kind of funny, I was making those same arguements six to seven years ago and was being shot down for it - now that I've adopted the methodology I get the same shitstorm for it I did when I wasn't using it?!?
    Shoulda stuck with those arguments

    I wouldn't call those arguments compelling against USING a reset, so much as compelling against not using the fat bloated resets that reach the point of not even being a reset so much as a library unto itself.
    I like using a reset (though I don't advocate Eric Meyers reset, or beginners using a reset at all until they understand why it's needed and for what elements)
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  13. #13
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    But..it's not XHTML. It's fake XHTML, because to make it XHTML you have to serve it with a correct mimetype otherwise it's fake XHTML.
    Ok, that right there is the part I've heard the new crowd of anti-XHTML people saying that makes little to no sense whatsoever; the mis-comprehension of the subject needed to come up with that is just mind-blowing... to the point of treading into Carlos Mencia hexadecimal gray. #DDD

    How is following the specification for XHTML making it "fake XHTML? "

    I THINK you (and all the other people who spout that nonsense) mean to say fake XML - You could probably say it's not real XML, though more accurately that is just a SUBSET of XML. It's just close enough most XML parsers won't barf on it while at the same time making it so SGML parsing won't choke either. The compatibility guidelines say don't use a bunch of XML's capabilities because you cannot rely upon them being available.

    That doesn't make it 'fake XHTML'... It makes it what XHTML 1.0 is FOR - compatibility with BOTH. If we weren't concerned about compatibility Appendix C wouldn't even exist. That's the DIFFERENCE between XHTML 1.0 and 1.1 - the former is a subset of XML abusing holes in the HTML (SGML superset) spec to allow for both parsers to handle it - the latter being pure XML with the full application features available to it, to hell with backwards compatibility.

    ... and that lack of backwards compatibility is what killed 1.1

  14. #14
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Why is it not fake XHTML? You don't serve it probably with the correct mimetype and as a result it's not really XHTML. The mime type makes all the world

    Even in W3's code examples they serve as XML (and they note they do so )

    I don't mean to say fake XML, I mean fake XHTML.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  15. #15
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    Why is it not fake XHTML?
    Because the SPECIFICATION; The document that says WHAT XHMTL 1.0 IS says it's ok to send it with the other mime-type?!?

    How hard is that to understand!?! The document DEFINING WHAT XHTML 1.0 IS SAYS IT'S OK TO USE THE OTHER DOCTYPE!!!

    How is it then NOT XHTML when it follows the rules defining what XHTML is!?!

    That's what I don't get about the arguement - if following the rules outlined in the document DEFINING it is "fake XHTML", then what the hell is "REAL" XHTML?!? What type of weirdo fantasy land logic is that?!?

  16. #16
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,721
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    You need to relax, this is a friendly debate

    You might actually want to go down to where it mentions mime types and then click the links they provide
    http://www.w3.org/TR/xhtml-media-types/

    This is a quote from the next link (the bolded part is actually bolded)
    Code:
     In summary, 'application/xhtml+xml' SHOULD be used for XHTML
    http://www.w3.org/TR/2002/NOTE-xhtml...ypes-20020801/
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  17. #17
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,299
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    http://www.w3.org/TR/2002/NOTE-xhtml...801/#text-html

    The 'text/html' media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML.

  18. #18
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Ok, what part of "Should" do you not understand - The word implies the other options are still VALID, just not "preferred" - oh noes - of course, it helps to NOT take that out of context so you can card stack what it's SAYING.

    You know card stacking right, presenting some facts while omitting the ones that contradict your viewpoint? I feel like Robert Strauss in XXX.... "You forgot the second half of the quote: and Tyrants"

    From your second link, the one you quoted:
    In summary, 'application/xhtml+xml' SHOULD be used for XHTML Family documents, and the use of 'text/html' SHOULD be limited to HTML-compatible XHTML 1.0 documents. 'application/xml' and 'text/xml' MAY also be used, but whenever appropriate, 'application/xhtml+xml' SHOULD be used rather than those generic XML media types.
    Much like the introduction from the first page you linked... you didn't even FINISH THE SENTENCE!

    In general, 'application/xhtml+xml' should be used for XHTML Family documents, and the use of 'text/html' should be limited to HTML-compatible XHTML Family documents intended for delivery to user agents that do not explicitly state in their HTTP Accept header that they accept 'application/xhtml+xml' [HTTP].
    The bold parts of both being what you omitted... It goes on, and I'm gonna highlight part of this too:

    [q] The media types 'application/xml' and 'text/xml' may also be used, but whenever appropriate, 'application/xhtml+xml' or 'text/html' should be used rather than those generic XML media types.[/quote]

    Same to you there Ralphy boy, Card stacking, quoting the part that supports your argument while leaving out the parts that don't... Always fun when you guys aren't even finishing the THOUGHT of the paragraph it's IN!

    The COMPLETE quote being:
    The 'text/html' media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML. However, as [RFC2854] says, “[XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html”.
    WHICH again is the POINT of 1.0 : "defines a profile of use of XHTML which is compatible with HTML 4.01" - so only the parts of XML that work under 4.01 should be used in 1.0!

    Both have just made it look like you are intentionally lying by omission to make your points. Good going.

    Either that or you don't bother to read past the first verb structure in a compound sentence or the complete thought of each paragraph. Comprehension - try it.

    Gah, this is treading into the same territory as the FSF's rhetoric at this point thanks to the use of the classic propaganda techniques. Card stacking, glittering generalities, bandwagon, transfer...

    Hmm... I think I have the "name calling" part covered - so slap in some testimonial and plain folks and we'd have the complete package for marketing "lies and bunk".

  19. #19
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,299
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Same to you there Ralphy boy, Card stacking
    Heh heh, I just like to stir you up! Your posts are more fun when you're angry.

  20. #20
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by ralph.m View Post
    Heh heh, I just like to stir you up! Your posts are more fun when you're angry.
    I'm mellow right now - just woke up, it's 59F out, no sign of the cursed glowing orb yet...

    Wait until noon, thanks to my Lupus the sun and I are NOT friends and I'm a miserable insufferable ass the moment the temperature breaks 65F - especially on days where my air conditioner on full blast can barely hold it on 70F - like the past four days.


    Not that we havenae already dragged this WAY OT, but at least it's a finished thread we're doing that to.

  21. #21
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,299
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Sorry, I shouldn't have been so flippant (it's a bad habit of mine). You are quite right about the danger of quoting things out of context. Although, the fact that we are disputing interpretations of what the document means suggests to me that it's badly written. (I can accept levels of meaning in, and various interpretations of, the writings of Shakespeare; but a technical document should be able to spell out facts and figures unambiguously.)

    On another tack, here's a question. Is there actually any advantage in using XHTML served as text/html over just using HTML 4? I'm basically a noob, and there may be some big thing I'm missing, but I just don't see it. The only reason I've heard that is intelligible is that XHTML is more strict about things like closing tags etc. Well, I was weaned on XHTML, so closing tags is not an issue for me. I do it anyway. OK, perhaps if I make a mistake, the validator will be more likely to pick it up if I'm using XHTML? That seems a bit of a lame reason to be using it, IMO. So maybe there's something else?

    I reckon that anyone who doesn't know about closing tags probably won't know about validators either, so it might not make any difference whether they are using an HTML or XHTML doctype.

    I can see a few disadvantages of using XHTML, such as the extra closing slashes (which look ugly to me), and, since they aren't valid HTML—and since text/html serves up HTML anyway—it is enough of a reason for me to consider XHTML served up this way as invalid... even if some spec writer decides to call this acceptable. And then there's other stuff, like all that CDATA rubbish... why would I want to bother with that?

    So, again the question: what am I missing? There must be some bigger reason for using XHTML served as text/html that I am unaware of. (This is not a cynical question, I'm genuinely asking...)

  22. #22
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    <ot>Hmm, "HTML-compatible XHTML 1" that basically means Transitional for obvious reasons Strict isn't backwards compatible. Though if anybody casts their mind back towards; http://www.w3.org/TR/xhtml-media-types/ (Working Group Note 16 January 2009) that's a damn Working Group Note and hence - non normative.

    SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
    Which is fine if you understand the "implications", which I am sure most people who have replied in this thread do anyway.

    The problem is many "other people elsewhere" don't understand that they are possibly writing well-formed markup (XHTML) put not delivering it through an XML Processor (but think they are). I believe that's the main sticking-point; when they think they are delivering XHTML as an Application of XML rather than just writing the grammar itself, which in the case of Transitional is fine anyway.</ot>

    It's the MUST and MUST NOT which you should obey to the letter the other two have slight leeway.

    Quote Originally Posted by ralph.m View Post
    So, again the question: what am I missing? There must be some bigger reason for using XHTML served as text/html that I am unaware of. (This is not a cynical question, I'm genuinely asking...)
    Backwards compatibility would be the main reason to legacy browsers or potentially future interoperability with it being well-formed but other than that it's pretty much negligible.
    Last edited by xhtmlcoder; May 29, 2010 at 06:15. Reason: Answering Question.

  23. #23
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    Although, the fact that we are disputing interpretations of what the document means suggests to me that it's badly written.
    Oh, I agree wholeheartedly with that - and that statement can be applied across the board to every "recommendation" the W3C has ever released! The vagaries of the language and worse, outright omissions in the specifications (think HTML is bad? Take a look at the CSS docs) are 99&#37; of why we have cross browser headaches in the first place. Look at the 'default' line height, which is 'suggested' to be anywhere between 120% and 130%, but is otherwise left ENTIRELY to the discretion of the UA... or how about there being ZERO information on how INPUT is even supposed to receive styling in the first place, or even IF it's supposed to accept it... Which is why Gecko, Trident, Presto and Webkit all handle the INPUT tag differently.

    As Dan used to say, when the specification is vague the browser makers all up and go their own direction, and to hell with how anyone else is handling it.

    You hit the nail on the head - it's TOO open to interpretation and it's BUILT using contradictory language! What it says in one section as should, it contradicts in the next section... and it's filled with "Would, May and Can" language instead of as xhtmlcoder steered it towards "Must and Is". A pen and paper gaming rules lawyer would have a field day.

    Quote Originally Posted by ralph.m View Post
    On another tack, here's a question. Is there actually any advantage in using XHTML served as text/html over just using HTML 4?
    Really if you are using XHTML 1.0 and following the compatibility guidelines, it makes no difference either way. You do everything appendix C suggests for compatibility, and there is ZERO difference between the two.

    You ignore the optional compatibility guidelines and the advantage lies in serving it as the application types and NOT as text/html - which is what MOST of the people arguing this are ACTUALLY talking about. That allows you to 'extend' the specification with your own rulesets and use XML modules - the full functionality of a XML application.

    But that's also a disadvantage as none of that actually WORKS in IE - which as a general rule makes the application mime-types (and by extension XHTML 1.1 which can ONLY be served as app types) undeployable "in the wild" on real-world websites.

    ... and since you can't use any of that stuff and have it work right across all browsers (and large sections of XML applications still don't work entirely right in gecko, webkit or presto) there's no legitimate reason to waste your time even WORRYING about the mime-type.

    It's the difference in intent between 1.0 and 1.1 - 1.0 is there to bridge the gap while being compatible to BOTH specifications. 1.1 is to let you build XML applications using the HTML reference set as a baseline... at which point IMHO you might as well say screw it, forget HTML and just use straight XML apps at that point since you're no longer building websites.

    Quote Originally Posted by ralph.m View Post
    The only reason I've heard that is intelligible is that XHTML is more strict about things like closing tags etc. Well, I was weaned on XHTML, so closing tags is not an issue for me. I do it anyway.
    Really that is the only reason to pick XHTML over HTML at this point - unless you also want to data scrape the page easily using something like PHP's XML Parser, which won't choke on XHTML 1.0 code that validates. (but don't trust the validator to check for well formedness! parsers that care WILL choke on poorly formed code that gets past the validator!).


    Quote Originally Posted by ralph.m View Post
    OK, perhaps if I make a mistake, the validator will be more likely to pick it up if I'm using XHTML? That seems a bit of a lame reason to be using it, IMO. So maybe there's something else?
    I wouldn't say the validator is more likely than you are to notice the mistake so much as you are - but there are exceptions. Under 'true' html a bunch of structural elements suddenly become optional - you have jokers out there omitting HTML, HEAD, BODY because according to the spec, none of them are 'necessary'. The worst part is when optional closing tags on elements like LI crop up. You don't have to close your LI, you don't have to close your P... you put a P after the LI and don't close either, you hit the UL and IE will suddenly need to have haslayout and display:inline thrown a dozen elements further down the page even though

    Explicit closings are a really good idea, required structural tags are a really good idea... Throwing the "would/may/can" attitude at them ends up with the same nonsensical mess that led to this whole "real or fake" discussion in the first place

    I reckon that anyone who doesn't know about closing tags probably won't know about validators either, so it might not make any difference whether they are using an HTML or XHTML doctype.

    Quote Originally Posted by ralph.m View Post
    I can see a few disadvantages of using XHTML, such as the extra closing slashes (which look ugly to me)
    I like 'em, but that probably goes with how I format my code. Something has more than one attribute, I like to put each attribute on it's own line for clarity... so the ending /> lets me know I'm actually closing the tag...

    For example:

    Code:
    <input
    	name="userName"
    	id="userName"
    	onfocus="showText(this.parentNode); return false;"
    	onblur="hideText(this.parentNode); return false;"
    />
    
    <a
    	href="gemmeoutahere.html"
    	title="Abort, cancel, bugger out"
    	class="buggerOut"
    >
    	Get me out of here
    	<span></span>
    </a>
    The difference between the two starts getting pretty handy visually... but I'm a total zealot when it comes to tabs and carriage returns. The run-on single line messes most people make drive me nutters since really I can't read code that way...

    Off Topic:


    Which is why I REALLY should like python a hell of a lot more than I do.


    Quote Originally Posted by ralph.m View Post
    So, again the question: what am I missing? There must be some bigger reason for using XHTML served as text/html that I am unaware of.
    Nope, the mime-type is actually a pretty small and petty thing to be arguing about in the first place... The only reason to use the 'proper' application mime-type is for functionality that breaks backwards compatibility. Serving it as either really makes no difference in rendering anywhere if you actually follow the guidelines as to what's safe to use in the first place. (again, appendix C)

    ... and really if you care about any of that stuff, you should be using 1.1, not 1.0... and then it should only be for things like in-house crapplets where you can dictate what browser the end user is using... at which point you might as well be using a real programming language, and if you need a crutch grab a copy of XULRunner, or for the wheelchair-bound any of the visual languages.

  24. #24
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,299
    Mentioned
    460 Post(s)
    Tagged
    8 Thread(s)
    Nice answer again! Thanks for taking the trouble to go to such lengths.

    Quote Originally Posted by deathshadow60 View Post
    1.1 is to let you build XML applications using the HTML reference set as a baseline... at which point IMHO you might as well say screw it, forget HTML and just use straight XML apps at that point since you're no longer building websites.
    A year or so ago, someone posted a pure XML page he was working on for some trouble shooting, and it was the first time I saw raw XML working in a browser (not IE, of course)—no HTML at all. It did make me wonder what the point of XHTML was. Although I would still call what he was building a "website". And RSS pages (which I assume are XML) run just fine as web pages.

    Off Topic:

    Ah man, I'll never get my head around this web stuff. Foolishly dipped my head into an Apache book today. I couldn't even understand the introduction! Surely there must be a straightforward way to explain these technologies!? O well, off to bed...

  25. #25
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by ralph.m View Post
    Off Topic:

    Ah man, I'll never get my head around this web stuff. Foolishly dipped my head into an Apache book today. I couldn't even understand the introduction! Surely there must be a straightforward way to explain these technologies!? O well, off to bed...
    I've been working with computers for close to three decades, and I'm STILL learning. There's an old saying, the day you think there's nothing new to learn is the day the rest of the world leaves you behind.

    Keep at it, it all makes sense eventually... or at least, you'll understand it even when it doesn't make sense.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •