Fixed .pageNavLinkGroup -> enable better clearfix

[CyberAP]

Current clearfix in .pageNavLinkGroup cuts the box-shadow of the button.

This is caused by a "dirty" clearfix using overflow: hidden;

I suggest to replace it with a pseudo-element clearfix, that is wisely used in discussion view for example.
So the code will be:

.pageNavLinkGroup:after
{
content: "";
display: block;
clear: both;
visibility: hidden;
}

To compare:

​

Dirty clearfix



A better one, pesudo-element clearfix.

 

[dutchbb]

I noticed this before but forgot about it.

 

[Mike]

The problem is that clear fix triggers clear: both, so it will cause problems when there are other floats involved. It's slightly contrived, but this does apply to the resource manager, for example. Alternative float containment methods (display: table) seem to have some other issues because of the automatic contraction; applying the necessary width has other knock on effects.

Not sure how we should best handle this now.

 

[CyberAP]

Hmm, tried this with RM right now. I see now issues so far, but I do understand what you're talking about.
http://css-live.ru/Primer/new-clearfix/demo.html

 

[CyberAP]

Here is the new clearfix we can use:

.pageNavLinkGroup:after
{
  content: ". .";
  display: block;
  word-spacing: 99in;
  height: 0;
  overflow: hidden;
  font-size: 0.13em;
  line-height: 0;
}

Source: http://css-live.ru/tricks/novaya-alternativa-clearfix-u-i-overflowhidden.html

 

[Mike]

The RM example is contrived, but set the resources per page to 1 and add a border to the page link group - it will expand to the bottom of the left column. It isn't a particularly big deal here, but it would be if something were after the page nav.

Using display: table with width: 100% would cause problems with margins and using the RM again, it pushes the page nav below the inline mod options.

However, that "new context" (the last option) at that page looks interesting so I'll have to play with that.

 

[Mike]

I'm experimenting with the "new context" option in 1.2 and it looks to be working pretty well. It seems to be an interesting way of working around the automatic contraction of display:table while still handling padding. We'll see how it goes through the beta. We can always revert to the original method, which isn't that big of a deal.