5 Questions for Conditional Comments Fans

Jens Meiert, December 13, 2007.

This entry is filed under Web Development.

Thanks to A List Apart and Vitamin, the Conditional Comments discussion became quite popular again, and recent reactions let me ask a few questions to CC proponents:

How do you sort your socks; do you put them in different drawers, or do you fold them and put them in one place? Why?
What is your opinion on markup comments, how should they be treated by a parser?
What is your vision for website maintenance? Is the number of files to be maintained relevant to you?
Do you consider probability estimation to be important in professional decisions?
What is the benefit of standardization for you?

While I certainly intend to provoke a little bit, these questions are not meant to be “offensive” in any way, and evil to him who evil thinks. I’m looking forward to your thoughts, even though I currently abstain from answering these questions.

Expect additional posts clarifying my position concerning Conditional Comments and website maintenance by yet other means, also covering alternatives (that I basically see in using alternative solutions for layout problems, using “valid” workarounds, and supporting W3C standardization).

Enjoy some popular posts, probably including contemporaries:

Comments

On December 13, 17:23 CET, ’Mas said:

1) folded in one place. I dress in the dark so as not to wake my wife.

2) markup comments should no be needed if the markup if properly coded. parser should ignore them.

3) form-based control of content, along the lines of a cms. the more to be maintained, increases the need for the form-based control.

4) important but not all-important.

5) forced me to look at content in a different context from the look of the site, which leads to better content. the rest is window dressing, albeit important window dressing, but window dressing nonetheless.
On December 13, 20:37 CET, Art said:

1. I keep all my socks in the same drawer, except for my dress socks which I only use rarely on special occasions. Those I keep in a drawer with all my other dress clothes.

I never have to rummage past my dress socks to get to my daily wear socks and there’s more room in my sock drawer.
On December 13, 22:02 CET, Jens Nedal said:

1. My socks are all in one drawer, in one place, each pair labeled for its use.

2. Markup comments should be parsed by browsers just like (most) hacks, meaning they should be ignored. Browser vendors beg to differ.

3. The number of files is relevant, just like naming.

One file is just as easy to maintain as a few appropiately named files. This argument is trivial to me. I have worked both ways.

Number of file requests is certainly a drawback here, granted. Different topic though.

5. That finally one day there will be no need to test against x browsers or discuss this topic

The benefit of standardization is that all can choose to speak and understand the same language without their personal dialects attached.
On December 15, 8:48 CET, Eric Eggert said:

1. I put them in one place. Because I’m lazy, that is. I’d be faster with finding appropriate socks if they were ordered. Oh, and my drawer is compatible to all socks, black and grey work fine, white has worked, too, if I remember correctly.

2. It’s quite common that comments are parsed in languages like c++ and others. They are used for directions at the parser. There is no problem with that if it’s in a documented manner. It’s not the most beautiful thing, but I think it’s appropriate from time to time, especially if the parser differs to other parsers as IE6 does.

3. That’s irrelevant as you’d pack those files together in one and send it gzipped to browsers. Having one file especially for one browser is okay, if a) it‘s well documented and b) only really needed attributes are used there. So if you’d have to correct IE6s box modell you’ll likely have width in there but not background-color. It’s more a matter of taste, if you like to use one ore more css files.

5. Standardization means interoperability for me. And getting a clean css file without hacks is one aim, which I want. Hacks and workarounds are as non-standard as having CCs. But that problem will be enforced with standards in progress as css3 and html5. Speaking of standardization, every site who uses them is non-standard to current standards and will be non-standard until 2010 or longer. Under those circumstances, standards are probably less important than future maybe-standards. We have to see how IE8 changes it’s engine. Probably that leads to a mor standardized web.
On December 15, 11:11 CET, Jens Meiert said:

Thank you very much, great feedback!

That’s irrelevant as you’d pack those files together in one

Eric, but you nonetheless have got 2+ style sheets on file level, right? I rather mean the file structure being possibly relevant for maintenance.
On December 15, 16:35 CET, Jamie Knight said:

