make html tags to have IE related classes to ease in cross browser fixes #56

Closed
wants to merge 1 commit into
from

Projects

None yet

6 participants

@ashfame

How about incorporating HTML5BP / Paul Irish's method of adding IE related classes to HTML tag so that it helps/encourage front end developers to use best practices while making their design cross browser?

This will make users to have a cleaner code and since _s is like the WordPress theme boilerplate, I think it will be good to have this in. Thoughts?

Let me know if it would be good to add some pointers or usage example in style.css for preaching about this technique.

P.S. - As seen in HTML5 boilerplate v3 - http://html5boilerplate.com

@kovshenin

Hi there! In my opinion, I don't think having device-specific, browser-specific or even worse, browser-version-specific code can be considered as "cleaner code," and this definitely does not fall in the 80/20 rule (is there one for _s?)

@ashfame

Hey mate, not sure how does the 80/20 rule fits here or does it have a variant I don't know of? :)

By cleaner code, I meant the HTML code generated in the end. Instead of embedding stylesheets in conditional IE statements, this is a better way. IE is a pain for everyone, and it helps in that direction by giving the option of dealing with it in the best possible way, and we end up doing this on every theme we work on, so thought it would be ideal to bake this in _s itself :)

I see _s as a combination of best practices of WordPress + Web dev in general (HTML5BP)

And in reply to browser/device specific issues, I saw some CSS rules for cross browser gradients which are not idle to have it in either, we end up removing all the time. Just wondering how can I align myself along the lines of wise decision making.

@kovshenin

and we end up doing this on every theme we work on

When working with themes I do my best to avoid browser-specific code, with exceptions of course (-moz-, -webkit-, ...) and I don't think that an extra class with the IE version will make my code any cleaner or easier to understand. Don't get me wrong, embedding stylesheets in conditional IE statements isn't any better. If there's a way to avoid both, we should avoid both :)

Anyway, that's just my opinion, and everybody has their own way of developing themes.

@ashfame

Yep if there's a way to avoid both, that will be ideal but then practically speaking, avoiding them completely is not possible. IMO, having just a single CSS for everything keeps the head section clean by avoiding those conditional stylesheet inclusions.

Lets wait for someone else to chime in before making a final call if such a thing should be merged/purged in the direction of where _s is headed :)

@philiparthurmoore

I'm pretty much in complete agreement that we should add browser-specific IDs or classes into the header of _s because I end up using them with every single theme that I develop. One of the best uses I can cite is something like the following:


img {
    height: auto; /* Make sure images with WordPress-added height and width attributes are scaled correctly */
    max-width: 100%; /* Prevent images from overflowing their boundaries */
}
#ie8 img {
    width: auto; /* Prevent stretching of full-size images with height and width attributes in IE8 */
}

So the following always ends up in my header, no matter what I'm working on:


<!--[if IE 8]>
<html id="ie8" <?php language_attributes(); ?>>
<![endif]-->
<!--[if !(IE 8)]><!-->
<html <?php language_attributes(); ?>>
<!--<![endif]-->

What I'm not so sure we all agree on is which browsers should be taken into account. We no longer support IE7 on WordPress.com and in my own personal projects I ignore it completely. Really the only browser I feel the need to target is IE8, not IE9, IE7, or (bleh) IE6.

To the point about the goal of _s, it's a tough one. Case-by-case to be sure, but sometimes adding something in or leaving something out for the sake of education and demonstration makes total sense to me. See this comment from @mfields. I'm totally in agreement with his reasoning and think that similar logic could be applied here.

I don't think we should make this change immediately because I'd like to hear from other folks, but count me in as one of the people who thinks adding something in to avoid repetition in this case wouldn't be a bad idea.

@ianstewart

I like Paul Irish's method of using conditional comments to target versions of IE but I dislike the idea of seeing it in underscores as a standard. I'm not convinced that the majority of themes we make need to target multiple versions of IE. That said, I'm a big fan of graceful degradation and of totally ignoring everything below IE8. That frees up the need to worry about IE for most theme designs. Sorry Mac IE 5.

@ianstewart

Does anyone else have an opinion on this one?

@corvannoorloos

At h5bp they're currently thinking about dropping IE6/7 support. As they are basically the current standard my suggestion would be to put this issue on hold for a month to see what its outcome will be.

@lancewillett
Automattic member

I vote to leave this out of _s — themers can add it in on their own after forking.

@kovshenin

If we're voting, then I'm with @lancewillett. We can revisit this after seeing more released _s-based themes.

@corvannoorloos

If we're voting, then I'm with @lancewillett. We can revisit this after seeing more released _s-based themes.

I agree

@philiparthurmoore

Switching my vote to leaving this out, especially given the recent news that Google Apps is dropping IE8 support on November 15th. Happy with adding browser-specific classes/IDs on an as-needed basis.

@ianstewart

I haven't counted but with IE8 being shown the door I'm saying the nays have it.

@ianstewart ianstewart closed this Sep 21, 2012
@ashfame ashfame referenced this pull request Jan 12, 2013
Closed

Made some changes #134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment