Bug 638726
|
Description
Felix Miata
2010-09-29 18:43:48 UTC
we have the problem with tables being too wide for the window quite regularly in the wiki. I can't see any legitimate reason for suppressing the horizontal scrollbar. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers @Felix (In reply to comment #0) I understand your frustration. In order to better assist and make sure any changes made would resolve the issue, could you provide the following info regarding when viewing that page: - Operating System - Screen resolution - Browser(s) Since that's a global stylesheet a generic change would skew other parts of many Fedora sites and we'd like to be sure that things still work properly. Thanks. @Adam (In reply to comment #1) This has been mentioned before. The first attempt in fixing this we broke plenty of tables and the footer and had to revert the change. We'll go ahead and revisit this. (In reply to comment #2) > - Operating System More than 40 unique flavors of Linux, plus various Microsoft & IBM operating systems, and one Tiger. Among them, Cooker, Factory & Rawhide. > - Screen resolution Most up to 2560x1600 except for miniatures/handhelds, but rarely less than 1280x960, usually 1400x1050, 1600x1200, 1856x1392 or 1920x1080. > - Browser(s) Konq, Epiphany, SeaMonkey, Opera, Chrome, IE, Firefox, Safari & others in both recent and devel versions. Additional notes: 1-Fedora sites are hardly unique in having this problem. Respectfully designed web sites are extraordinarily rare. Most web styles and stylists are corrupted by print design characteristics that don't apply to pages designed to embrace the web's inherent advantages over traditional mediums (e.g. accommodation, adaptability). 2-all questions and answers above are orthagonal to the issue. Properly designed web pages work well without regard to operating system, browser, or screen resolution. 3- http://sperling.com/four-things-clients-should-know.php (In reply to comment #4) > (In reply to comment #2) > > - Operating System > > More than 40 unique flavors of Linux, plus various Microsoft & IBM operating > systems, and one Tiger. Among them, Cooker, Factory & Rawhide. > > > - Screen resolution > > Most up to 2560x1600 except for miniatures/handhelds, but rarely less than > 1280x960, usually 1400x1050, 1600x1200, 1856x1392 or 1920x1080. > > > - Browser(s) > > Konq, Epiphany, SeaMonkey, Opera, Chrome, IE, Firefox, Safari & others in both > recent and devel versions. > FWIW, I fit into the above description and the text seems fine. Did you perhaps hold down the control button while using the scroll wheel at one point? It's amazing to me that trying 40 flavors of linux * 6 different screen resolutions * 7 different browsers (wow, did you really test this page view 1,680 times?) and they all produced text that was too small. I only tested it once at 1600x1200, in Fedora 13, in Firefox 3.6.10 and really the text seems normal and easy to read. Created attachment 450806 [details] screenshot on 144 DPI system (In reply to comment #5) > Did you > perhaps hold down the control button while using the scroll wheel at one point? The (24/7) system from which this screenshot was made has no scroll wheel on its Trackman Marble FX. > I only tested it once at 1600x1200, in Fedora 13, in Firefox 3.6.10 and really > the text seems normal and easy to read. "Normal" means different things to different people. To me, normal text size means my browser's default text size. In this screenshot, the bulk of glyphs showing on the Fedora page are considerably smaller than my 12pt (24px) default. This screenshot was made without having made any Firefox preferences changes in at least a week. I bumped the SeaMonkey minimum font size preference down from 20 to 18 to match the Firefox setting just for this screenshot. Firefox was opened 2010/09/27 22:47 (-0400). No DTE font settings for this login have been changed since the last system upgrade some months ago. Created attachment 450827 [details] screenshot on 120 DPI system setup URL: http://fm.no-ip.com/Tmp/sc-redhatb638726.html No zoom applied here either, just 15px minimum, and still no horizontal scrollbar in Firefox. Dunno why I'm CC'ed here, but after looking at the initial complaint and screen- shots, I'll add my two cents worth: I don't care how much text you feel the need to present, if you have to size it at 8pt or smaller, you're committing a gross and quite basic rule of page design. Jakob (useit.com) has talked about this for over a decade. If you have to make paragraph (not annotation, footnote, etc) text 8pt. to make it all fit, make do with less, or chunk up your information into paged segments. It's not hard to do so. Web Design 101 IMNERHO. Folks: Thank you for your opinions on the matter. What we need now are actual fixes to the CSS, tested against the places the CSS uses to make sure it solves the ongoing problem here without causing a regression elsewhere. You can learn how to get a checkout of the website so you can work on the CSS to generate patches. I suppose we should keep the patches coming to this bug report? Any code with questions could be sent to the Websites team mailing list. http://fedoraproject.org/wiki/Websites/ShowUs I want to remind everyone that the Fedora Websites team is a group of volunteer contributors in charge of a disperse set of websites. It's been acknowledged that this is an ongoing known issue and previous attempts to solve it have caused regressions. If the team could have solved the problem by now, they would have. That means that from here, we need less opining and more patching. Since it sounds like we have some people here with specific ideas and the experience/know-how to back that up, it will be most helpful from here forward if we focus on specific suggestions and patches to fix the problem without causing regression elsewhere. (In reply to comment #6) > > "Normal" means different things to different people. To me, normal text size > means my browser's default text size. In this screenshot, the bulk of glyphs > showing on the Fedora page are considerably smaller than my 12pt (24px) > default. I'm wondering if it's possible for you to locally create and test fixes? Are the CSS rules applied to too many places to isolate out this part? Or is this problem mainly in the wiki, and we can focus on carving out a bit of CSS just for the wiki to solve this? If the latter is the case, can Felix run a local MediaWiki + our packages + CSS checkout to be able to test fixes? > This screenshot was made without having made any Firefox preferences changes in > at least a week. I bumped the SeaMonkey minimum font size preference down from > 20 to 18 to match the Firefox setting just for this screenshot. Firefox was > opened 2010/09/27 22:47 (-0400). No DTE font settings for this login have been > changed since the last system upgrade some months ago. Do the 1600+ permutations of distro/resolution/browser mainly mean, "I have seen this problem on every permutation I have been on"? If yes, can we agree upon a specific distro version/resolution/browser, or at least a reasonable subset that you and others are going to test on? Created attachment 450942 [details] screenshot on 96 DPI system setup URL: http://fm.no-ip.com/Tmp/sc-redhatb638726.html No zoom applied here either, just 13px minimum (which here at least is not necessary to reproduce), along with the upstream 16px proportional default, and still no horizontal scrollbar in Firefox. Here @ 96 DPI, 13px equals 10pt, the recommended minimum size by usability professional Jakob Nielsen. http://www.useit.com/alertbox/20020819.html (In reply to comment #10) > Do the 1600+ permutations of distro/resolution/browser mainly mean, "I have > seen this problem on every permutation I have been on"? Essentially, yes. It is very easy to reproduce. Because I always find minimum size necessary, I have to go out of my way to not reproduce the (in the immediate case) scrollbar-less 5 hidden/10 visible table columns on https://fedoraproject.org/wiki/Test_Day:2010-09-29_Radeon On both this screenshot's 1280x800 system and the 1856x1392 system shown in attachment 450806 [details] I have to zoom minus 3 times to make all 15 columns visible, at which point the largest text in the big table is at most 2/3 the size of my 10pt DTE UI text, maybe half as big as the browser's default (~6pt). cf. http://fm.no-ip.com/PC/displays.xhtml which has 27 columns, requests a narrow font-family at the browsers default size, and displays as many as all 27 columns without need for horizontal scroll, plus allows the browser to provide a horizontal scrollbar if necessary to reach all columns. (In reply to comment #10) > If yes, can we agree > upon a specific distro version/resolution/browser, or at least a reasonable > subset that you and others are going to test on? Proper web designs do not depend on assumptions that are not generally applicable. This means any sane combination of browser default size, viewport size, and actual physical screen DPI should produce acceptable results on pages using a 1em (100%) base font-size. For a portrait mode handheld device I doubt any sane method of displaying such a wide table exists. In all other cases, it should be good enough to test on any system with a browser default matching the 12pt computer display text size most commonly favored by ordinary users and recommended by usability and accessibility experts. 23" 1080p HDTV (96 DPI actual), 15.4" WXGA laptop (98 DPI actual) and 21" WSXGA+ desktop (94 DPI actual) displays are among those that can, with all upstream defaults left in place, be used to do this. (In reply to comment #10) > I'm wondering if it's possible for you to locally create and test fixes? > Are the CSS rules applied to too many places to isolate out this part? > Or is this problem mainly in the wiki, and we can focus on carving out a bit of > CSS just for the wiki to solve this? Total CSS called by the Radeon test day page, including print-specific, is about 80k spread across 8 files. To me, that is an unworkably large amount of CSS for any single person to competently manage, and worse for disparate members of any group. Long term, a policy needs to be adopted, an oversight/test team formulated, and a competent professional web developer hired to perform a complete overhaul designed for maintenance either via CMS used by selected, qualified volunteers, or via some manner of retention of the professional web developer. Short term: > If the latter is the case, can Felix run a local MediaWiki + our packages + CSS > checkout to be able to test fixes? I doubt anyone lacking considerable time to contribute can solve the immediate problem without causing unwanted impacts. The existing CSS more complex than I could hope to deal with in the time I estimate it would take even to attempt in the foreseeable future. Certainly I could sample work on a test site hosted by and worked on by others, but little else any time soon. > > Total CSS called by the Radeon test day page, including print-specific, is > about 80k spread across 8 files. To me, that is an unworkably large amount of > CSS for any single person to competently manage, and worse for disparate > members of any group. Despite your opinion here, the Websites team has been doing a fine job of handling all that. I'm sure they agree it is overly complex, but they are not running away from the problem. There is a single problem here that is hard to solve. You are conflating that in to a Big Huge Dramatic Problem and are being deeply insulting to the people who are actually doing the work you are benefiting from. Please stop doing that. > Long term, a policy needs to be adopted, an oversight/test team formulated, and > a competent professional web developer hired to perform a complete overhaul > designed for maintenance either via CMS used by selected, qualified volunteers, > or via some manner of retention of the professional web developer. You are showing a prejudice of some kind here, I'm not sure what it is. Despite your opinion on the matter, a competent team of volunteer amateur and professional web developers have worked the large Fedora web properties up to what they are. Which work very well, for the most part. Yes, we all agree there are problems with the CSS -- complexity, etc. I have full confidence that the team is capable and interested in solving that. Otherwise, I'm shocked at your non-open source methods and recommendations about how the team should approach this. As a comparison, the fact there are a large number of paid developers who work on the Linux kernel today isn't a testament to the idea that Linus Torvalds was helpless without all that paid professional help. Rather, those paid developers are there and not somewhere else because the Linux kernel model worked so well before they even got there. In fact, bringing Big Paid Developer Team attitude to kernel submissions is pretty guaranteed to not work -- just ask IBM, et al. http://video.linuxfoundation.org/video/1709 > I doubt anyone lacking considerable time to contribute can solve the immediate > problem without causing unwanted impacts. The existing CSS more complex than I > could hope to deal with in the time I estimate it would take even to attempt in > the foreseeable future. Certainly I could sample work on a test site hosted by > and worked on by others, but little else any time soon. Your persistence in getting this problem solved is commendable and I'm not interested in turning away your help. Until there is a test site someone else sets up and you can test on it, would you be kind enough to tone down the hyperbole and insults? (In reply to comment #14) > You are showing a prejudice of some kind here Definitely. I'm anti-disrespect as a web standard. The web is rude, and attempts to advocate respect in web design, such as this bug, usually get dismissed. http://fm.no-ip.com/Auth/rudeweb.html Created attachment 657934 [details]
contextual docs.fedoraproject.org 120 DPI screenshot
Created attachment 657935 [details]
contextual boot.fedoraproject.org 144 DPI screenshot
Created attachment 657936 [details]
contextual fedoraproject.org/wiki/FAQ 144 DPI screenshot
Created attachment 1562240 [details] 132 DPI F30/Plasma desktop with fedoraproject.org wiki pages loaded in Firefox 45 The mousetype UI in SeaMonkey is due to bug 1420743. GTK3 Firefox releases suffer same problem, which is why this was made with FF45 (built with GTK2). The websites team does not maintain the wiki. If this is still a problem, you can file a ticket with the infrastructure team: https://pagure.io/fedora-infrastructure/issues |