1: I wear a black sock and a white sock each day and they live in a draw.

2: they should be ignored. Useful during development, but should not be on the final site.

3: CMS using MVC for easy extendability.

4: Sometimes.

5: The power of unified formats. for example, microformats and operator

I have been building sites for 4 years, and i am yet to need conditional comments.

^licks^

Jamie & Lion
On December 16, 5:09 CET, Sean said:

I am not going to answer any of these questions, because the first is obviously bait. Instead, I am going to point out something in terms of using CCs over putting hacks in amongst your sheets.

Common practice nowadays is to keep multiple sheets for better organization. Bundle your reset stuff, your type stuff, your layout stuff, and your misc or “on the fly stuff.” I don’t believe I have read an article by anyone that I respect that hasn’t promoted this particular method.

So if you are bundling your styles anyway, why not bundle your hacks into a separate file as well. You know where they are if you need to update them.

And on the topic of CCs not being standard, the only browser that actively uses them isn’t exactly standard compliant anyway, thus the need for CCs and hacks in the first place. Browsers that are more in line with standards treat them exactly as they are formatted, as comments.

So the only time you are not following standards in terms of CCs is with a browser that you are not going to be following standards with anyway. And more importantly, you are keeping your non-standard hacks out of the view of compliant browsers.

Long story short, CCs are at worst a non-issue, and at best a CSS-expert recommended way to ensure organization and standard compliance in browsers that actually care about standards.
On December 16, 12:04 CET, Jens Meiert said:

Jamie, thank you!

Sean, thank you as well! I may clarify that I especially write about CC since it is such a controversial topic and apparently a very sweet fruit … but probably too sweet to try to avoid CC and “hacks” altogether. And while I absolutely agree that complex projects can benefit from separate style sheets (I can point you to quite a few sites I developed that do exactly that, but without CC), this must not mean that it is commendable to do so from scratch – to end up with something like Choke, for instance.

Anyway and like I said before, expect additional notes in this place soon.
On December 18, 8:34 CET, Jens Nedal said:

Sean, one could not put it into better words. Thank you.

Jens, i see the possible danger in ending up with something like Choke (which i laughed about hilariously).
On January 3, 17:46 CET, Martin McNickle said:

1) Dress socks and sports socks go in separate drawers.

2) Comments should, of course, be ignored by the parser.

3) Maintainance is helped by well organised code.

I believe a few CSS files are not a problem as long as the content contained in each is separated logically. I find that organising code into several files often increases maintainability.

This could come from my background as a traditional programmer. A recent project I was working on had all the functionality in one huge 15000 line file. That code was unmaintainable. I know this doesn’t translate exactly to CSS but I hope you can appreciate the sentiment.

5) I would love to be able to “write once, run everywhere.”

—

I do appreciate what you are saying about CCs. I feel the same about traditional CSS hacks. I don’t advocate either of them for a minute. I spend a long time avoiding them.

The only thing that CCs have going for them is that they are obvious as a hack. They hold up their hands and say “this is a hack, right here, in between these tags.” Selector hacks are hideous, unclear and in my mind, completely unmaintainable.

So to reiterate, both are bad, repeat bad, but CCs are the lesser of two evils.
On March 6, 0:02 CET, Brian said:

1) I throw them all into the same drawer, because I’m lazy.

2) Comments should be ignored by default. However, *this very property* is exactly what makes them the perfect vehicle for introducing new directives that won’t break existing parsers. This is very common practice in many languages as noted by Eric Eggert in comment #4.

3) The less maintenance the better. Using hacks means having to test all those hacks again, whenever a new browser comes out. Of course the number of files is important, but more files doesn’t automatically mean more maintenance, especially if tweaks in conditional stylesheets are kept to the barest minimum necessary, and are adequately documented (ie, with comments in the main stylesheet).

4) Of course.

