Nao

  • Dadman with a boy
  • Posts: 16,080
Sidebar emulation method in IE6/7
« on September 19th, 2012, 02:48 PM »
These days I've been going through the skin files and trying to simplify some stuff. To little avail, though... It's still kind of messy.
Still, I've been thinking about the sidebar system (cf. my talk with Emanuele), and was reminded of two things:
- the macro system is really powerful and great,
- it's totally going to confuse themers.

Well, to be honest with my greatness, it's not that hard to understand: <we:sidebar> holds the sidebar code, <we:offside> has the main content, etc... And 'sidebar' is defined in the index template, as well as in <skeleton> tags in sub-skins. So far, so good.

Now, I've always considered Weaving to be a skin that really, really should require as little 'hacking' as possible.
In Wedge, by default, the sidebar has two different codebases:
- IE6/IE7 use a table-based layout (<table> tags)
- Other browsers use table emulation (<div> tags with display:table on them)

It's okay because it explains how flexible the system is.
Now, if we delve into sub-skins, the skeleton is modified. When it comes to Warm, it's okay that it's modified because the sidebar position really is quite removed from the original layout. It's a great example of what you can do with careful planning.
But in Wine, the skeleton is modified so that the sidebar can be shown on the LEFT of the screen instead of the right. It's just an example, of course -- but it's still completely silly to change the HTML for what can be done in CSS.

Well, in my defense, back then I didn't know that table cells could be swapped with CSS. I learned about that some time ago, that you just need to apply 'direction: rtl' to the parent display: table, and 'direction: ltr' to its children. And it works perfectly. Despite it being a 'dirty hack', it's still extremely simple to apply and even to understand -- and it has the added benefit of leaving the sidebar contents where it belongs, i.e. at the end of the HTML source. (Heck, I'm even considering pushing the menu into a display:table of its own, and using display:table-header-group to move it to the top regardless of its position in the source...)

Okay, so far so good. I'm definitely doing that. I only need to redefine the skeleton once (in Warm), and Wine is left alone. Consider it an 'announcement' of a change I'll commit soon. What matters right now is IE 6/7.

Now, when it comes to them, doing table-based layout is cooler in my opinion, but a more realistic way of handling them would be to instead use the negative margin hack to show the sidebar correctly. i.e., by putting a negative right margin on the main contents and a positive right margin that compensates for it right in the first nested div, I can easily put a right-floated sidebar on the right. It's a proven method, and has no drawbacks -- except that it's not a proper 'column' that shows up, instead just a floated sidebar, meaning that if you set a background color on the sidebar, it only extends as far as the sidebar contents will extends, rather than filling the entire sidebar.
It's a well known problem.
It can also be fixed by using faux columns or other alternative tweaks for IE that are also well documented. But it just adds to the bloat and limits extensibility.

So... Here's my question, basically (and as TL:DR).

When it comes to IE6/IE7 compatibility, what would you prefer to have by default in the skins provided in Wedge?

1/ What exists right now, i.e. the <div>s are replaced on-the-fly to simple <table> tags for IE6/7 only?
2/ A simple CSS float hack that positions the sidebar <div> correctly but doesn't extend the sidebar to the full height?
3/ A complicated CSS hack that positions the sidebar <div> correctly and extends the sidebar just like (1) would do?
4/ Like (3), but applied to all browsers, instead of using the more logical 'display: table' setting? (<-- don't bother, that one's just troll bait :P)

As a reminder - none of these change anything for non-IE browsers. They will *always* use <div> tags. Also, I'm still considering the possibility of allowing for the sidebar to be removed (possibly to be replaced by a single-line fallback for mini-links like the time of day and Unread posts/replies.)

So... Please start discussing :)

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Thank you,
Boko

Nao

  • Dadman with a boy
  • Posts: 16,080

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Sidebar emulation method in IE6/7
« Reply #4, on September 20th, 2012, 12:00 AM »
Solution 2 could ne applied to all browsers but we lose the sidebar effects.

Solution 3 implies additional hacks for various bugs in several ie versions. Never said it was gonna be easy ;)

Semantically, solution 1 is the least hacking. Which is why I used it in the first place. But I want Weaving to be easy to modify, hence my concerns about the sidebar code. Of course most themers won't touch the sidebar code anyway...

MultiformeIngegno

  • Posts: 1,337

Nao

  • Dadman with a boy
  • Posts: 16,080

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
The way it's meant to be

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Sidebar emulation method in IE6/7
« Reply #9, on September 20th, 2012, 03:41 PM »
Yes, that's the whole point of the macro system... ;)
Okay then, I'll stick to the original plan I guess. The only change I'll be doing is using the direction:rtl hack to help keep the sidebar HTML after the content HTML.
My only worry was about the fact that themers may find it a bit hard to understand. But OTOH that's really not the kind of place they want to mess with in their first attempts. Also, I could 'simply' get rid of the index template's macro definitions and move them over to Weaving's skin.xml but it would probably make the parsing a bit slower. (Until I decide to cache these...)
Posted: September 20th, 2012, 03:36 PM

Oh... I was in the process of reverting my changes, and completely forgot to say -- the main reason why I wanted to get rid of the table tags for IE6 is that the sidebar can't be moved to the bottom...! Best I can do is to just hide the sidebar, but not move it below... Which is a bit of a bummer. And that's why I tried looking for an alternative that would work.
Re: Sidebar emulation method in IE6/7
« Reply #10, on September 21st, 2012, 05:50 PM »
So, err, in case my post yesterday wasn't clear... I was saying, solution (1) should be amended to say, "the main drawback is that IE 6/7 can't have their sidebar moved to the bottom in case we're in a low resolution."

Should I make a proper poll for this...?
Posted: September 21st, 2012, 09:38 AM

Or... Silly me... I could 'simply' use a 'always below' position for IE6/7... i.e. we still use <div> tags on them, but the sidebar is considered as a block instead of a table-cell, and thus is always moved to the end. We can complete this with a max-width on IE7 to ensure the text doesn't expand too wide compared to other browsers.
Posted: September 21st, 2012, 10:07 AM

Bump! I love bumps. Except on my forehead...

billy2

  • Trying to earn brownie points for a lads trip to the Red Sea. Minus 1 already - just for asking!!
  • Posts: 350
Re: Sidebar emulation method in IE6/7
« Reply #11, on September 22nd, 2012, 09:41 AM »
You should really get a warning from the mods for bumping a less than 24 hr old post.
But I suppose we can let you off :eheh:

<br /><br />cough, cough.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: Sidebar emulation method in IE6/7
« Reply #12, on September 22nd, 2012, 10:51 AM »
It's just that I'm obviously trying to get rid of the old IE compatibility code when it gets in the way of readability for the main Wedge code...
It's really a problem to me because I can't make my mind between readability and the fact that most themers won't touch that area of code anyway. But it's still in index.template.php and thus is something that bothers me a bit. It's quite plain-in-the-face.