Personally, I've taken to just doing browser detection once and well at the start of the session and then delivering dynamically generated CSS code based on what I know of the browser instead of trying to use those types of hacks.
IE Conditional comments (<!--[if IE]> blah blah <![endif]--> ) are the way to communicate to IE only browsers.
Using hacks Karl are perhaps a short and sweet response to an IE quirk but the problem is they can be lost in the miasma of CSS code you have. Even if you decide to put IE hacks in a specific commented part of your global.css you're still relying on someone else finding it there, or yourself remembering it's down there, and then it will have lost relevance to the other statements of CSS it may be related to.
Much better is to have a dedicated stylesheet for IE only browsers (or different versions if that's what is required) and use proper selection to override existing statements in your general stylesheets.
You'll certainly never forget where you put those styles and any new developers that might stumble upon your code will instantly see that there are IE specific styles going on there.
It's now pretty much possible to develop sites without using any hacks at all if you're clever with your CSS and use conditional comments.
Esskey, why would you need to use dynamically generated CSS? sounds a bit nasty
Nice! I forget sometimes, that there is a better way. One advantage to the hack is: with a hack, you can keep the hack in same proximity of the original style. I know you are saying that isn't an advantage, but... I would need to do something like this, something which prompts me that "woops, a hack was required for IE!", so example:
Just because IE conditional comments are proprietary does not mean they are a hack. They are perfectly standard compliant and a great tool to use when you need to differentiate between browsers on the HTML or inclusion level.
Indeed, just because they're a hack means they're a hack. They're proprietary, and also (or by extension) not standards compliant. Except for a few exotic layout approaches, you can almost always get by with mere redundant (standard) CSS - the rest of the time there are plenty of standards compliant hacks.
That's a non sequitur. Something not being standardised does not mean it isn't standards compliant. Conditional comments in IE are just HTML comments to other browsers. Anything in them is part of a comment and can safely be ignored. It's only IE in particular that treat them differently, treat them in a proprietary manner.
Look, CSS allows dashes to lead property names but promises to not use them for any standards property and implementations that do not recognise them just ignore them. Does that mean properties like -moz-binding or -o-replace aren't proprietary? No, it doesn't. But it means that they are not hacks either. (Hacks in this sense defined as abusing or misusing syntax or semantics for purposes that are contrary to the syntax or semantics as specified.)
HTML comments are the same. They are specified to be ignored. That means that they are the perfect place to insert special proprietary handling for subsets of that syntax in your particular implementation without actually breaking any rule of the HTML language. As such, proprietary but standards compliant.
This is a common thing to do when you are actually trying to avoid breaking a standard - use one of the specified ways of getting some code ignored by a standard to get your proprietary functionality into it without breaking if that code is given to somebody that only supports the standard. Often specs are actually written with this in consideration and have appropriate holes for custom functionality to be patched in. In XML, for instance, we have PIs on the syntax level and namespaces on the semantics level. CSS is the prime example here with so many holes specifically there for extensions that you can extend it pretty much to do whatever you want. ECMAScript, XML, HTML, HTTP and many other web or non-web technologies have similar places where you can insert proprietary functionality in non-breaking ways.
quote:Something not being standardised does not mean it isn't standards compliant.
It increases the chances it isn't.
quote:Conditional comments in IE are just HTML comments to other browsers.
Unfortunately HTML conformance is not based on how things work in "other browsers", and the spec doesn't say "Information that appears between comments has no special meaning except in Internet Explorer", it just says "Information that appears between comments has no special meaning".
quote:CSS allows dashes to lead property names but promises to not use them for any standards property and implementations that do not recognise them just ignore them. Does that mean properties like -moz-binding or -o-replace aren't proprietary? No, it doesn't. But it means that they are not hacks either. (Hacks in this sense defined as abusing or misusing syntax or semantics for purposes that are contrary to the syntax or semantics as specified.)
While the CSS spec does explain the recommended naming conventions for vendor-specific (proprietary) extensions, it does not say these are conformant, but goes so far as to say "An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS." and "Authors should avoid vendor-specific extensions".
A comparison to the HTML comment rules is therefore not apt because the CSS spec doesn't say vendor-specific extensions are conformant (except as a convention for use in a non-conformant way), and because the HTML language explicitly states "Information that appears between comments has no special meaning".
Resio: The document is perfectly standards compliant, though. The ie handling of those comments as conditionally non-ignored content does not change whether the document is conformant or not. And whether you use it or not does not affect whether the user agent is conformant.
But yeah, on another plane you're right. The CSS model doesn't make the proprietary extensions conformant. In that way, it's a less permissive spec than a few others I could mention. But let's look at ECMAScript then. All browsers allow function definitions in statements. The spec does not permit them there (and for a reason - even though all browsers support them there's no cross browser compatibility here because they support them in different ways). But the spec makes it conformant for implementations to extend the syntax, so one engine supporting this does not makes that engine non-conformant. It's just an example though - not a justification. The IE treatment of conditional comments is a break of the rule that the content of a comment should be ignored.
That does not make using conditional comments a hack for the document author any more than using lack of support for CSS properties, or use of broken CSS parsing, or use of custom HTTP headers etc. You are still as a user just generating valid HTML/ CSS / HTTP. It's the user agent that is non-conformant and not your document/style sheet/resource.
quote:The document is perfectly standards compliant, though.
No, it isn't.
quote:The ie handling of those comments as conditionally non-ignored content does not change whether the document is conformant or not.
Yes, it does.
quote:And whether you use it or not does not affect whether the user agent is conformant.
The issue is not whether a user agent is conformant, but whether the markup is, and it plainly would not be.
If it were about whether the UA were conformant, we would have no need for validators, and everything would automatically be non-conformant, because no UA gets it that right so far.
quote:That does not make using conditional comments a hack for the document author any more than using lack of support for CSS properties, or use of broken CSS parsing, or use of custom HTTP headers etc.
This could be considered true.
quote:You are still as a user just generating valid HTML/ CSS / HTTP.
This could not be.
quote:It's the user agent that is non-conformant and not your document/style sheet/resource.
It'd be both, but you have control over one ? the website code ? whether that is conformant or not is entirely up to you.
In which way does inserting some comments into the document make the document non-conforming?
This is perfectly fine HTML5:
code:
<!DOCTYPE html>
<html>
<head>
<!--[if IE]>
<p>Obviously if this wasn't a comment this document would be non-conformant,
but since this is a comment it of course remains conformant.</p>
<![endif]-->
<title></title>
</head>
<body>
<p></p>
</body>
</html>
You can do the same thing to earlier HTML versions, of course.
How ie treats that comment does not in any way change whether the document is conformant. Ie thinks it sees element content where only a comment body can be found. That does not change the fact that in the document it's only a comment and not element content.
HTML 5 is a different animal (some would say beast ) ? what you have there does look to be conformant HTML 5. It is not conformant HTML 4 (obviously excluding the doctype declaration). Regardless of whether you're aiming for HTML 4 or HTML 5, however, it remains proprietary code, the use of which has always been worse than having merely non-conformant code.
FYI my site includes a conditionnal comment ( to fix PNG transparency ) and is valid XHTML 1.0 strict ( at the exception of a 2 pages which have encoding issues, but that is irrelevant to the point about conditionnal comment ).
Listen, I'm not saying that CC are a silver bullet. I'm just saying that they have their use, and have a little cost. That being said, plain, valid, CSS is usually enough to make IE behave with the box model.
Since you removed " with the box model " from the second quote, I wonder how you suggest to make IE respect PNG transparency for instance.
Do you say my site isn't valid XHTML 1.0 strict because of the conditional comment or there is something else ?
[edit] It would make a great entry in the FAQ if you could elaborate a bit on your suggestions about avoiding CSS hacks, conditional comments and what not. [/edit]
Since you removed " with the box model " from the second quote, I wonder how you suggest to make IE respect PNG transparency for instance.
IE 6? I probably wouldn't bother.
#coverShadow doesn't really need to exist; the images behind it must be made to spec anyways, you could just flatten the shadow on top of them and use one image... and having the images semi-readily accessible without the shadow effect inseparable is not particularly useful (though it could be in many other situations, like a gallery, etc., obviously).
The shadows on the nav menus is a nice effect, but I doubt many IE 6 users would miss it, and you could probably get away with a dithering of gray and transparent pixels without many people noticing.
You don't need to have that rule with the behavior "property" inside an IE conditional comment regardless, though, of course - your CSS would show as not entirely valid according to the W3C CSS validator, but, well, it isn't valid (whether the validator sees it or not), so that's fitting. I've never really heard of anyone complaining about a single CSS validator error over things like this, anyways. Usually people are eager to add as much proprietary nonsense as possible. You can always just put a comment beside it like "/* IE */" and then nobody can say 'your code isn't even valid, you're so ignorant', because it'll be undeniable you did it on purpose.
Besides, if the "gods of CSS" Zeldman and WaSP don't use valid code (and don't even bother to hide it from the validators as you have), why should anyone else, right?
quote:poi said:
Do you say my site isn't valid XHTML 1.0 strict because of the conditional comment or there is something else ?
Just that.
quote:poi said:
It would make a great entry in the FAQ if you could elaborate a bit on your suggestions about avoiding CSS hacks, conditional comments and what not.
Resio: No, it's not non-conformant in other HTML versions either. The syntax rules governing the comments are different, but this is valid HTML4 Strict, and with a change of Content-Type header and doctype, plus the addition of the appropriate namespace declaration, valid XHTML1 Strict.
code:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<!--[if IE]>
<p>Obviously if this wasn't a comment this document would be non-conformant,
but since this is a comment it of course remains conformant.</p>
<![endif]-->
<title></title>
</head>
<body>
<p></p>
</body>
</html>
The conditional comment does not change the validity in either XML or SGML based HTML versions. Though of course, there's never been a widespread SGML based user agent, so that's just a shim anyway. In fact the standard up til now was the Netscape comment parsing because that's what Microsoft reverse engineered and everybody then later on reverse engineered the Microsoft implementation. A clear case where the de jure standard contradicts the de facto standard to the point that only overlap to be seen is the bare minimum of a much richer syntax.
Using an IE conditional comment is no different from using embed, bgsound, or layer. That alone makes it non-conformant, and its clear abuse of the aforementioned definition of a comment makes it doubly so.
Tyberius Prime
Maniac (V) Mad Scientist with Finglongers
From: Germany Insane since: Sep 2001
posted 10-22-2008 17:28
I believe you're misreading the spec to drive your point, reisio.
It says 'no special meaning' (within the scope of this specification, or that an implementor would have to care about in order to support the specification.).
It does not say 'no meaning'.
Having IE only comments is just as valid markup as keeping 'magic markers' for some kind of editor (even if that editor's called "Bob" and the comment reads "edit the line below") in comments.
Is it valid markup? Yes.
Is it pretty? No.
Should it be avoided? Yes.
At all costs? No.
But if the 'appropriate answer' is to have two websites instead and rely on server side detection to deliver the right one - well, that's bound
to be more fragile than piggybacking on comments. And it disempowers the user agent.
As for embed, bgsound or layer: None of these are syntactically valid tags. <!--[if IE]> ... is a syntactically completly valid content (if semantically dubious).
I believe you're misreading the spec to drive your point, reisio.
Why would I limit it to HTML 4?
quote:Tyberius Prime said:
It says 'no special meaning' (within the scope of this specification, or that an implementor would have to care about in order to support the specification.).
Yup
quote:Tyberius Prime said:
It does not say 'no meaning'.
Indeed
quote:Tyberius Prime said:
Having IE only comments is just as valid markup as keeping 'magic markers' for some kind of editor (even if that editor's called "Bob" and the comment reads "edit the line below") in comments.
Well, it's potentially not any more invalid.
quote:Tyberius Prime said:
Is it valid markup? Yes.
Clearly not.
quote:Tyberius Prime said:
Is it pretty? No.
Indeed
quote:Tyberius Prime said:
Should it be avoided? Yes.
Indeed
quote:Tyberius Prime said:
At all costs? No.
You haven't defined what possible costs there could be but it's irrelevant, because in addition to being proprietary/non-standard, they aren't even ever necessary.
quote:Tyberius Prime said:
But if the 'appropriate answer' is to have two websites instead and rely on server side detection to deliver the right one - well, that's bound to be more fragile than piggybacking on comments. And it disempowers the user agent.
That's never necessary, either.
quote:Tyberius Prime said:
As for embed, bgsound or layer: None of these are syntactically valid tags. <!--[if IE]> ... is a syntactically completly valid content (if semantically dubious).
Nope. Just as those are invalid because the spec does not include them, so too are IE conditional comments, which are not only not included, but expressly forbidden.
Yes it is. Can you please stop repeating this until you get a clue about what validation is? (Hint: it has nothing to do with the prose, only the machine checkable part of the specification).
quote:[...] so too are IE conditional comments, which are not only not included, but expressly forbidden.
Either you have no clue about XML/SGML and what a comment is, or you're just daydreaming. Please explain where you think the spec expressively forbids CCs. And if it did (which it doesn't), explain what that would have anything to do with validitity.
(And note that I'm talking about the type of conditional comments on poi's site. There are others that are syntactically wrong).
it has nothing to do with the prose, only the machine checkable part of the specification
To me this only supports my point - the W3C validator saying you're using valid code doesn't mean your code is valid, only that the code it is aware of is valid. Consider a more extreme case of hiding non-standard code usage in JavaScript.
quote:HZR said:
about XML/SGML and what a comment is
If HTML were SGML, we'd call it SGML. HTML has additional rules on top of SGML.
quote:HZR said:
Please explain where you think the spec expressively forbids CCs.
Already have at least twice.
quote:HZR said:
explain what that would have anything to do with validitity
Explain how usage of something forbidden by a spec has to do with conformance with the spec?
quote:HZR said:
(And note that I'm talking about the type of conditional comments on poi's site. There are others that are syntactically wrong).
Resio: Your quote of the HTML spec does in fact not argue for your side. The spec defines what the comment does. If the spec says that the comment has no meaning, then that imposes on the document that contains it that the comment has no meaning. That one user agent in particular ascribes a meaning to that comment does not change the fact that it per spec does not have a meaning. You can insert pretty much ANYTHING (limited by the syntax rules of SGML/HTML/XML comments depending on which HTML version you're talking about of course) into a comment, with any intent, and you do not change that. A conditional comment DOES NOT have any meaning in the context of the HTML document. It's only ie that interprets that, but a user agent's implementation be it wrong or right changes nothing in regard to the relationship between the document and the spec.
quote:HZR said:
it has nothing to do with the prose, only the machine checkable part of the specification
To me this only supports my point - the W3C validator saying you're using valid code doesn't mean your code is valid, only that the code it is aware of is valid. Consider a more extreme case of hiding non-standard code usage in JavaScript.
It certainly does not support your point, because you're confused about what validation means. A validator checks a document instance against a set of formal rules expressed in the machine-processable part of the DTD. If the instance conforms to those rules, it's valid.
The spec could say that the document must use "Hello World" as the title, but there is no way for a DTD-based validator to check this. If you had another title the document would be non-conformant, but still valid.
quote:
quote:HZR said:
about XML/SGML and what a comment is
If HTML were SGML, we'd call it SGML. HTML has additional rules on top of SGML.
It actually has, and this effectively disqualifies HTML from being an SGML application. That's of couse pre-HTML 5 where they stopped pretending.
quote:
quote:HZR said:
explain what that would have anything to do with validitity
Explain how usage of something forbidden by a spec has to do with conformance with the spec?
Conformance and validity are not the same thing.
reisio, read what liorean said about how a UA interpreting something one way or another does not make it non-conformant.
Do you believe that the CC syntax was valid before IE started to assign special meaning to it, and that is suddenly stopped being valid when they did?
Another example: browsers sniff the doctype declaration. Does that mean that a doctype is invalid as it's not used the way the spec describes?
Conformance means that the document follows the criteria in the specification. This involves stuff like validity and requirements for alternative text for images.
Validation means, as I wrote before:
quote:[...] check[ing] a document instance against a set of formal rules expressed in the machine-processable part of the DTD.
A validator cannot check for instance that an alternative text for an image is correct according to the spec. This has to be done by a human. If the text is bogus, the document is non-conforming, but still valid.
Valid documents are machine readable, and thus open for all kinds of mashup.
Conformance also touches things like accessiblity and semantic which are a out of reach of an automated test and a sure way to endless debates : Anyone up to jump in the discussion about the ALT attribute of Rorschach inkblots images ?
Every language has three basic building blocks, grammar, vocabulary and semantics. They together build a context. The semantics in that context can either make sense or be nonsensical. Sometimes it's hard to tell, sometimes it's crystal clear either way.
Let's take something from my quotes file: "Hold the newsmedia's nose squarely, waiter, or friendly milk will countermand my trousers." Every part of it can be found in the English vocabulary. The sentence conforms to the somewhat muddy grammar of modern English. Every word has some associated semantics. Taken in context though, it's absolute nonsense.
HTML validation is all about grammar and vocabulary. HTML conformance is about the sentence making sense, however. But even if each sentence makes sense, a paragraph of them can still be nonsensical, and even if a paragraph makes sense, the whole text can still be nonsense.
Bonus points for anyone recognising from where I got that sentence.
quote:Given this response, I have no idea what your point is.
The point is that you're wrong in thinking that something becomes invalid (or even non-conforming) just because some UA uses it in a way that it wasn't meant to. This has been pointed out a number of times, but I'm not even sure you're reading what we're writing. You're at least not answering my questions, so I ask again:
Do you believe that the CC syntax was valid before IE started to assign special meaning to it, and that is suddenly stopped being valid when they did?
Browsers sniff the doctype declaration. Does that mean that a doctype is invalid as it's not used the way the spec describes?
quote:
Do you believe that the CC syntax was valid before IE started to assign special meaning to it, and that is suddenly stopped being valid when they did?
Just for the record....this is a *completely" irrelevant question.
Nobody used the CC syntax before it was "meaningful" to IE. And nobody would.
it is used absolutely soley for the purpose of it's non-conformant properties. It is absurd to speak of it outside of that context.
No it's not an irrelevant question - it's an entirely hypothetical but certainly relevant question. Whether something is used or not does not change whether its use would be valid or not. Our argument, or at least mine, is that if there had been a document that used that syntax nothing would have changed with regard to either the document, the HTML spec or the relationship between them when a user agent suddenly started interpreting it in a special way. And nothing would change if tomorrow a Microsoft mandatory update to IE suddenly disabled the support for conditional comments on all versions. The relationship between the spec and a document does not change depending on external factors such as user agents.
Look, comments are never inserted because they have no meaning. They are inserted in order to tell somebody something about the source code. It can be explaining the document structure for developers that want to change it, comments about why things are done a certain way, markers for templating systems or CMSes, easter eggs for users that look at the source code or any number of things. But one thing a comment always does is carry some meaning. It just doesn't carry a meaning in the HTML document itself. What the HTML spec tells us is just this - that comments do not have anything to do with the HTML document. This particular comment has a meaning regarding the source code - more specifically, it tells ie that the code contained therein is to be treated as if it was not contained in a comment. Which means that ie does treat the document in a non-conformant way. But ie treating that comment in a non-conformant way does not change the fact that to a conformant user agent it's just a comment.
The point is that you're wrong in thinking that something becomes invalid (or even non-conforming) just because some UA uses it in a way that it wasn't meant to.
The HTML spec is also for authors, and when a person uses an IE conditional comment, that is abuse of an HTML comment.
quote:HZR said:
Browsers sniff the doctype declaration. Does that mean that a doctype is invalid as it's not used the way the spec describes?
No of course not, but if you used a doctype declaration in a way that is at odds with how the spec says it is to be used, it would.
quote:DL-44 said:
quote:HZR said:
Do you believe that the CC syntax was valid before IE started to assign special meaning to it, and that is suddenly stopped being valid when they did?
Just for the record....this is a *completely" irrelevant question.
Nobody used the CC syntax before it was "meaningful" to IE. And nobody would.
it is used absolutely soley for the purpose of it's non-conformant properties. It is absurd to speak of it outside of that context.
I'm obviously with DL here:
quote:reisio said:
Just as those are invalid because the spec does not include them, so too are IE conditional comments, which are not only not included, but expressly forbidden.
To be completely technical - no, had someone used certain IE conditional comments before they existed, without knowing what they were, for example thinking they were gibberish, that would not be non-conformant...
...and that is exactly the point. The conscious, willful use of proprietary code by an author makes it non-conformant. The awareness that this information has special meaning makes its inclusion non-conformant.
quote:liorean said:
The relationship between the spec and a document does not change depending on external factors such as user agents.
Indeed, the document coder has authored non-conformant code.
No, the document coder has not authored any non-conformant code. The HTML spec doesn't say that authors shouldn't put content in there that does have some meaning. No, it rather dictates that information that occurs between comments has no meaning - meaning that any content the coder puts inside the comment is void of meaning. This means that the content of the comment, e.g:
code:
[if IE]>
<p>Obviously if this wasn't a comment this document would be non-conformant,
but since this is a comment it of course remains conformant.</p>
<![endif]
... does not have a meaning in HTML. You could change that content to any other content (except again for caveats in the comment syntax of the chosen HTML version) and you would not change the meaning of the comment, because neither this particular comment nor any other comment has any meaning in HTML. That it has a meaing in ie tag-soup does not change that it has no meaning in HTML.
And if it has no meaning in HTML then nothing you can put in there, short of syntax errors or early closure, can change whether the document is conformant or not.
Sorry, but that comment body having a certain effect in ie does not mean anything with regards to HTML. It does not mean the document is invalid (it obviously isn't if you check it in a validator), it does not mean the document is non-conformant (because it does not contradict any statement in the HTML, XHTML, XML or SGML specs), it only means that the document source code has a bit of content that carries no meaning in the document.
posted 09-28-2008 10:08
) ? what you have there does look to be conformant HTML 5. It is not conformant HTML 4 (obviously excluding the doctype declaration). Regardless of whether you're aiming for HTML 4 or HTML 5, however, it remains proprietary code, the use of which has always been worse than having merely non-conformant code.