5) In an ideal world, standardization would mean a standards-compliant website would render the same in all browsers. Unfortunately this is not the case, and we are forced to use browser-specific rules in certain situations. HACKS AND CCs *BOTH* VIOLATE STANDARDS. However, CCs are future-proof and hacks are not, thus CCs are the lesser of two evils.

Future-proofing is the core issue here. I *KNOW* that IE8+ will not have any problems with a conditional IE6 stylesheet. I have no idea whatsoever how IE8+ will handle hacks.

No offense Jens, but I have yet to see you directly address this extremely important point, in either this post or the other one.

Allow me to posit my own questions for you:

1) Is using code almost guaranteed to break at some unpredictable point in the future good practice?

2) Is having “logic” in the markup to target specific rendering agents inherently bad?

3) Does having code logically split into multiple files increase or decrease maintainability?

4) If hacks could be found that only targetted printing, would you advocate using those, instead of print stylesheets?

5) Did the release of IE7 break sites that depended on hacks?
On March 9, 13:22 CET, Simeon said:

The first question is ridicolous. Let’s ask you this; how do you sort your CSS? You use external stylesheets or do you stuff the whole website in one single file? Or with your metaphor; how do you sort your socks and flour? Do you pour the flour in with the socks or keep it in a bag in the cupboards? Really, that’s how your question sounds. What you meant was that there will be an extra external stylesheet for IE, right? Then we have another factor; not every browser is gonna look for the extra stylesheet, as well as not everyone is gonna look for your unordered socks. Since CCs don’t break on browser upgrade, you won’t even have to update those ie6.css stylesheets as often as you have to update those ie6_hacks.css stylesheets.

On the second question, IE is not following standards, so why should we follow standards when developing for IE? It just makes it harder. Standards were made for the browsers supporting them. Comments are ignored by all browsers, I hardly think you would “happen” to write a conditional comment when commenting your HTML document. “Oups, I unintentionally wrote [if IE 6] in the comment…”

Thirdly, all you need is one extra stylesheet for IE specifics. If that single extra stylesheet exceeds, let’s say 30 lines, then you have to redesign your layout because you’re doing it wrong. Do it again, do it right.

Brian had really good points on the fourth and fifth questions, so I just confide agreement with the preceding speaker on those.
On April 7, 19:22 CEST, Bert said:

1) I keep my socks there where it is most convenient and practicle.
2) Ok, the w3c spec states that comments should not be parsed, but I don’t think they thought about this type of usage. What if they change this in future specs? Will you then switch sides? Besides, the validator does not invalidate your markup when it contains a CC. And more importantly, the CC does not malform your code nor does it interfere in any way with how other browsers parse the code.
3) The number of files is totally irrelevant to me. Structure is relevant. And sometimes multiple files provide better structure. Being able to pinpoint exactly where IE breaks by means of a seperate stylesheet is better than testing hack after hack. (See also my answer to point 5)
4) Yes, and I think using a CC that will AUTOMATICALLY become redundant when the targeted IE dies, is a better prognoses than updating my hacked CSS each time a new version arrives.
5) The benefit is that you know what to expect from your code. And as long as browsers do not display uniformly, I would actually like to see CCs for each and every browser.
I don’t use CSS hacks at all, and I use CCs only when no other alternative is possible, but I prefer it over hacks as I know for sure that I will never have to look at it again.
On April 16, 21:05 CEST, Ger Hobbelt said:

