OFFICIAL "SERVER PROBLEMS" THREAD

[Madpoo]

Originally Posted by Mark Rose

My only complaint would be the huge fonts (went from 11.9 pt to 16.4 pt). If the font size is to stay, I'd switch to serif font like Georgia, which is easier to read at large sizes. Otherwise I'm indifferent.

The new menus are easier to use on my phone, but it's not obvious they're a menu. As to how to best achieve that, I don't know. I'm not a UX guy :)

Good point... mobile browsers. Hmm... yeah since the menus are using a hover-over flyout, that won't work on a feature phone as well since you have to actually click on the thing to get the flyout.

I just looked again on my Chrome for Android and it does indeed "fly out" if you click on the item on the left, but I wonder what would be a good clue that you can do that. See, I know I can because I've been staring at it for a couple days, but how to let the new pair of eyes coming to the site realize they can do that. A desktop user is likely to mouse over those things and see the sub-menus, but would a mobile user know? Good question.

[Mark Rose]

Originally Posted by Madpoo

The default font size for the normal text *should* all be 12pt, and a boring "font-family: Tahoma, Arial, Helvetica, sans-serif;"

If you're seeing a larger font size for the regular text, like 16.4, that seems weird. :) If you're able to check using the Chrome inspect element tools, I'd be curious to see where it thinks it's inheriting a larger font size from.

Okay, part of it is my fault, accidentally having chrome zoomed in to 110%

I'm now seeing a font size of 12 pt. The old font size was 10 pt.

I do agree with removing the font tags. :) There's still a couple in the footer wrapping the page render time.

[Madpoo]

Originally Posted by srow7

can you put back UTC time
dont care where

Done! I put it back underneath the "not Mersenne" photo, similar to where it is on the old layout.

[Madpoo]

Originally Posted by Mark Rose

Okay, part of it is my fault, accidentally having chrome zoomed in to 110%

I'm now seeing a font size of 12 pt. The old font size was 10 pt.

I do agree with removing the font tags. :) There's still a couple in the footer wrapping the page render time.

Yeah, there's some other old elements to clean out, especially with some tables and what not. My goal is to have it pass (more or less) an HTML5 validation check.

And you're right, the old default font size was 10pt. Hmm... I don't remember why I changed that. I had a reason I'm sure. Something about trying to match the sizes of the existing home page as a baseline. When it was 10pt like before, it just looked weird, like something was happening to all the other sizes where they looked smaller than they should have.

Long term there's no reason the font sizes on any new pages couldn't be changed but I was focused on fixing up the layout and not so much the main content so I was trying to get them to match as nearly as possible. :)

[Madpoo]

Originally Posted by Mark Rose

Okay, part of it is my fault, accidentally having chrome zoomed in to 110%

I'm now seeing a font size of 12 pt. The old font size was 10 pt.

I do agree with removing the font tags. :) There's still a couple in the footer wrapping the page render time.

Cleaned up some. I set the default font back to 10pt but for whatever mystery of CSS, on the current page I *see* 12pt for the text even though it sure seems like it should be 10pt. I set it to 12pt on the mock page anyway.

I also added some little arrows to the flyout menu to suggest, hey, that really is a menu hiding in there.

And finally I stuck the Google Translate thing way down in the footer. Although I *think* the plugin suggests translating if the browser language doesn't match "en", kind of like Chrome does by default if browser lang != page lang. But I have no interest in changing my browser language just to try it out. :)

EDIT: Oh, and I cleaned up a few other old things, and it now passes HTML5 validation except for the "PICS-Label" meta-equiv tags, but apparently that's a known problem with the w3.org validator. I'm leaving the doctype to html4 transitional/loose because if this ever goes live, there are many other pages to fix up, but that's one of the goals.

[retina]

Originally Posted by Madpoo

Cleaned up some.

I still get the grey space in my face. For the home page it doesn't matter that all the old news is pushed down but for other pages it would be very disturbing.

[Madpoo]

Originally Posted by retina

I still get the grey space in my face. For the home page it doesn't matter that all the old news is pushed down but for other pages it would be very disturbing.

What browser and version (and OS) are you using?

I can tell from your screenshot that it's an issue with alignment of the various divs, and odds are it's that thing I mentioned with the padding/borders and varying support for the "box-sizing" style.

I'd hate to put in browser specific "fixes" :) I'd even say I could loosen up the alignment a bit, but that screenshot shows stuff pretty far out of whack.

For instance, the 2 images in the top left (our good friend Clark Griswold and 2^p-1) combined are 160px wide (80px each), plus that whole top header has a 1px border on all sides, so let's just call that image portion 161px wide.

The overall width is set to a fixed 1000px, and so in order to get that left hand nav to fit directly underneath those 2 images (which is how it *should* look), it's set to float left with a width of 16.1% (161px).

The side nav has a 4px left/right padding and 1px left/right border. If your browser is ignoring the box-sizing instruction, then it's adding the padding and borders *outside* the div, resulting in 161 + 4 + 4 + 1 +1 = 171px.

And I'd say as a guess from your screenshot, it does look like the side nav juts out past the width of those images by 10 pixels.

The main body section is set to float right with a width of 83.9% and it has 1px borders all the way around and 2px padding all around. That'll bump it's left-right width by an extra 6px if it's ignoring the box-sizing, so instead of a nice 839px wide it's out to 845px.

