The 14-pixel font size on the new MDC skin is too small. While it looks okay on very large screens, on laptops it's uncomfortable to read. We need to bump it up to maybe 16px.

For me, the computed style of font-size is 12.25px. The main body text is currently set to display at 87.5% the size of the user preferences. https://developer.mozilla.org/skins/mdn/Transitional/css.php:75: body { min-height: 400px; font: .875em/1.286 "Lucida Grande", "Lucida Sans Unicode", Lucida, Arial, Helvetica, sans-serif; margin: 0 auto; color: #333; } .875em should be changed to be no less (and no greater) than 1em.

I agree here; the default base font size of content should never be smaller than what the user's font preference is set to; smaller font sizes should be reserved for very specific cases, such as minor captions and stuff like that. Having the majority of a site's content render smaller than the user's preference can make reading very uncomfortable.

Sheppy has indicated he's happy with the current font-size.

Sizing in px 100% disregards user defaults. That's rude, and unacceptable from a site that should be a leader in best practices. cf. bug 511900 & bug 577317

Hello Felix, Have you seen the new beta MDN site? http://developer-new.mozilla.org We hope to launch Monday. I looked at the new stylesheets and we aren't using px-based font sizes anywhere but a few special circumstances.

http://developer-new.mozilla.org/ redirects to https://developer-new.mozilla.org/, which won't open without adding an exception. Doesn't work for me on the reachable version.

The exception will not be necessary when our new website launches soon. For now, adding the exception is perfectly safe. After adding the exception, take a look at the font size. What do you think?

