Wow, you don't have to dig too far before you realise that the whole admin css mixed with front end css is a bit of a convoluted mess. I am only doing a proof of concept so far but I think I might try and separate the two out and have the admin side rely on nothing the front end needs.

Depends on what is created, but pretty much yeah. The thing is there are up to 4 "menus" plus the gray navbar. Putting them on the left shuts out useful real estate from other stuff ... or requires scrolling to get to everything else. But it depends on what you come up with more than anything. Like for example do you recall when we were trying to get all the menus onto one line? There was a hook hardship in there due to something Yabs was doing, but even so it was a total bitch. Anyway the gray navbar allowed for "top level" stuff, and other levels turned into dropdown menus. I think that's how it was. Maybe even the top level was a dropdown? I forget exactly but it was a pretty good idea ... except Yabs had a really valid point about the hook making it not work so great.

Hey on the whole admin css stuff: splitting them from admin to public would be GREAT. I'm not sure if I did it or not, but one of the branches sitting in merge gets rid of the @import stylesheet game, which is a pretty good beginning on splitting the two. If nothing else, I'd love to see that (splitting admin from public) happen. Even if it was something as simple as duplicating the files. That way we'd be able to knock out chunks that the public side never needs

OK, cool. I'm still playing (translate that into the admin is all over the place) but I'll see what comes out the other end. I know just having the navbar without the other menus has been talked about before so that could be a way to go.

EdB wrote:Even if it was something as simple as duplicating the files. That way we'd be able to knock out chunks that the public side never needs

At this point, this is exactly what I have done to let me mess with things but keep the public side isolated. I am ripping big chunks out as we speak

Wasn't doing anything other than thinking and I remembered this topic, then thought about the 5grid thing I stumbled across. 5grid came to my browser because of free html5 templates at http://html5up.net/ I tend to have a hard time doing templates, including conversions. When I saw the html5up things and saw that they were built on the 5grid framework I thought it might be the easiest path for me to get html5 templates for QP5, but I haven't done any work with that yet. I looked under the hood a bit and thought it looked good and made sense is all.

Anyway once monster finally happens - figure probably about a month maybe less - we really need to get cracking on a better way to make html5 templates. It'll take a shedload of core work to get rid of all the assumed divs ... or maybe just to make sure we can assume html5 markup just as easily. But anyway it's something we really gotta get on top of. Finally.

So we can use bootstrap if we want, or the 5grid thing. Right now I've no preference for one or the other but I suppose we might learn stuff about both of them that give us pros and cons to ponder?

I didn't get very far with bootstrap due to time more than anything else. I did all the example files (summary.php etc) and sorted out the install process.

The main problem is that the markup used in the admin is not very helpful when trying to use a more modern framework and I think it will take quite a big rewrite of the way the admin is structured and the markup usd to get the maximum benefit out of it.

I would still like to see it happen if we have the desire. I have done a number of projects in bootstrap now so know it pretty well. I really don't mind what we use though.

Bootstrap is probably the more robust of the two. I have not spent any time looking at html5 templates; the term still does not make a lot of sense to me; HTML is suppose to be markup, CSS is suppose to be the template engine. Leave HTML to html, CSS to css.