patches/fixes are welcome: https://github.com/spring/spring-website

how do I execute them? I want to do more than a css tweak, Can I get admin acess on the wiki on the test server?

logout page looks funny (on springrts.com)

FF 10

• Fork on github
• Set up forked repo locally via W/M/L/XAMPP
• Commit/Push changes after testing
• Issue pull request for merging your version of the site into the official version
• Official repo is deployed to Test subdomain
• If everybody agrees its an improvement, deploy to live site

Its not just the CSS thats in the git repo, its the site in its entirety, phpbb, mediawiki, the custom code, and all the other stuff. See the readme file for the database and phpbb attachment dumps.

that isn't what I need to do.

christ, it isn't a matter of adding a file or tweaking a value..

Then start a new thread, those instructions cover just about everything to do with site development. If it doesn't fit in then your problem is content or moderation/administration, not development.


Also, phpbb needs:

I want to test something against the dev version of the site. Are you saying this thread is NOT for site testing?

thanks, applied. (maybe CTRL+R and/or CTRL+F5 is needed to force reload the stylesheet)

@knorke: fixed by this change

(now, since all errors are gone its time to make a new page! )

using "float:left" is evil and _breaks_ stuff:

• bottom padding is not existing if page is higher than 100%
• menubar is still broken with smallscreen rendering (cause of "float:right")

-> Never use "float:" for inline alignment (except for elements in text), elements with such a tag don't resize their parent elements and break stuff in a lot of ways.

that was a bad joke... float left was the only solution i saw to fix the strange breaking without changing big things that would maybe break much more.

imo biggest problem on this page is, that we use mediawiki and phpbb with the same stylesheets. see http://validator.w3.org/check?uri=http% ... ne&group=0


whats broken on the menubar? imo its fine how it wraps. it looks much uglier with a min-width set and not wrapping.

yeah, indeed bottom padding is not existing.

how it looks like currently:



how it should look like:

Adding:



To the relevant media query corrects the menu issue. I would also add some kind of clearfix to the #wrapper element.

The problem here is that there is no grid system or structured layout in place, and we're dealing with the mishmash of fnordias table foo, my div wrapper changes, and the hodgepokery style changes of 3 or 4 people to try and make things pretty.

dunno, I found float to be awesome if you manage it correctly.

Anyone got problems with the latest rev: http://test.springrts.com/ ?
(except the linebreak one in the community headlines)



I explained why it is evil, you don't have any counter arguments ... (also I don't disapprove it everywhere, just for aligning containers it is the devil himself)

There are some nice improvements in there, particularly in the menu. I don't know about the white text glow but I don't oppose it. I would say for the moment it would be worth looking into making it so that the smaller form of the navigation is what's used when normal sized too.

Also on Chrome 17 the text in the 3 buttons is top aligned now rather than vertically middle aligned.

For anybody making further changes, it would be a good idea to replace the rotating images instead with div containers using the background image to specify the image instead. Then, list all the images in an overflow-x: hidden container so they're aligned in a long row in the container., and randomly picking one via javascript. We could also use nivoslider on the main homepage banner too. This should speed up page times by not reloading the banner every time we load the page, letting the browser cache a lot more stuff, and letting us cache the header itself so it's static.

Smallscreen menu must be different from normal one. You cannot just resize the normal one and say it's fine. smallscreen=smartphone and you rarely have a mouse pointer there instead buttons need to be large enough for your fingers.

fixed

Bad idea, this way the browser would preload all images on first load and so the site gets slower & traffic increases.

The buttons aren't any bigger on the small screen though, the whole point of the bar is not for usability, it's to stop the current style looking horribly broken.

Also right now instead of the browser preloading every image, we have it reloading every image regardless half the time.

1. But it is shared between all opened instances in the browser.
2. Code says each _single_ image is cached and tests circumstantiate that it works. (see ETag)

They are fixed size, while the only possibility to get the `normal` menu for smallscreens too would be to reduce the font-size -> making buttons smaller.

i added as test the wysiwyg extension to the mediawiki. it only shows up, when you login to the wiki + click on "Show RichTextEditor"

http://test.springrts.com/mediawiki/ind ... ction=edit

requested by smoth, forb and some others. ("without i have no desire to write docs").

it seems to be useable, but isn't displayed correctly because of our css changes. so... my suggestion is: wait for feedback and then revert or keep it.

Looked fine to me.. what did it look like for you?