That file doesn't exist anymore.

If JamaL doesn't have his final version I still have my files at home, they only need a few tweaks to finish em off. (DevliN: I edited my post while you replied if you havnt noticed)

Found it. Extract and enjoy the portal page.

I'll have to redo it slightly due to how 5.1's code works for skins, but it should be a quick fix.

EDIT:
Started to work on it when I got home. This is going to take a while. I've got the header and navbar done (with working mouseover menu), and will get to the other parts later.

Post has been edited 1 time(s), last time on Apr 13 2011, 8:04 am by DevliN.

Standardize the skin and keep it simple

If you have to use little tiny images to make a corner, or have to split an image in halves for some reason, you are doing it wrong.

Half of the problem I had when modding the epic skin was that I didn't know which colors were what. If we can get 2-3 base skins and edit them so that all we need to do is change the css and the images, that will be wonderful. Having a mobile friendly image will be excellent as well. SEN right now is not mobile friendly, my windows phone uses IE 7 I presume. To read anything I have to zoom in. It's not like wikipedia, where everything is already in fairly large text.

Also, aren't we moving to a different system? or are we just going to fix the "bugs" in the current system which IP and Dev coded (mostly)? Whatever happens, it would be nice to supply an offline, "test" SEN where you can test your own skin that you make, or release a page which includes every color used by the css and a description of where it is used.

I'm remaking the entire site in a professional and easy to add onto/modify manner.

For example there will be a "base" html page that all other pages will inherent as if the base html page were a class in OOP. Then after the inheritance in a new html page you can add onto/modify and create an entire page with a unique function. You'll see when it comes out, it's rather elegant.

I will say that despite its flaws, Devourer's 5.1 made it easier to skin SEN and change things like that. I am looking forward to the new system, though.

Thank you, as long as it does what you say, I should be very happy, but I pray we do not lose everything.

Define "everything." As far as I know, we're keeping everything in the mysql database (posts, users, oldwiki, shoutbox?, etc.) but we'll have to redo the skins again.

actual content (not simply graphics) which doesn't include skins (as no skin now is all that great).

Ah, okay. Yeah all the posts, users, etc. are stored in our sql database. That would all be saved.

Yeah there's a lot of documentation on dealing with legacy data in django.

CSS is considerably more limited than you seem to think. Box corners? Default. Rounded corners? Easy. Clipped corners? Time to break out the tiny images. :\

Readable CSS could help with this, as can the use of a consistent color palette. (For example, "post_header_bar" would be a better CSS class than, say, "fphdr".)

I've never done work for mobile pages before, but I would imagine that the main differences would be client-side ones. Support on the server-side shouldn't strictly be necessary (if we use a new system); someone would simply code a skin that works in a mobile browser. (There may also be issues regarding phones and AJAX, but I'm pretty sure Cecil knows to create non-JS/non-AJAX fallbacks for AJAX-based server stuff. If he doesn't, then he will once he reads this -- Cecil, if it can be done with AJAX, it should be do-able without AJAX as well.)

IIRC Cecil has something in mind regarding offline testing for skin code in his proposed new system. Not sure, though.

There are tricks you can do with CSS, though. (This is not a solution specifically for the problem presented; it's just an example).

Yeah, it's actually a very large and blatant security issue to have no fallback with form submission via client side disable-able code, like JS.

Ah, yes, the right-triangle trick. I should make a note to use that in future projects, to save on images (even if it is a bit unwieldy).

Security issue? Didn't know that. I was just thinking it would suck to click "Preview" and not have anything happen.

(Or are you talking about form validation, i.e. maxlength?)

Form validation

Edit: Not fallback, I was just told to not do form validation with client side code.

You were told correctly; all it takes is the address bar and a JS snippet to break validation.

As for fallbacks -- if something can be done with AJAX, there should be a way to do it without AJAX as well. Within reason. (Marking a forum as read, for example, should not require AJAX; if the user views the page with JavaScript disabled, they should be able to click the appropriate link and mark a forum as read without JS. In that particular scenario, the link would lead to some URL that tells the server to mark the forum; JS, if enabled, would change the link at run-time to use AJAX.)

Thanks, there's lots of documentation on this sort of thing so it should all come in time as I am developing.

On a side note: While working here at Microsoft I overheard a web dev talking about how some previous employee coded a forum system using JS as their method of security when disabling forum features, and some dude disabled it in his browser and is wreaking havoc with his posts

Wow, someone was stupid enough to do that? Lol.

Wait, it's not so surprising anymore. :3