Sent by Mark Richards on 10 March 2008 15:03
> -----Original Message-----
> From: Alan Gresley
> Conditional Comments can be problematic to maintained and some
beginners
> will start adding them to every page. Sometimes if it's not a
> true CCS rendering issue at all but just incorrect
> understanding of CSS or invalid CSS and markup.
I don't see how that problem is different from CSS hacks that import
separate stylesheets, actually.
> Should I just stop supporting for IE6 now and remove all my
> other hack for it. When I have finished, there will be nothing
> left. Not quite true some elements will remain. :-)
I'm not saying "don't target".
> OK, you can zap a file form here or there and all is fixed
> but what list is this? Does everyone on this list use (I may
> be mistaken here) PHP? You are answering my question with a
> scripting solution. Will this help a beginner? My solutions
> is entirely based on CSS and markup. Please keep solutions on topic.
Ok, I admit that server-side scripting is off-topic, but then so is
code-maintenance in general. Personally I would be astonished to find
that most people are NOT using some server-side scripting system; who
has a totally static website in 2008? And anyway, even if your website
IS static, that suggests that there are only a few pages. If you're
maintaining a large site without some code generation and templates, I
feel sorry for you :)
As for helping beginners, I think conditional comments are still a
better solution than hacks specifically because they are easier for
beginners to understand. Anyone who can grasp a tiny bit of JavaScript,
and surely someone who can use the more advanced CSS selectors should be
able to understand the syntax of a conditional comment, and won't need
to worry about what the hacks are or how they work. And when you first
encounter a conditional comment on a page, even if you've never heard of
it, you can at least intuit what it does. Not so with a hack.
> > You seriously feel the above code is more readable, maintainable
> Yes I do. I have changed my import slightly.
>
>
> /*\*//*/
> @import url("test-ie8.css");
> @import("test-ie.css"); /* IE/Mac */
> @import test-ie; /* For IE5~7/Win */
So in order to be able to use this you need to understand that all three
constructs, which look (to me) like they should do the exact same thing,
actually work or don't work based on the browser you are using. It's
also possible that there are other browsers out there that will read
these imports (correctly or incorrectly) depending on what bugs THAT
browser has.
> The above code appears on "one" CSS file. I know exactly what
> it does.
But no beginner does, and not necessarily every CSS dev either. I know
about these hacks from this list, but I'd have to look up what the hacks
are for.
Hacks are based on doing something WRONG in CSS but having the browser
do something "RIGHT" in response. If the CSS code isn't valid the
browser should do NOTHING, but in the case of a hack it does something.
Exploiting that error is confusing to people who usually write correct
code, expecting that incorrect code will do nothing.
> I find all those linked style sheet redundant. You only need
> one. Even if you had an extra one for IE, why can't you use
> the star html (* html) or escapes within the style sheet to
> target or filter the difference versions of IE?
Because different versions of IE have different features and different
bugs, and require different fixes. Separating the fixes required makes
it easier to drop support later on, or to fix a bug without possibly
breaking the other browsers if they don't have that bug. Anyway it's
the same thing as your example: an IE stylesheet for every version that
needs it (remember: if I don't need any IE7 fixes I don't have an IE7
sheet and the script doesn't put that comment into the page). Most of
my pages have just an IE6 sheet, actually. (Where I work we don't
support IE/Mac).
> And that's why you should comment both your CSS and markup.
> We know what IE7 and IE8 does with those comments. OK, your
> perspective is from several people authorizing the code so
> when answering keep this in mind that there are also those
> single author. The full spectrum.
In my experience even a single author can be confused by his own code
later on. Comments help but they're not always there and not always
right. Doing things in a clear way from the beginning means less
reverse-engineering later.
> Yes I am targeting. Should I pull those imports out and make
> those pages look awful for IE/Mac, IE7 and IE8. Please tell
> me how else I can do this without conditional comment.
I'm not saying "don't target". We have to target. It's a sad necessity
because the browsers all have different capabilities and bugs. I also
agree with putting browser-specific fixes into browser-specific sheets.
I think it's reasonable to design stuff so that fixes required are kept
to a minimum, but sometimes you just have to fix some browser's broken
implementation. Naturally you want your pages to look good in as many
browsers as possible and you don't want to just drop stuff from your
page.
My issue is not with targeting but with the use of hacks to import
additional css files. If you have enough control of the site's content
that you can add files, and maybe add a bit of html, I think conditional
comments are the best tool to use. You can put your IE stuff in a
separate file, ignored by other browsers, easy to understand even 5
years from now, easy to maintain, and easy to zap when it's no longer
needed. You ask how you can target the various browsers without using
conditional comments but I think that's the wrong question. If the
browsers worked properly you wouldn't be able to target them except by
conditional comments. But because they not only have rendering bugs but
also parsing bugs, it happens that there is a trick you can use.
Frankly I wish the other browsers would adopt conditional comments.
Mark
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