(In reply to John Karahalis [:openjck] from comment #7) > After adding the exception, take a look at the font size. What do you think? Inane. Note that unless the viewing size is adjusted so that the one inch block measures one inch wide, the image is useful only to show perspective, and is not a realistic view comparable to that seen on a display of the indicated pixel density.

This is what it's likely to look much like on the latest Macbook Pro. Again note that unless the viewing size is adjusted so that the one inch block measures one inch wide, the image is useful only to show perspective, and is not a realistic view comparable to that seen on a display of the indicated pixel density.

Thanks for the screenshot, Felix. I will be sure we look into this.

This will be addressed in the site redesign launching in 2013.

We've launched a beta of the MDN 2013 redesign (instructions to sign up and see the changes are here: https://wiki.mozilla.org/MDN/Development/Redesign/Testing) Is this bug still valid for the new site design?

Font-size of the re-designed MDN docs in a desktop browser with screen resolution of 1366 x 768.

The font-size of the content looks fine and legible. But the font-size of the <code></code> element should be increased to 13px minimum since it looks really small in desktop browser with screen resolution of 1366 x 768.

In the new design, the font-size of <code> element is the body of the article is 14px. Anyway, I think this bug was about the old theme and is likely to be resolved as WONTFIX or WORKFORME now.

anandprabhu, there is no material difference between now and when I previously attached screenshots. My same comments apply. Sizing text and text containers in px is both incompetent and rude. There is no rational excuse for any web pages to initially open with most text a tiny fraction of a desktop's UI text as is shown here, much less technical pages on the subject of web design hosted by a web browser maker.

No material improvement in the new version. Body font size is still rudely set in px @ 49% of my default size. I never did get to see it while in beta due to inability to figure out how to make that new login tool stay visible long enough to use it.

Adding it to the list of bugs for triaging. (Even if it is an old bug)

(In reply to Felix Miata from comment #16) > Created attachment 8338377 [details] > 180 DPI screenshot of > https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Introduction > > anandprabhu, there is no material difference between now and when I > previously attached screenshots. My same comments apply. Sizing text and > text containers in px is both incompetent and rude. (In reply to Felix Miata from comment #17) > No material improvement in the new version. Body font size is still rudely > set in px @ 49% of my default size. I agree with Felix. The very "14-pixel font size on the new MDC skin is too small" comment which initiated this bug report still applies. I see many other issues. 1- the links of the breadcrumb navigation is way too small (12px); it should be "font-size: 100%" instead. 2- there is an insane amount of redefinitions, redeclarations of CSS code: eg. margin-bottom of p elements is declared and redeclared 3 times... when, on the other hand, each and all browsers (IE8+, Chrome, Safari, Opera, Konqueror) use the same vertical margins for <p> elements in their UA style sheet! So, such redefinitions are often, very often unneeded anyway. 3- there are lots of CSS reset, unneeded and unjustified CSS resets: eg html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, hr, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, figure, figcaption, hgroup, menu, footer, header, nav, section, summary, time, mark, audio, video { border: 0px none; } The only elements which have a default border are the iframe element, the fieldset element, the hr element and maybe a few others that I do not know well (like video) and they all have a border for a good reason. I do not understand why you need to zero-reset all these elements instead of using, relying on browser defaults, on user-agent style sheets. You should only zero-reset properties which really need to be reset. Nota bene: Extended support for Windows XP ends on april 2014: that's only 4 months from now. So, after April 8th 2014, there will be no security patches for XP and all its IE browsers: IE6, IE7, IE8. So, I see no reason to try to continue to support (cater for) IE6, IE7 and IE8. It just is not coherent, not logical, not responsible to do so. 4- the font-size of the toggable table of contents for the article is way too small: #toc > ol { font-size: 12px !important; } ... and suddenly, the declaration (in redesign-wiki-min.css) even uses !important for no apparent reasons. 5- emboldening is a technique to help guide the readers, orient the readers, ease the task of the readers. So, if you are going to embold words, then I suggest to do it in "directivist" manner. *not* is not going to direct (or help) readers but *HTML does not describe the style and formatting of content* is clearly going to. Emboldening can be made to attract readers onto the most important ideas of an article. Emboldening words favors eye/reading scannability, helps text skimmability, faster text reading/checking. So best is to use it on the most important propositions, sentences or expressions that you want your article readers to remember. 6- Overall, you really should try to reduce the number of rules, to reduce the number of declarations, to reduce the number of stylesheets, to reduce the number of IE versions to support, to use zero-resets sparingly and only when required and to minimize redeclarations. Otherwise, you are re-creating again an unmanageable monstruous website. CSS was originally designed to reduce the amount of code! 7- "Make sure you are saving it using the character encoding UTF-8." (...) <head> <title>A tiny document</title> </head> One way to make that sure is to include <meta charset="UTF-8">. Most HTML editors (eg BlueFish 2.2.4) will interpret <meta charset="UTF-8"> as a directive to save the document using UTF-8. Furthermore, Firefox's web console (in JS tab, check error) will report an error in that myfirstdoc.html stating that charset has not been declared if/when <meta charset=""> is missing.

(In reply to anandprabhu04 from comment #14) > The font-size of the content looks fine and legible. But the font-size of > the <code></code> element should be increased to 13px minimum since it looks > really small in desktop browser with screen resolution of 1366 x 768. Most of the time, in the article, the <code> elements are nested inside a <pre> which is styled with pre { line-height: 19px !important; font-size: 12px !important; } So, even after increasing default font-size for monospace fonts from 12px (12px is the default in Linux; 13px is the default under Windows) to, say, 16px in Firefox, I still did not benefit from any font-size increase in the article. This isn't the end of the story. This test http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/font-size-code-kbd-samp.html proves that several elements using monospace are not font-size-compatible across browsers. (In reply to Jean-Yves Perrier [:teoli] from comment #15) > In the new design, the font-size of <code> element is the body of the > article is 14px. Jean-Yves, over here, the font-size of <code> element is 12px.

Going to roll this bug into part of a project to review accessibility/readability of the site (will create a master bug). Need to define some experiments we can do on the site to determine what works best for users as far as font size, etc.

This is going into the site usability review.