.equalize - Not working? Better approaches? about wet-boew HOT 18 CLOSED

Thanks you for the bug report. We're glad you are interested in our project and are considering using it as the base of your next project. Quickly looking into this issue it looks like you are correct that the equalize JS is not loading any more. We used to use a CSS-based approach that worked in IE6 and IE7 but it was very problematic so we abandoned it for the much easier JavaScript approach. We've since dropped support for IE6 and are looking to phase out IE7 some time in the future (based upon usage stats) so we're open to better ways of doing things (while providing IE7 fallbacks for now). If CSS can be a reliable way of achieving equal heights columns then it would certainly be the better approach maintenance and performance-wise.

We'll look into this to get equalize working again and to investigate a better approach for modern browsers. We also welcome pull requests if you are interested in helping us out.

from wet-boew.

Equalize is working again. I added it as a global plugin that is called through settings.js. I tried to use display:table and display:table-cell to achieve equal heights but it doesn't seem to work with floated content and doesn't seem to allow moving columns around as is done with the content area and the secondary menu (secondary menu is structurally after the content area but is supposed to be visually to the left of the content area).

Please let me know if you have any suggestions for achieving equal heights through CSS only while still being able to swap the visual order of the columns.

from wet-boew.

The old stand-by I used to use was the pie (position is everything) trick for equal height floated columns, but as we quickly discovered, they had issues when anchor tags were used inside such columns (you couldn't see the content above thanks to the overflow hidden!).

Display table is definitely the way to go now, lose the floats for column-based layouts. You can even swap the order of the columns if you calculate things correctly, and for IE 6 and 7 there's calculations to even things out without JS: http://www.gunlaug.no/tos/moa_11h.html

The trick to swap columns is, as with floats, using margins. In this case, you create the columns first using table-row and table-cell, and you can (as shown) use direction: rtl to reverse the direction of the cells. If you need more than that, e.g. swap content from column 1 to column 2, then you set the display: table-cell div to the width of the columns, and shift the content inside using positioning and widths.

To make sure this works the way I think it does, I edited it in Chrome and it does still seem to work as a technique, but I had to switch from position: relative to a content wrapper with position: absolute and margins. I tried using floats instead, but the width of floats, unlike absolute positioned content, is used when re-calculating the table cell widths/distribution. (Since tables scale columns to equally redistribute content when the widths of content inside cells are wider than the table itself.) It may seem strange to use position: absolute but it's still less of a hack in my mind than the dreaded "clearfix" class.

Admittedly, I'm not designing a grid here, but I'd give table-cell methods more credit. See also: http://www.sitepoint.com/give-floats-the-flick-in-css-layouts/

from wet-boew.

Reopening as an enhancement to be investigated.

from wet-boew.

Is anyone able to investigate this? Would be good to find a way to make this CSS-based where possible. Ideally it would be CSS-based for browsers that support the table CSS and JS-based as a fallback for the other browsers.

from wet-boew.

(moved the discussion from #907 to keep things clean).

I now have a working CSS .equalize pushed to my fork. The one item I'm not 100% happy with is when .equalize is used on .module-* elements in IE9/10. I've had to use multiple background images to simulate the outline because of just how awesome that browser is:

Demo of behaviour

Following is how the two different hacks I've used display in IE9:

1. First row uses an :after pseudo element and a CSS outline. Unfortunately it doesn't expand to the full height of it's parent's content though. If anyone has any ideas on how to fix this, it is definitely the better solution.
2. Second row uses multiple background images. This will add heft to the CSS since we'll need to encode 4 backgrounds per module outline colour. On the plus side, I should be able to put together a function that can do the Base64 encoding from a hex or rgb value (adapting this example).

Also open to any other suggestions on the above IE9+ problem.

from wet-boew.

I'd like to avoid adding heft to the CSS if possible. One possible option is that in the interim we can load equalize.js for the browsers that need it until we figure this out. Can use pe.ie to target IE7/8/9 with the JS fix. Ideally we would eliminate the need for equalize.js but if there are drawbacks to the solution then I'd rather the impact be felt solely by the affected browsers.

Another hack could be to detect IE9 and then apply IE9 specific-CSS to equalize (if there are IE9-specific CSS that could help). Could do that by using JS to add "ie9" to the html element class and then targeting with .ie9 .equalize. Not a clean solution but better performance than the previous suggestion (since no extra http transfers and mostly CSS-based). One possible approach would be border + negative margins but that could get messy.

As for a pure-CSS based solution, can't think of one off the top of my head that wouldn't impact other browsers.

from wet-boew.

Unfortunately the above is already using .ie9 targeted CSS hacks with this change in pe._init():

if (pe.ie > 8) {
    $html.addClass('ie' + parseInt(pe.ie, 10));
}

I've been banging my head against the IE-only CSS for a while so your suggestion of serving equalize.js to IE7/8/9 may be the way to go unless someone has another idea.

from wet-boew.

IE8 and under could use CSS expressions, but they do tend to be expensive on the DOM

from wet-boew.

Better to rely on equalize.js because of the number of hits CSS expressions do to the DOM (which are effectively scripting anyway).

from wet-boew.

I couldn't seem to compile the fork in a way that duplicated the results of the above demo, @patheard -- it actually looked fine for me in IE10 and IE9 emulation modes.I must not have compiled it properly. Meanwhile IE is my favourite browser to debug with, because editing inline always (read: never) works for me, so I can't debug easily from the page. I wonder, though, if it has anything to do with the box-sizing property applied to module divs. As to IE10, you could try some of the newer layout techniques most commonly found in Windows 8/RT apps: http://blogs.msdn.com/b/ie/archive/2011/04/14/ie10-platform-preview-and-css-features-for-adaptive-layouts.aspx

from wet-boew.

Thanks for the suggestions @LouisStAmour (this bug has been driving me crazy). When you view my demo page in IE9/10 do you see the bug in action for the top row?

I was thinking that box-sizing might be the problem too, but I've experimented with the different properties and had no luck.

I'm also pretty excited about the adaptive layout options that are coming. Once flexbox layout has better support, this'll do the trick for us:

.equalize {
    display: flex;
    flex-flow: row wrap;   
}

.equalize #wb-sec {
    order: -1;
}

from wet-boew.

I see it on the demo page hosted by github, but downloading your repo, and viewing the page locally after compiling, did not exhibit the bug. So I'm a fair bit perplexed also. It shows in IE10 under Standards and Quirks modes, and in IE9 emulation from the Developer Tools dropdown.

from wet-boew.

What browser mode does your browser switch to when viewing files locally? From my experience, IE8 and IE9 switched to compatibility (IE7) mode when viewing local files (or at least intranet files). It only went in the normal browser mode when viewing files on the Web.

from wet-boew.

I use the Developer Tools (F12 or from Options drop down) to override the
browser mode switching, so it was in strict/IE10, or strict/IE9 in my
testing.

On Wed, Feb 6, 2013 at 12:00 PM, Paul Jackson [email protected]:

What browser mode does your browser switch to when viewing files locally?
From my experience, IE8 and IE9 switched to compatibility (IE7) mode when
viewing local files (or at least intranet files). It only went in the
normal browser mode when viewing files on the Web.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/75#issuecomment-13192471.

from wet-boew.

If you can write a Selenium test, we could run it through https://saucelabs.com/ on non-emulated old IE

from wet-boew.

I just ran manual tests through IE9/10 with Sauce Labs and I'm seeing the same bug. Nice testing service though.

@LouisStAmour That's odd that you can't see the changes when you build my equalize branch locally. Here are the steps that work for me:

1. Download the equalize branch and unzip.
2. Open a command prompt at the wet-boew-equalize root and run ant without a build target (invokes the default full build).

To check if the CSS is there, you could open up the following file:

C:\wherever-you-unziped\wet-boew-equalize\dist\grids\css\util-min.css

And search for:

.ie9 .equalize.after>[class*="module-"]

from wet-boew.

Closing issue since an integration with Twitter Bootstrap was done previously (as part of Grids) and the CSS-based equal column heights was just implemented for browsers that can support it.

from wet-boew.