Wedge

Public area => Bug reports => The Pub => Archived fixes => Topic started by: Nao on April 16th, 2013, 11:33 PM

Title: IE 6/7 + mini-menus = headache
Post by: Nao on April 16th, 2013, 11:33 PM

Okay, here's an example of what I'm seeing with IE10 in IE7 compatibility mode... That's awful.
This is supposed to be a mini-menu in the thoughts area.

What's happening then?
Here's the simplified structure of a mini-menu top-level entry:

<span>
   menu caption
   <ul>
    <li>contents...
   </ul>
</span>

'span' is set to position: relative
'ul' is set to position: absolute, so that for instance, setting top: 100% on it will position it right below the span text itself.

This works perfectly in all browsers, including IE8+.

In IE 6/7, and you can test on wedge.org if you'd like, the mini-menu is shown BEHIND the menu captions ("Action") for all other mini-menus. Not only that, but if you hover it, the mini-menu will close because it gives priority to the Action button that's supposed to be hidden behind it.

What's the reason for this..? Well, the span's position: relative is the culprit. If you remove it, then the mini-menu will never be overwritten, it will retain priority.
Only problem is, if I wanted to get rid of position: relative, I'll have to manually set (via JavaScript) the position for my mini-menu. Honestly, I'd rather not do that...!

Now, here's the thing: I spent the better part of the day LOOKING for examples of this IE bug online, but so far, I've found NOT EVEN a single description of the problem. It sounds as if the problem is ONLY on wedge.org, and/or ONLY on my PC.
Considering my IE6 copy is running in VirtualPC XP Mode, I can safely say it's the "real thing", and it's not a quirk of browser emulation, like broken filters in IETester + IE6.

I discovered the bug when I was trying to 'make things work' in IE 6/7 with regards to my main menu rewrite. I ended up giving up and reverting much of my changes, because I couldn't afford to drop compatibility with both IE 6/7 when it comes to the main menu.

I doubt anyone will be able to help, but it doesn't cost anything to ask. Can anyone reproduce this bug? And if yes, do you have any frigging idea what's happening..? Thanks!

Title: Re: IE 6/7 + mini-menus = headache
Post by: godboko71 on April 17th, 2013, 04:08 AM

I can test tomorrow at work. No ie6 or 7 at home

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 17th, 2013, 06:04 PM

The reason the bug didn't show up in mini-menus before I added the thought menus, is because there never was any overlap between these menus.

I made a quick test to remove most elements in the page, and sure enough, in a topic page, the user name shows up on top of the currently opened mini-menu (from the previous post.)

And believe it or not, I actually managed to fix it, ahem...
Not in a usable way.

I just replaced the ul's top: 100% declaration to bottom: 100%... As a result, it goes UP, but it also shows correctly.
I said it -- not usable. But still...!! The problem is, thus, not only in having a "position: relative" element outside of the current 'position' stack, the problem shows up only when setting a 'top' value on the absolutely positioned element Inside the stack.
Not setting top or bottom at all also fixes it... Which is why, I guess, we never had the problem in the main menu: this is because I didn't use positioning this way.

So, basically, I've reset the main menu code pretty close to what it used to be (and forfeited at least 100 saved bytes in the process... -_-), I'll try to make a IE6/7-specific version later, so as not to 'encumber' non-oldIE browsers with legacy code.
Still, I'm very, very upset. I still can't find any web page mentioning that at all. IE bugs are so thoroughly documented, I went through hasLayout and positioniseverything, two of the best sites for these, none of them mention this bug... -_-

Posted: April 17th, 2013, 02:46 PM

I'm so tempted to drop support for IE < 8.. :^^;:
This isn't like me.

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 17th, 2013, 07:26 PM

