Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Clear Fix/Modernizr Problems in Safari (6.0.5) #284

Closed
seansean11 opened this Issue · 9 comments

7 participants

@seansean11

I want to start this out by saying _'s is awesome and thank you so much for making it.

I had a client today tell me that their site was showing up as a blank white canvas in Safari. After investigating I realized that the display table on the psuedo-elements in the clearfix was causing the html element (with a white bg) to be rendered with a higher z-index than the rest of the page and consequently cover the entire page with white.

The reason this occurred was that the [class="site"] and [class="content"] selectors when used in unison with Modernizr will select the "generatedcontent" class that is added to the html element. As a regular user of _'s I would prefer that the css didn't contain these selectors out of the box, so that I can choose my clearfixes, but wouldn't you be able to get the job done using the "^" selector instead of "*" in this case? I would be open to making a fix, but not sure what your course of action will be.

@SDavisMedia

I can't imagine anything being a better solution besides targeting the elements specifically. Using "^" would fix your issue but could easily cause a similar issue with the next install's classes considering "content" is commonly used.

I agree that the attribute selectors should be avoided if possible... especially with such common terms like "content." Other attribute selectors included in _s, like [class*="navigation"], at least have or are descendant selectors.

@seansean11

Yea, I understand the difficulty there ([class*="site-"] might also be another option). Maybe I'm mistaken, but I would think that many (maybe even most) _'s users also have Modernizr installed. These more specific selectors may help prevent future interferences, although it won't solve the problem.

After checking, I realized that another one of my client sites also has the same issue.

@grappler

This was discussed here too. #212

@seansean11

Thanks, and sorry for the repeat bug report. I think I'm just going to use my own base CSS with _'s from now on, in order to avoid any future complications.

@obenland
Owner

@grappler suggest to go with that:

.clear:before,
.clear:after,
[class*="-content"]:before,
[class*="-content"]:after,
[class*="site-"]:before,
[class*="site-"]:after {
        content: '';
        display: table;
}

I'd be fine with that. It would fix the issue, correct?

@seansean11

Hmmm....I'd have to look into the theme a little bit more, but I do see a selector used right off the bat of "content-area" which must be selected by this clearfix currently. With that new star selector rule, it would be left out. There is probably a nice and organized way about the process if you were to analyze the selectors being used and where clearfixes should be applied out-of-the-box.

I think that starting a theme with "*" selectors which are so generalized could be dangerous for development. So, it might be a more philosophical question of when, if at all, these clearfixes should be applied to the theme. Or, maybe we can just place the blame on Safari for the issue. For some reason setting pseudo elements to display table on the html element in Safari causes z-index problems, but I haven't seen this in any other browsers.

@emiluzelac

You can substitute

*
with
^

@Brendonwbrown

Thank you very much. I was scratching my head over this very problem.

@obenland obenland closed this issue from a commit
@obenland obenland _s: Be more specific about clearing elements.
(Introduced in b1d3b53)

While class attribute selectors are very powerful and might help in
keeping stylesheets concise and easier to maintain, they don't work very
well with a project like WordPress. Not only can third-party scripts
insert and rely on specific class names that get picked up by attribute
selectors for common class names. But more importantly WordPress passes
category and tag slugs on to post classes, which can result in
unpredictible results.

Fixes #284, fixes #309.
dff92a0
@obenland obenland closed this in dff92a0
@ElShaddai

Thanks very much for tracking this down. I had it nailed down as far as a conflict with Modernizr, but you've saved me many hours!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.