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.
quote:DL-44 said:
Just for the record....this is a *completely" irrelevant question.
No, it's not. It's hypothetical. So please answer it instead.
quote:reisio said:
quote: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.
That was my whole point. Doctype sniffing is not in the spec. It doesn't talk about "standards mode" or "quirks mode". Browsers started using the doctype for something that it wasn't meant for according to the spec*.
Now, if someone inserts a doctype declaration in a document for the sole purpose of triggering standards mode (which, in your own words, "is at odds with how the spec says it is to be used"), does that mean that the document is invalid? No, of course not. Browser behavior does not decide what's valid/non-conformant or not.
And I completely agree with liorean, who sums it up great, especially in the last post.
______
*) And by the way, from an SGML point of view, the description of doctypes in HTML 4 is completely non-sensical.
quote:No, it's not. It's hypothetical. So please answer it instead.
Yes, it is. So there's no point answering it. Chasing that kind of hypothetical would seem to be why you guys are having such a hard time grasping this...
It's hypothetical because it's a situation which we never entered into. However, it is relevant because there are logical conclusions to draw from what the answer is that are neither hypothetical nor irrelevant. So there is a point to answering it.
To rephrase, it's basically asking you whether you think that something that has nothing to do with either the document or the spec can have an effect on the relationship between the document and the spec.
Your argument makes no sense. According to you, the contents of comments shouldn't be ignored no matter what it is... thereby making it not a comment at all. Or perhaps the contents of a comment should be determined to have special meaning or not based on whether the author felt it should be special or not? You can't have it both ways.
quote:HZR said:
quote:DL-44 said:
Just for the record....this is a *completely" irrelevant question.
No, it's not. It's hypothetical. So please answer it instead.
Didn't you ask me? I answered.
quote:HZR said:
Browser behavior does not decide what's valid/non-conformant or not.
Browsers do not insert IE conditional comments, authors do.
quote:Your argument makes no sense. According to you, the contents of comments shouldn't be ignored no matter what it is... thereby making it not a comment at all.
I cannot possibly see how you interpreted it that way. What he said was rather the opposite. Quoting liorean:
quote:[The HTML spec] dictates that information that occurs between comments has no meaning - meaning that any content the coder puts inside the comment is void of meaning.
Of course the contents of a comment should be ignored by parsers. I don't think there's an argument over that. The fact that one browser happens to not do that, is however nothing that makes the syntax invalid.
quote:Didn't you ask me?
I did, but I thought that DL-44 could explain his position when it was pointed out to him explicitly that the question was hypothetical.
quote:Browsers do not insert IE conditional comments, authors do.
Likewise, authors do not decide what's valid/non-conformant or not. The spec does that.
quote:I did, but I thought that DL-44 could explain his position when it was pointed out to him explicitly that the question was hypothetical.
It was obviously a hypothetical question.
I am very confused on how something being hypothetical stops it from being irrelevant?
For instance, let me ask you: hypothetically, if pigs were purple, would that make you like tomatoes less?
Completely Hypothetical. Still completely irrelevant
But any way, if you really need an answer -
The CC syntax did not exist prior to the user agent being able to make use of it.
Whatever logical conclusions you want to pull out of the hypothetical do not apply to the reality.
Resio: That is exactly the opposite of my point, and I don't see how you can possibly read that out of my argument. I've several times now made the point that comment content is ignored in HTML, thus the author's intent and purpose for placing it there is totally irrelevant for whether the document is conformant or not. ANY possible content that can be placed inside a comment according to the comment syntax carries no specific meaning in HTML. That includes the IE conditional comment syntax.
Likewise, the fact that there is a user agent that is non-conformant and treats a document different from how the spec tells user agents to treat it does not change whether the document itself is conformant or not.
DL-44: No, it's not totally irrelevant, since as I said the answer to that question has logical conclusions that are entirely non-hypothetical. It's a question of establishing which factors are important - according to you - as to whether a document is conformant to the spec or not.
If I constructed a Mozilla extension that suddenly gave certain comments that already exist on the web a defined meaning in Firefox, and spread this extension around, then we would have another user agent with such special comment syntax as the ie conditional comments. Would documents that contained this comment syntax before that point in time suddenly become non-conformant because of this? Would future documents that contain this comment syntax be non-conformant where they previously would not have been?
Oh, but that is incorrect. The logical conclusions DO apply to reality. Not to the reality of where we stand today, but the reality of what policies we use today. You see, the answer would tell us that you're applying a different rationale than us to the concept of spec conformity. Which means that we can remove assumptions or change assumptions to be in line with your answer, and see where that leads us. And if the result leads us to absurd situations (as it will on this specific issue) then we can do a reductio ad absurdum argument against your basic premise.
If you talk in circles lone enough, you can think it all makes sense I suppose
I think it comes down to this: if you have to spend that much time correlating hypotheticals, and you need to spend this much verbiage on your justifications...it should really tell you something about your basic argument.
Oh, but I'm just trying to disprove one specific point: That conditional comments do not make an HTML document non-conformant. I've laid down at least one very straight forward argument that you apparently ignore, without explaining exactly why. Others have done the same.
So we try to explain why your standpoint is incorrect through leading it to it's logical conclusions, but you dismiss a question that would either prove an answer that is inconsistent with your earlier standpoint (if the answer is no) or that would lead into a downwards spiral resulting in eventually no content being a possible conformant comment (if the answer is yes).
But, since you refuse to answer HZR's question, please answer one of my two later questions, neither of which talks specifically about the ie conditional comments syntax, but both of which will lead to the same results either way.
quote:if you have to spend that much time correlating hypotheticals [...]
We haven't. The question has been asked a number of times since you refuse to answer it, calling it irrelevant even when it has been explained to you why it's not. Now, please answer lioreans's question about the Firefox extension (which is exactly the point I tried to make).
quote:it should really tell you something about your basic argument.
Well, we have actually put forward arguments. You haven't. You have, in fact, not even bothered to explain why you think we're wrong when we say that something external to the specification cannot have any influence whatsoever on the spec in question.
You both seem to think I've said a great many things I haven't. I haven't said anything about most of your points, and I won't.
I simply pointed out a logical flaw, and have explained myself quite fully.
I am also confused as to why you both insist that I have refused to answer your question when I did in fact answer it (just not with the yes/no answer you wanted).
~shrug~
You have both explained what meaning you *think* will come from the answer, to which I have simply and directly responded. Explaining the same thing 12 more times with rude tones isn't going to change the answer any
quote:I am also confused as to why you both insist that I have refused to answer your question when I did in fact answer it (just not with the yes/no answer you wanted).
Your so called answer was this:
quote:The CC syntax did not exist prior to the user agent being able to make use of it.
which suggests that someone couldn't have written
code:
<!--[if IE]> ... <![endif]-->
before IE started assigning meaning to it. Which is of course wrong.
You're right - we've been considering you as taking Resio's position when in fact you haven't stated much either way. However, let's see what you wrote that sparked this derailment:
quote: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.
You're making plenty of assumptions here that go counter to our earlier argument:
- First of all, you're talking about "it's non-conformat properties", which means that you think it's got some properties that are not conformant. You haven't taken any time to explain which these properties are of what makes them non-conformant, while our argument earlier was specifically that they are not non-conformant.
- Second, you are talking about this syntax specifically, while we're talking rather about conformity. If you take the comment syntax of HTML and list all possible contents, you would find you could split that up into two lists (both infinite in size), one of conformant comments and one of non-conformant ones. Our argument is that the lists are the same before and after ie implemented that syntax. If the lists are not the same, that means that a factor outside of the spec itself can affect whether the same content is compliant or not. That means that our question is not irrelevant on the policy level - it determines whether it's possible to make content that was previously conformant somehow be non-conformant.
- Third, it is not an answer to the question, it is an explanation of your standpoint that it's not a relevant question.
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.
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.
