WordPress.org

Make WordPress Core

#23507 closed defect (bug) (fixed)

Twenty Thirteen: move IE-specific extra font-family property out of main stylesheet

Reported by: markmcwilliams Owned by:
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.6
Component: Bundled Theme Keywords: has-patch
Focuses: Cc:

Description

As per #23504, here's a separate ticket! :)

Having a very quick look through the stylesheet ...

I noticed that there was a double use of font-family on Line 212, which I don't think should be there?

Attachments (2)

23507.diff (427 bytes) - added by markmcwilliams 14 months ago.
23507.1.diff (1.8 KB) - added by obenland 14 months ago.
Moves all IE7-specific attributes to ie.css and removes the IE6-specific attribute.

Download all attachments as: .zip

Change History (16)

markmcwilliams14 months ago

comment:1 Viper007Bond14 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Blame Internet Explorer. It's a CSS hack for it. :)

comment:2 markmcwilliams14 months ago

I initially checked Google to see if it was before a CSS hack, but found nothing!

Upon reading that it is in there, specifically for Internet Explorer, I went in search of an article to find out why? Good news is that it turned up http://www.queness.com/post/5600/10-dirty-internet-explorer-css-hacks-you-might-not-know which states using _font-family: is for IE6 and below!!!

Now I appreciate I know nothing about CSS, but why are we supporting something that is really old, for a WordPress theme that has been designed for 2013? On this occasion, I completely disagree with that decision. Why hasn't this been used in Twenty Twelve, Twenty Eleven and Twenty Ten?

Looking back through the Twenty Thirteen CSS file, I can see further IE hacks ...

comment:3 Viper007Bond14 months ago

What's the harm including a simple fix for a browser that many people are still using, especially when it's already in place? I can see not wanting to add a new fix for such an old browser but why the desire to remove it?

I wasn't involved in the development of the theme but I don't see the problem.

comment:4 follow-up: markmcwilliams14 months ago

I know and understand you weren't involved, I'm just trying to figure out the rationale for wanting to support an out-of-date browser, especially IE6 of all sorts. It sort of defeats the purpose of having Browse Happy show up in WordPress dashboards, yet the newest default theme is happy to support them?

Very least there should be a little note, something like: /* IE6 Support */

comment:5 lancewillett14 months ago

We don't plan to support IE6 -- so will either remove those hacks completely -- or move anything IE7 and IE8 into the "ie.css" file.

comment:6 in reply to: ↑ 4 DrewAPicture14 months ago

Replying to markmcwilliams:

It sort of defeats the purpose of having Browse Happy show up in WordPress dashboards, yet the newest default theme is happy to support them?

There's a big difference between back-end and front-end browser support and how each is decided. Front-end typically has to have wider support for older browsers.

comment:7 markmcwilliams14 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

As per make/core I figured this should be reopened so we don't forget about it! :)

comment:8 SergeyBiryukov14 months ago

  • Milestone set to 3.6

comment:9 lancewillett14 months ago

  • Summary changed from Extra font-family in Twenty Thirteen stylesheet! to Twenty Thirteen: move IE-specific extra font-family property out of main stylesheet

obenland14 months ago

Moves all IE7-specific attributes to ie.css and removes the IE6-specific attribute.

comment:10 obenland14 months ago

  • Keywords commit added

comment:11 lancewillett14 months ago

In 23611:

Twenty Thirteen: move IE-specific properties out of main stylesheet. Props obenland, see #23507.

comment:12 lancewillett14 months ago

@obenland Are the filter properties still in main stylesheet because of IE9? There is also one case of IE7 styles in the custom header file, but probably no way to avoid that.

comment:13 obenland14 months ago

Those came from Joen, but yes, I think so.

comment:14 lancewillett14 months ago

  • Keywords commit removed
  • Resolution set to fixed
  • Status changed from reopened to closed

OK, closing.

Note: See TracTickets for help on using tickets.