Either way, the browser won't render them side-by-side since the 2 sections together won't fit into the 1000px width ( plus the header's own 2px extra for it's borders), so it cascades them instead. Boo.

I suppose a quick fix is to add extra padding to the top nav, just on the right side, so it *also* extends the same total width of what the two lower panes do, which is 1016px instead of the current 1002px it has (forgive me if I lost anyone along the way).

The footer is also set at 100% width and has 4px padding on the right and 1px border on the right (none on the left...why'd I do that?). So it would bump to 1005px. It's set to float right so it should still align on that side. But it's the footer and it's meant to be below everything so it's in no danger of doing anything too weird besides just not lining up like I meant it to.

(Speaking of footer, I did have it just under the content (83.9%) but with the old expanding menus, on some pages if all the menus were expanded they actually extend further down than the main content, and the footer looked odd. With flyout menus I can change that and have it align directly under the main content and not have that little "stub" on the left.)

I'll do some testing on my beta page to fiddle with the width of that header and if it doesn't break the way it *should* look normally, I can update the mock page and have you try again.

[Mark Rose]

Originally Posted by Madpoo

The side nav has a 4px left/right padding and 1px left/right border. If your browser is ignoring the box-sizing instruction, then it's adding the padding and borders *outside* the div, resulting in 161 + 4 + 4 + 1 +1 = 171px.

That's the standard box model behaviour... why not use it? Unless you're worried about supporting IE 5.5 ;)

[Madpoo]

Originally Posted by Mark Rose

That's the standard box model behaviour... why not use it? Unless you're worried about supporting IE 5.5 ;)

I could, but it was driving me nuts since I hadn't nailed down borders and padding and then having to adjust the div widths each time something changed.

Besides, "box-sizing: border-box;" behavior makes SO much more sense to me. I'm new at all this so I'm coming in from a fresh perspective without any history of how it used to work. So in *my* brain if I'm adding a border, for example, I'm expecting it to use some of the existing space of my box. But that's me. I was a little surprised to learn that it doesn't work like that. I mean, how confusing. :)

Although this is my first dabble at doing this work by myself, I'll add that I actually have dealt with this issue before. The place I work has a number of international websites, and the top menu items would be translated into different languages.

The way the devs setup the tabbed menu, if a translation was extra long (I'm looking at you, German language!) it threw off all the spacing and here I am, the server admin just trying to deploy this and make it work, so I'd tweak a view widths until it all fit. Trouble was, the devs QA team only tested the English version so they didn't see the problems I saw. :)

So for me, it makes sense to design your layout once and then later on if you decide, hey, I want a thicker border, or the padding on this box could be a little tighter, then just do it and not have to worry about adjusting a dozen other things.

[retina]

Originally Posted by Madpoo

What browser and version (and OS) are you using?

FF 3.6.28

And, no, I don't want to upgrade just to view mersenne,org without the grey box. Every other website I regularly visit doesn't have this trouble. Maybe don't try to make it all such a tight fit, allow some gaps here and there to accommodate things more loosely? Why fixed at 1000px width? Not everyone has their window set that wide. Allow the width of the right side box to be variable and fill out the rest of browser window.

[Mark Rose]

Originally Posted by Madpoo

I could, but it was driving me nuts since I hadn't nailed down borders and padding and then having to adjust the div widths each time something changed.

Besides, "box-sizing: border-box;" behavior makes SO much more sense to me. I'm new at all this so I'm coming in from a fresh perspective without any history of how it used to work. So in *my* brain if I'm adding a border, for example, I'm expecting it to use some of the existing space of my box. But that's me. I was a little surprised to learn that it doesn't work like that. I mean, how confusing. :)

Although this is my first dabble at doing this work by myself, I'll add that I actually have dealt with this issue before. The place I work has a number of international websites, and the top menu items would be translated into different languages.

The way the devs setup the tabbed menu, if a translation was extra long (I'm looking at you, German language!) it threw off all the spacing and here I am, the server admin just trying to deploy this and make it work, so I'd tweak a view widths until it all fit. Trouble was, the devs QA team only tested the English version so they didn't see the problems I saw. :)

So for me, it makes sense to design your layout once and then later on if you decide, hey, I want a thicker border, or the padding on this box could be a little tighter, then just do it and not have to worry about adjusting a dozen other things.

Well, it's a matter of which things you want to adjust: the things inside the box or outside the box!

When you think about a bunch of dynamic width content, yes, having the box stay the same size makes sense at first glance. But then consider a picture or other item with a natural fixed width: should the picture shrink or overflow when a border or margin is added? Also, margin on two elements can overlap, and that could get really confusing when elements become narrower when they have overlapping margin. The way they've done it makes the most sense, as much as it's not obvious at first. It took me a bit to wrap my head around it, too.

I'm so glad I haven't had to deal with CSS in over three years now. Our guys have to deal with multiple languages, including right-to-left languages, desktop, mobile, and integrate with customer CSS on hundreds of different sites. I'm impressed it works as seamlessly as it does. We've also had a multi-lingual issue make it by QA before, too. It happens. But we have a rule that no deployments happen after 3 pm, or noon the day before a day off, so whoever wrote broken code is around to deal with it. We'll hold a release until the next work day if past the deadline. It's a system that works well for us.