I was thinking about this....

Shouldn't left and right navigation div be wrapped in a parent div ?
The parent div then gets the: "left: 10em; position: absolute; top: 2.5em;" styling.

The "width detection routine" that also collapses the tabs etc, could then find when there are no more collapsible elements to push away, and then set "min-width" on this new parent element. This would then prevent the content being pushed into eachother, and scrollbars will be needed in the browser window.

<div style="position:absolute;top:2.5em:width:100%;min-width:45em">

<div id="left-navigation"> position:absolute;left:10em; (no top)

<div id="right-navigation"> no margin-top

</div>

min-width would have to have a default value, and can then be "adapted" by the collapsible code. Tested this with Safari 4 and it worked really well. But needs crossbrowser testing of course.

Created attachment 7704
avoid collision of tabs

This patch avoids that Vector header tabs collide and thus overlap and become inaccessible.

• When collapsible tabs JS is enabled, the value of min-width of div#top-navigation should be changed to 41em.
• Should work for all modern browsers https://developer.mozilla.org/en/CSS/min-width
• Does not account for added portlet links that are forced visible (think Twinkle menu, or portlets added when collapsibletabs are not enabled)
• Does not account for an enlarged Search field.
• p-personal will run "underneath" the tabs on small windows.

I consider this solution imperfect because of the last three points, but at least it will improve Vector on the iphone from the current situation.

attachment headercollission.patch ignored as obsolete

(In reply to comment #3)

Created attachment 7704 [details]
avoid collision of tabs

This patch avoids that Vector header tabs collide and thus overlap and become
inaccessible.

Thanks for this patch. Tagging need-review and calling on Trevor to review it.

attachment headercollission.patch ignored as obsolete

All the patch does is assume 44em will be enough space for the tabs to be rendered. In some languages this will be more than needed, resulting in a horizontal scroll bar prematurely, while in some languages it still may not be enough space. This problem exists, but this patch is not a viable solution.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

Marking as reviewed. Per comment #5

• Bug 21297 has been marked as a duplicate of this bug. ***

I'll try working on this, but no promises. The code around this is *awful*.

Related bug: bug 44385.

[Removing 'patch' keyword as the patch has been proven non-viable.]

Partial fix: Iedaebefc (core) & Ie34dce9a (Vector ext.).

With these two, instead of overlapping, the "right" navigation will be displayed below the "left" one. It might overlap page's title, but this is better than rendering critical functions unreachable.

• Bug 29333 has been marked as a duplicate of this bug. ***

I'm not sure what devices you see this as being a problem for. When does the window become this narrow? Also if the screen IS narrow. Is the problem a far bigger one then a case of stopping the menus overlapping?

My investigations show that the menu's only overlap (on enwiki) when a desktop screen resolution is below 659px. This will fluctuate on other language projects I'd be surprised if the numbers vary that much.

On mobile and tablets this less of a problem as they also have a viewport resolution.

Are we saying we want to support < 800px width screen resolutions?

According to http://webdev-il.blogspot.com/2011/04/mobile-web-design-viewport-size-vs.html

I tried various mobile devices - opera mobile, iphone, ipad, android browser and IE7 mobile and none of them had a problem with the Vector skin.

So I repeat - please be clearer. What do we see as being the exact problem here?

Bit of my message got clipped:

.... According to
http://webdev-il.blogspot.com/2011/04/mobile-web-design-viewport-size-vs.html the viewport size only goes below this for IE Mobile browsers. Although I was unable to check this, this article claims it has a viewport of 320px and I figure rendering at that width is a far bigger problem then fixing the menus!
...

(In reply to comment #13)

I'm not sure what devices you see this as being a problem for. When does the
window become this narrow? Also if the screen IS narrow. Is the problem a far
bigger one then a case of stopping the menus overlapping?

My investigations show that the menu's only overlap (on enwiki) when a
desktop
screen resolution is below 659px. This will fluctuate on other language
projects I'd be surprised if the numbers vary that much.

If the Vector extension is not installed (or JS disabled), it starts overlapping at 696px for me, and it's much quicker in other languages (779px in Polish, for example). English is in my experience one of the tersest Latin-alphabet-using languages out there.

Are we saying we want to support < 800px width screen resolutions?

Sort of; we certainly want them to degrade gracefully, especially if it has no cost otherwise. Obstructing clickable links is not graceful; shifting the layout slightly is.

Do we have any data on how many people are effected by this or could we collect some data via EventLogging? It would be great to understand the extent of this problem some more. I'm curious to how many < 800px width screen resolutions there are out there in the wild using Wikipedia and what browser they are using.

(In reply to comment #16)

Do we have any data on how many people are effected by this or could we
collect some data via EventLogging?

Probably not many, and you probably could (but it's not an unreasonable assumption that such machines could have JS disabled, skewing your counts).

Personally I can say that this has been annoying me when I intentionally opened Wikipedia in a small window, for example to view several articles side-by-side.

• Bug 52233 has been marked as a duplicate of this bug. ***

The patch at Iedaebefc is still not merged after over half a year, by the way.

Change 45944 merged by TheDJ:
vector: Move right tabs from behind to below left tabs

https://gerrit.wikimedia.org/r/45944

Created attachment 13041
Tabs' behavior after Iedaebefc was merged

This is mostly fixed now (see screenshot in attachment), so I'm closing this bug. Further improvements would be lovely, but the immediate issue is fixed.

Attached:

• Bug 53630 has been marked as a duplicate of this bug. ***