Okay... Given the lack of feedback... (I didn't expect anyone to be able to help... But at least some compassion please... :lol:)
I've decided that, while it'd be stupid to drop support for IE6/7 "just for that", I'll reconsider in a few months time, maybe in early 2014, when IE6 shares will be nothing to worry about, and IE7 shares should be much lower if automatic updates 'work'.

In the meantime, I've enabled a silly hack for thoughts... Instead of showing the menu below the action button, it's now shown on the right. Yeah, I told you, it's silly... But it works very, very well.
The only visible issue will be with the search popup, because it overlaps some <we:title> elements in the sidebar, which have position: relative set on them. (I don't remember exactly why, though... :^^;:) Perhaps I could just add a .sidebar .title { position: static } as a hack for IE6/7...

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 18th, 2013, 09:58 AM

Done some more testing...
Really, the 'only' way to realistically fix the problem, is to remove all 'position: relative' declarations, and instead just use 'position: absolute' on children, and manipulate position with regular CSS rather than with explicit left/top declarations.

It was already done this way in the main menu until I rewrote it to use position:relative for bytesize. I guess I'd already had the same problem in the past, and 'fixed' it with a simple 'clear: left'... Dunno if it'll work for mini-menus, too...

Here's what I'll do. I'm going to try and see if I can do it for mini-menus; if it works, then I'll just maintain two separate codebases -- one for IE6/7, one for other browsers. Under @if blocks, naturally. That way, regular browsers get the bytesize crunching, and IE gets it to work.. (Barely. As usual with it...)

I'm just posting to say, "Hey; I'm still on this. I'm not slacking. God please have mercy on me."

PS: last night, I discovered I was having the problem with the search popup as well -- it was being overlapped by the main menu... Sigh. AND EVEN IN NON-IE BROWSERS. YAY. The main menu does NOT have position: relative currently. I fixed it 'by magic' -- setting the popup's parent to have z-index: 1 (0 doesn't work).

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 18th, 2013, 05:33 PM

So... In order to fix IE6/7's crap, I can either add some custom CSS to make them, if not behave, at least remain usable... This is the solution I'm using currently; but alternatively, I could also add this JavaScript snippet I wrote...

Code: [Select]

var num = 100;
$('.mimenu').each(function () {
$(this).parent().css('z-index', num--);
});

Basically, it'll attribute a decreasing z-index, in DOM traversal order, to all .mimenu parents, i.e. the things that should have a 'position: relative' value.
I can confirm that it works... It solves the z-index issue in the thought list.
This also has the added benefit of fixing mini-menus without external help if plugins want to use them.

Still, I don't think it's worth adding 90 bytes of code just for oldIE, although it compresses to exactly 26 bytes. It's still 26 useless bytes for all other browsers... Well, it might be an opportunity to start caching JS like I'm doing with CSS, i.e. with the browser name in the filename, which would allow code to do @if ie[-8] instead of if (is_ie8down) for instance, and potentially remove all browser hacks from the JS code when your browser doesn't need them.
But Wedge doesn't have a lot of these hacks in JS, I removed a lot of them over time... So we wouldn't save a lot, while increasing the number of cached files exponentially, just as in the CSS cache folder. (Well, not that much actually... CSS cache has many more files to begin with, with multiple skins and all that...)

So, err... Worth it or not..?

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 19th, 2013, 07:52 AM

If nobody chips in, then no one has the right to complain about my decisions to come. All right...?

Title: Re: IE 6/7 + mini-menus = headache
Post by: ziycon on April 19th, 2013, 05:21 PM

Something to keep in mind is that IE6 has less then 1% market share and IE7 has between 6-9% market share depending which source you use. From April next year XP is no longer supported so I can foresee a major drop in the usage of IE8 and below due to the fact that Windows 7 only supports IE9+.

If you take this into consideration with the release date you have in mind for wedge(if you've even thought about a release date yet) you can make a much better informed decision as to whether or not you'll even need to support IE8 and below for the release of wedge.

Title: Re: IE 6/7 + mini-menus = headache
Post by: Nao on April 19th, 2013, 07:12 PM

Quote from ziycon on April 19th, 2013, 05:21 PM

Something to keep in mind is that IE6 has less then 1% market share

No, it has 6 to 7% market share, and hasn't evolved much in the last year...
However, over half of its users are located in Asia (including a whopping 25% market share in China...), and this isn't our primary target, so it's less of a concern for us.

Quote

and IE7 has between 6-9% market share depending which source you use.

It's always the same problem: it's hard to determine what source is best... Some will tell you that 'unique visitors' are better because page caching doesn't impact these. (The sillier the browser, the more likely it is to reload a page from the web when clicking the Back button, instead of just fetching it from the cache and thus not generating an extra hit on the remote server, meh... Problem is, I don't know which browser is sillier in that respect, and maybe it's not IE... :lol:)

Quote

From April next year XP is no longer supported so I can foresee a major drop in the usage of IE8 and below due to the fact that Windows 7 only supports IE9+.

It doesn't work like that...
Sure, we might get more upgrades from corporate users. But nowadays, most IE6 users are people who don't have a CLUE about what a browser is, their PC is a zombie filled with spyware, and they think their machine has gotten so slow because 'it's a few years old'... No, PCs don't get slower, as long as you clean them up from time to time.

Anyway, I don't think that there's a good reason to prevent our computer-impaired senior users from browsing a Wedge-based forum where they might be finding the exact information they needed to find.

Quote

If you take this into consideration with the release date you have in mind for wedge(if you've even thought about a release date yet) you can make a much better informed decision as to whether or not you'll even need to support IE8 and below for the release of wedge.

Our original plan was to release Wedge in early 2011, but... Obviously that didn't happen, did it..? ;) Thankfully, it finally was out in 2012. Wait, something's wrong... Okay, it's released when it's ready™, but honestly it'll never be ready... So, Pete and I will instead have to decide at some point whether Wedge is in a 'distributable state', after which we'll release it, and keep improving it after that.