Clickable tabs overlap for small screen resolutions
Closed, ResolvedPublic

bzimport set Reference to bz20234.
bzimport created this task.Via LegacyAug 14 2009, 7:38 AM
TheDJ added a comment.Via ConduitMay 14 2010, 1:34 AM

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.

TheDJ added a comment.Via ConduitMay 14 2010, 10:01 AM

<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.

TheDJ added a comment.Via ConduitSep 26 2010, 2:57 PM

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

Catrope added a comment.Via ConduitSep 27 2010, 8:41 AM

(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

TrevorParscal added a comment.Via ConduitSep 27 2010, 9:22 PM

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.

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

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

bzimport added a comment.Via ConduitAug 19 2011, 7:12 PM

mhershberger wrote:

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

rmoen added a comment.Via ConduitJan 14 2012, 12:59 AM

Marking as reviewed. Per comment #5

Aklapper added a comment.Via ConduitDec 15 2012, 10:52 AM
  • Bug 21297 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitJan 26 2013, 4:17 PM

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.]

matmarex added a comment.Via ConduitJan 26 2013, 4:26 PM

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.

matmarex added a comment.Via ConduitFeb 6 2013, 9:15 AM
  • Bug 29333 has been marked as a duplicate of this bug. ***
Jdlrobson added a comment.Via ConduitJun 6 2013, 8:45 PM

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?

Jdlrobson added a comment.Via ConduitJun 6 2013, 8:48 PM

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!
...

matmarex added a comment.Via ConduitJun 8 2013, 8:01 PM

(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.

Jdlrobson added a comment.Via ConduitJun 8 2013, 8:11 PM

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.

matmarex added a comment.Via ConduitJun 8 2013, 8:29 PM

(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.

matmarex added a comment.Via ConduitJul 29 2013, 6:02 PM
  • Bug 52233 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitJul 29 2013, 6:03 PM

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

gerritbot added a comment.Via ConduitJul 31 2013, 9:02 PM

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

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

matmarex added a comment.Via ConduitJul 31 2013, 10:08 PM

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:

matmarex added a comment.Via ConduitSep 1 2013, 9:05 AM
  • Bug 53630 has been marked as a duplicate of this bug. ***

Add Comment