Jens Meiert

5 Questions for Conditional Comments Fans

Jens Meiert, December 13, 2007 / March 1, 2009.

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:

  1. 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?

  2. What is your opinion on markup comments, how should they be treated by a parser?

  3. What is your vision for website maintenance? Is the number of files to be maintained relevant to you?

  4. Do you consider probability estimation to be important in professional decisions?

  5. 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).

Read More

Enjoy the most popular posts, probably including:

Comments

  1. On December 13, 2007, 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.

  2. On December 13, 2007, 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.

  3. On December 13, 2007, 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.

  4. On December 15, 2007, 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.

  5. On December 15, 2007, 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.

  6. On December 15, 2007, 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

  7. On December 16, 2007, 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.

  8. On December 16, 2007, 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.

  9. On December 18, 2007, 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).

  10. On January 3, 2008, 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.

  11. On March 6, 2008, 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?

  12. On March 9, 2008, 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.

  13. On April 7, 2008, 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.

  14. On April 16, 2008, 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.

  15. On April 17, 2008, 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!

  16. On April 30, 2008, 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

  17. On June 24, 2008, 21:38 CEST, Ricardo said:

    hmm. CSS hacks are susceptible to changes in the parser, conditional comments are not. Even if Microsoft decides to drop support for it, nothing will happen, it’s just a comment ignored by the parser. They were created exactly for this, you specify which versions of IE you want to target and *bam*, magic happens: only those versions are affected. There’s no disadvantage - just an extra CSS file (which will usually consist of less than 10 rules if your main code is written properly). I can’t see ANY advantage in using hacks. They are not standard either.

    Point 2: standards are for guaranteeing accessibility, conditional comments are doing no harm - actually they are enhancing accesibility by providing correct page viewing in older browsers. I can’t wrap my mind around the idea of using css hacks instead, what the hell are you thinking? Think about maintenance for hacks vs CC and that’s enough.

  18. On June 24, 2008, 21:38 CEST, Ricardo said:

    btw, who knows? Maybe CC will become standard in the future. Don’t limit yourself.

  19. On August 18, 2008, 0:40 CEST, Al Boulley said:

    Please Jens, respond to some of the points being made here…..

    On March 6, Brian called you to task. Read his answer to your question #5 and perhaps even answer his 5 questions. It looks like you are aware of his request in your post on April 17, but as is obvious it looks like you’re dodging his request. Bottom line seems to be, several well-spoken individuals have stated that CSS hacks are not “future safe” whereas CC’s “are”. Quite honestly, you seem very “zealous” (in the religious way) in your dismissal of CC’s/support for CSS hacks.

    Perhaps you would also like to post a rebuttal to the following article- http://www.digital-web.com/articles/keep_css_simple/ -or perhaps you don’t want to. I see several great points made in that discussion by Peter-Paul Koch. He was in fact mentioned in someone else’s comment (which you also didn’t respond to). And yes, I know you aren’t an advocate of “CSS hacks just because”, you seem to be in the “CSS hacks over CC only when…” camp. Regardless, you’ve made several statements which have been rebutted well in my opinion. But who am I, just an “outsider” right?

    Allow me to answer your question #1 and then you tell me all about what my answer means as it pertains to CSS hacks versus CC’s. Please note that I have not stated one way or the other which I prefer, because quite honestly I don’t develop enough websites to use either method. But I am intelligent and I see you making what amount to “dogma” arguments which rely on your “expert” status to enforce what amounts to an opinion.

    So - I keep my white socks in one drawer, my black socks in a second drawer, and all other socks (gray/colors) in a third drawer. Furthermore, what I do isn’t much different than having one huge drawer with white on the left, black on the right, and everything else in the middle. The intent to organize is the key, and obviously the dimensions of one’s chosen dresser. Of course, you have yet to mention how YOU store your socks, and I will not guess as to how that might be.

    I’ve yet to see anyone bring up things such as “<!–#if blahblah –>”… is such markup not considered a conditional comment, and if so why? Just throwing this out there for “completeness”.

    Lastly… I know you probably loved the abrasive tone of Edward Edmonds, because it gives you an “excuse” to ignore his entire comment. But I also loved his abrasive tone, because he uses it to show you just how infuriating your platform is. He uses it to show you that there are points being made which you are intentionally ignoring - points that others have made before his post. And, since you thank everyone for their passion, I see alot of passion in his statements. I would be impressed with you Jens if you could put on some studded leather armor and genuinely address the passionate *points* made by Mr. Edmonds.

    Yes I’ve given you alot to chew on, but I think you are starving yourself here.

  20. On August 22, 2008, 9:05 CEST, Jens Meiert said:

    Well. First, apologies for the ridiculously long time it sometimes takes me to reply. I’m working on that. Second, thank you all so much for contributing, and I love to see passion and commitment, something that appears to be especially evident when talking about this very topic, Conditional Comments. So:

    Brian, fair enough, let me finally answer your questions:

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

    No. But, and that “but” is big I fear, it depends.

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

    Yes, due to several reasons, at least two of them being unreliability (realistically, as we learned from several ways to identify user agents already) and worsened maintainability (talking about presentational stuff, and you can certainly consider style sheet references presentational as well).

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

    It depends (concerning CSS, where and how are style sheets linked, and how are they structured).

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

    No.

    5) Did the release of IE7 break sites that depended on hacks?

    Apparently. Of those of mine using “hacks”, none though. (However, how long did it take to fix eventual issues? And did this involve touching HTML?)

    Ger,

    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)

    Absolutely agreed. And that is exactly why I asked for the “benefit of standardization”.

    In a way it’s funny, as it is very similar to the choice put to religious preachers for millennia

    I’m not sure, however, I notice some faible for metaphors related to religion? ;)

    Edward, watch your tone before posting next time. Again, I appreciate passion, but I cannot accept insults.

    Al, thank you for reminding me of the utter “sensibility” of this post and the questions and issues raised in this thread. Appreciate you mailing me.

    Please Jens, respond to some of the points being made here…

    Consider it done ;)

    Perhaps you would also like to post a rebuttal to the following article- http://www.digital-web.com/articles/keep_css_simple/ -or perhaps you don’t want to. I see several great points made in that discussion by Peter-Paul Koch. He was in fact mentioned in someone else’s comment (which you also didn’t respond to).

    Oh I know his articles on “hacks”, and many of his points are valid and good. I guess I didn’t claim anything else anyway.

    And yes, I know you aren’t an advocate of “CSS hacks just because”, you seem to be in the “CSS hacks over CC only when…” camp.

    Yes.

    So - I keep my white socks in one drawer, my black socks in a second drawer, and all other socks (gray/colors) in a third drawer. Furthermore, what I do isn’t much different than having one huge drawer with white on the left, black on the right, and everything else in the middle. The intent to organize is the key, and obviously the dimensions of one’s chosen dresser. Of course, you have yet to mention how YOU store your socks, and I will not guess as to how that might be.

    Each pair folded, all in one place. Translating to rules for the same element in the same place, and all rules in one style sheet. However, the latter must not be misleading – there can be good reasons to use more than one style sheet. But, I consider this to be neither CC style sheets nor resets.

    I’ve yet to see anyone bring up things such as “<!–#if blahblah –>”… is such markup not considered a conditional comment, and if so why? Just throwing this out there for “completeness”.

    I guess that by definition, this is a “conditional comment”. However, does it belong into HTML documents?

    Lastly… I know you probably loved the abrasive tone of Edward Edmonds, because it gives you an “excuse” to ignore his entire comment. But I also loved his abrasive tone, because he uses it to show you just how infuriating your platform is. He uses it to show you that there are points being made which you are intentionally ignoring - points that others have made before his post. And, since you thank everyone for their passion, I see alot of passion in his statements. I would be impressed with you Jens if you could put on some studded leather armor and genuinely address the passionate *points* made by Mr. Edmonds.

    Well, as mentioned before, I appreciate passion and can very well deal with playing hardball, but, there are things that are not necessarily appropriate.

    However, I will close this thread as soon as some small follow-up is done (probably quite soon). Yet there’s some chance to leave a reply again, even when the author is sometimes lousy in replying.

Leave a Comment

Unfortunately, comments are closed.

Found a mistake? Reward! Email me, jens@meiert.com.

You are here: meiert.com – Archive for 2007 – 5 Questions for Conditional Comments Fans

Last update: March 1, 2009. Copyright 2000-2009 Jens Meiert. Legal notice.