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?
Real navigation bar without the text
Thanks in advance.
Nice answer again! Thanks for taking the trouble to go to such lengths.
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.
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…
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#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.
<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.
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.
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% 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.
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.
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!).
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.
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:
<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…
Which is why I REALLY should like python a hell of a lot more than I do.
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.
[ot]
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.[/ot]
Not that we havenae already dragged this WAY OT, but at least it’s a finished thread we’re doing that to. 
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.
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…)
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)
In summary, 'application/xhtml+xml' [B]SHOULD[/B] be used for XHTML
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”.
Heh heh, I just like to stir you up! Your posts are more fun when you’re angry.
'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)
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?!?
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?!?
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”.
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.
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
Nice reply, deathshadow… although
…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 [URL=“http://csscreator.com/node/34411”]arguments against them.
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
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
Thanks deathshadow60 for your help. I would love to learn about Strict, now you have got me started on it, I will go further.