Despite my agreement with Sean (#7), I’ll bite. Because it’s that sort of day.

Q #1: I put my socks in several drawers: socks that go with my formal/professional cloths, socks that go with jeans and otherwise workmanly outfit for when I’m going to work on something rather more physical and thirdly - and that’s what I didn’t see here yet - all my socks with /holes/ in them go into their own separate space. Bacause I don;t like to find them on my feet at 7 AM when I’m in a hurry to get out to work.

Q #2: Comments are documentation. Treat as such. I’m a backend/you-name-it engineer: some crufty compilers abuse comments, but that’s also where certain language [standard] designers have been smart to provide an opt-in for decades already, e.g. #pragma statements (C/C++). Of course C/C++/… has it’s CCs and CSS hacks too, nevertheless.

Q #3: Yes, relevant. /Not/ in the sense that a design goal must be to compress everything into the minimum number of files possible (1? or even 0.0001? you’re /good/ then).
Ad vision: my vision is that I like to change things in one place per functional subject only, where-ever possible: copy&paste-alike duplication is to be frowned upon. (And the occasional hit with a fresh set of twigs might be appropriate education.)

Q #4: Yup. Very good question. Very generic too. Typical ‘cover all bases’.

Q #5: Benefit = one bible to learn for multiple jobs/applications; hopefully the brainpower designing the standard has been able to produce a semantically and syntactically consistent (~ orthogonal) design and - praise your diety/-ies if they achieved this - an unambiguous and complete specification to go with that.
Basically, I don’t care so much about standards (you can flame me on that, before you read on), but more about the number of different things I have to learn and remember to do the things I want to do. Less is generally better (but not always). In languages and applications, I hate exceptions, especially when people find they must put minimalization of code/words before reduction of number of exceptions.

I’ve read through the previous (closed) CC discussion and this one and I find the comments of high quality.
Given my background (backend construction, C/C++/C#/… with PHP/HTML/… rather as icing on the cake) I’m slightly upset I didn’t see explicit ‘modularization’ mentioned as an argument here yet - I might have missed it though; I blame my nearsightedness.

The problem I see here is it’s mixing two issues: (a) the whole diatribe here is about arguing the /must/ for standardization adherence while trying to fix certified /non/-standard applications (IE for one; Safari and others too), this is a no-win situation: either of these sides has to bow its head. (b) next, the same discussion is made ‘interesting’ by making it an argument over which sort of noncompliant temporary solution (hack) is ‘better’ (more Godly) than the other, though both are agreed to be hacks (i.e. sins you should stay away from).

You want standard compliance all the way up your crevice? Disregard IE/etc. noncompliancy and accept that decision /and/ the consequences thereof. Don’t yammer. Thou art free of sin, though.

You want to reach the maximum number of people? Confess your sins Sunday next and do what you have to now, so you may reach your goal. Realize you did something ‘bad’, and again, live with it. Try to keep it down, though. The fact you can doesn’t mean you should all the time.

Modularization? It’s so old, it’s almost antique design wisdom by now? Separating content and display is one modularization choice. Amazingly we stop to consider it beyond that point: if you have to support multiple, disparate visual rendering engines (a.k.a. browsers), in my line of work it is a common practice to provide wrappers (alias drivers / interfaces / plugins / whatchamacallit) for each, based on a single template (here, that’s the ideal compliant browser). In other words: you put the processing of /specific engine (browser)/ quirks in a separate module per subject (browser/browser group). Like a very clear comment on the previous CC article explained, this significantly improves your testability by restricting access of those targeted hacks to the intended target only.
CSS hacks are not in a separate module accessible only to one, so are accessed by every new browser (which comes with its own bugs as God wasn’t its engineer), resulting in /undeterminable/ /probable/ damage. That’s Q no. 4 right there in favor of CC’s for IE: we know for sure no-one else will touch them as they are comments in reality and there’s no-one else outside MS wishing to implement this.

Both CC and CSS hacks are ’sins’. Anyone saying CSS hacks are any better because they are standards compliant should reconsider their life, as I think you will be highly successful as a lawyer; nice thing that new profession will bring in more money per annum too and is one of the very few jobs that are close to guaranteed futureproof - at least as long as there’s any sort of human society, your bed is made.
Why? Because you have proven to be able to walk the very fine line beyond the ambiguity and holes of the law (the W3C standards).

Neither CSS hacks nor CCs are anywhere near standards complaint from a solid engineering viewpoint. Lawyers may and should disagree here most empathetically.

The fact that some folks believe using a CC permits or even demands you to copy/paste your complete CSS set, is proof to me that our educational system has let slip through one more despite all our efforts.
Neither does the use of CCs free you from CSS hacks: if you decide to offer a hand to other non-compliant browsers such as Safari, you’re still having to muck around some more. That part of the discussion has only been touched in a few places here: how far are you willing to sin, either way, to help your employers reach the people which do not adhere to (your) standards?

In a way it’s funny, as it is very similar to the choice put to religious preachers for millennia: are you willing to live among the sinners in order to get a chance to convert them? And how far are you willing to soil your soul to reach out to them that should join your religion? (religion = full W3C standards compliance without ambiguity)

Sorry for the wordcount. Basically I think it’s ridiculous to feel strongly for either CSS or CCs ‘properness’ in any way, though I lean towards CCs as they allow at least some level of modularization that’s simply impossible with CSS hacks alone.
Here’s the petrol. Got enough car tires already. And you can have my lighter too. Winnie knew what to do, so can you. Your choice.
On April 17, 14:59 CEST, Jens Meiert said:

Well, now I almost need to print the discussion, especially referring to Ger’s recent comment (I truly appreciate that!) to give really specific feedback. Apart from that and some different opinions, I may thank you for your time and passion, guys!
On April 30, 14:01 CEST, Edward Edmonds said:

I have been a web developer since the first version of Mosaic was released, that’s a long time, and I’ve seen a lot of changes for the good, and a lot of changes that I had to scratch my head a little, all in all the changes have been for the good. If they weren’t what is possible today—wouldn’t be possible.

I’ve seen a lot of IE bashing for a long time, most of the time I just laugh, because really these arguments have nothing to do with Microsoft or IE, it has to do with your pathetic outlook on life and piss poor attitude.

Building a completely so called “standards compliant” website is farfetched and unrealistic, it is possible though in simple cases, but for sites with any significant functionality different browsers treat different things differently. That’s the way things are and will probably be till the day I die.

And quite frankly you control freak pricks; realize that while having some sort of standard is good, being a control freak is not, a company has the right to add features to its browser that are different from other browsers, in fact sometimes doing that gets the others browsers scratching their heads saying, “hmm, maybe that is a good idea”…

IE is a different platform than Mozilla or Opera, just like Windows is a different platform than Unix or BeOS, they all implement things differently they all have their own software, some software is even cross platform like applications written in Java, but even Java with all its promises of being cross platform still falls short when it comes to achieving that goal in all but the most simple applications.

There comes a point in time when it’s just simpler to write a bit of native code than to look for an all encompassing solution, because most of the time people are being paid, and finding such a solution costs too much money. And (excuse my grammar) a lot of times the performance drag of such an all encompassing solution really doesn’t justify your so called perfect solution.

So again pricks, for me IE conditionals seem like a good idea, I have one IE style sheet in between CC’s that override my CSS when need be, 1 freaking file, that I almost never ever touch, plus guess what? I don’t have to invoke an instance of the JavaScript engine with browser detection code, that’s more clock cycles for the user to have to themselves.

If you’d like to revert to a control freak world be my guest, but that’s where innovation dies, move back to England or some where in Europe for that phenomenon.

Again being standards compliant is a good thing I don’t argue that, but at the same time a company has to bend the mold to introduce new things to stay on top or introduce change… after all let’s not forget what company introduced the none standards compliant XMLHttpRequest, you freaking assholes, that made things like AJAX a reality.

If you write good applications people will use them, if you write shitty or unusable applications all except the most retarded people won’t use them (excluding academic folks). [Remember people want things that are easy to use, that don’t require a rocket science degree to use them. Because remember people use technology supposedly because it gives them more free time to do what is really important. (That doesn’t apply to developers since developing these solutions is your job.)]

And if CSS or browser differences are causing you headaches and you are a real web developer that actually gets paid and has a family, than charge more for your so-called expertise, otherwise bite, and crawl in a corner.

Happily and Sincerely Yours,
Edward Edmonds

Jens Meiert

5 Questions for Conditional Comments Fans

Read More

Comments

Leave a Comment