Where are the css gradients for title bars?
Why do Ant's sidebars not match title bars when they're changed with Curve2 color changer mod?
1- index.css? I don't think the titlebars have gradients, and neither the catbars, they do have shadows.
2- Is that the tutorial from the tips and tricks board? I suppose the code could not be matching the current code?
Lol. Probably because if you are using that override code I posted (without understanding it) it relies on some pretty large hammers to wallop existing code on this site.
TBH I have never looked at the colour changer mod, because obviously I can write my own CSS anyway. I prefer the cleaner approach, so really don't care what that mod does.
I'd rather do it without the mod, but can't find the gradients, unless they're images, which I thought had been eliminated in 2.1. Inspect element is not telling me anything.
Quote from: Antechinus on April 26, 2022, 05:38:03 PMTBH I have never looked at the colour changer mod, because obviously I can write my own CSS anyway. I prefer the cleaner approach, so really don't care what that mod does.
That's the thing, it doesn't do anything, it's just a color overwrite.
So it's an issue with your tutorial then.
Quote from: Sir Osis of Liver on April 26, 2022, 05:39:43 PMI'd rather do it without the mod, but can't find the gradients, unless they're images, which I thought had been eliminated in 2.1. Inspect element is not telling me anything.
Mate, if you can give me a direct link to the problem I can probably solve it in about ten seconds, but without knowing exactly what you are running...
And no, my sidebar code does not use any non-standard images. It's all CSS.
The gradients are not really gradients on the category headers, for example. Look for the .cat_bar styling (for the container, not the .catbg itself) and you'll find a box-shadow defined on them that is inset.
It's really a shadow pulled inwards rather than outwards, so not *really* a gradient.
Yes, for default title bars, but if he is running one of the variations of my override code (and there have been several posted) then all bets are (probably) off.
It's here (https://www.thekrashsite.com/nuketest/index.php), you can login and see it in profile -
user: csstest
pw: csstest
Quote from: Arantor on April 26, 2022, 05:48:16 PMThe gradients are not really gradients on the category headers, for example. Look for the .cat_bar styling (for the container, not the .catbg itself) and you'll find a box-shadow defined on them that is inset.
Already tried commenting this out, has no effect -
div.cat_bar {
background: #557ea0;
border-bottom: 1px solid #777;
padding: 0;
border-radius: 6px 6px 0 0;
box-shadow: 0 16px 20px rgba(255, 255, 255, 0.15) inset;
text-shadow: -1px -1px 1px rgba(0, 0, 0, 0.2);
}
QuoteIt's really a shadow pulled inwards rather than outwards, so not *really* a gradient.
(https://thekrashsite.com/pics/fp.gif)
Then whatever your override code has done has broken it - because this *is* how it's done in 2.1 CSS to have the gradient effect on catbgs.
Or you haven't refreshed hard enough.
Aha. Yep, I see it now. Those are not actually title bars as such. Bear in mind that this is a revamping of presentation for the default drop menu system, so it uses the markup of that.
<div class="generic_menu">
<ul class="dropmenu dropdown_menu_1 sf-js-enabled sf-arrows" style="touch-action: pan-y;">
<li class="subsections"><a class="active sf-with-ul" href="****">Profile Info</a>
<ul style="display: none;">
/* This is the visible list of subsections. */
/* Summary, Show stats, etc.... */
</ul>
</li>
</ul><!-- .dropmenu -->
</div><!-- .generic_menu -->
So the bits you are wanting to target are these:
@media screen and (min-width: 720px)
#genericmenu .dropmenu > .subsections > a {
padding: 0 0 0 12px;
background: #557ea0 !important;
color: #fff;
font-size: 15px;
font-weight: 700;
line-height: 36px;
font-family: "Tahoma",sans-serif;
text-shadow: -1px -1px 1px rgba(0,0,0,.2);
border: 0 !important;
border-bottom: 1px solid #777 !important;
border-radius: 6px 6px 0 0 !important;
box-shadow: 0 16px 20px rgba(255,255,255,.15) inset !important;
pointer-events: none;
}
TBH this is really where you want to understand the code you are using, and how to make a cleaner version for use in custom themes. :P Which, I know, I should make, but TBH I have not been using 2.1 live myself on a site of my own, so have not got around to making yet. I'm after getting a converter script working first. :P
The joys of randomly taking code on the internet that looks cool, and using it without having a clue how it works. :D
Is it loading css from minified?
Depends if you have enabled the setting to minimize files, then yes.
You'd want to remove it and temporarily disable the setting to avoid them while you make changes.
Ok, if I do this, both changes take effect -
div.cat_bar {
background: #346699 !important;
border-bottom: 1px solid #777;
padding: 0;
border-radius: 6px 6px 0 0;
/* box-shadow: 0 16px 20px rgba(255, 255, 255, 0.15) inset;*/
text-shadow: -1px -1px 1px rgba(0, 0, 0, 0.2);
}
#genericmenu .dropmenu > .subsections > a {
padding: 0 0 0 12px;
background: #346699 !important;
color: #fff;
font-size: 15px;
font-weight: 700;
line-height: 36px;
font-family: "Tahoma", sans-serif;
text-shadow: -1px -1px 1px rgba(0, 0, 0, 0.2);
border: 0 !important;
border-bottom: 1px solid #777 !important;
border-radius: 6px 6px 0 0 !important;
/* box-shadow: 0 16px 20px rgba(255, 255, 255, 0.15) inset !important;*/
pointer-events: none;
}
I'm matching main bg color on website, so gradient isn't really necessary. 2.1 css seems like an assways way of doing things.
If you want to know why it uses an inset box-shadow: back when I wrote the code for 2.1 Alpha, cross-browser support for CSS gradients was still a bit iffy. Since it was alpha code I just wanted something clean and simple, so instead of including all the current variations on CSS3 gradient syntax I used an inset box shadow. This worked, with one simple syntax, and gave the look I wanted at the time. :)
It's not necessary for anyone to use an inset box-shadow if they would prefer to use something else. ;)
So basically it's ten year old code. Nice. :P
Where are the board icons called (on.png, on2.png, off.png)? I've replaced them, deleted them, nothing changes.
.board_icon a {
background: url(../images/boardicons.png) no-repeat 0 0 / 90px;
display: inline-block;
width: 45px;
height: 45px;
}
.board_icon a.board_on2 {
background-position: -45px 0;
}
.board_icon a.board_off {
background-position: 0 -45px;
}
.board_icon a.board_redirect {
background-position: -45px -45px;
}
.board_icon {
text-align: center;
padding: 8px 0 0 0;
width: 60px;
flex-shrink: 0;
}
It's one image now. This makes it load faster and perform better against Google's ever whiny performance criteria which means SMF doesn't get downvoted *quite* so badly as it used to.
I was about to tell him that, with an added note that he would not have had to ask if he had used his browser's document inspector to grab the default CSS. :D
Quote from: Sir Osis of Liver on April 26, 2022, 06:40:07 PMSo basically it's ten year old code. Nice. :P
Yes, but it's still a simple and efficient way of getting that look without using images. I assume that is why it hasn't been changed.
Quote from: Antechinus on April 26, 2022, 07:04:24 PMI assume that is why it hasn't been changed.
It was changed to regular gradients and changed back, I think, because I remember having an argument with someone in 2013 about how they would have to upgrade their several-year-old Mac Pro to get the gradients as they were actual gradients.
A sprite. Thought we were getting rid of sprites?
Inspect element wasn't giving me the file name.
Quote from: Sir Osis of Liver on April 26, 2022, 07:10:29 PMA sprite. Thought we were getting rid of sprites?
We were getting rid of stupid big sprites where they didn't make sense (main_block.png, etc).
QuoteInspect element wasn't giving me the file name.
It will show you the CSS associated with any element. That's what you needed to look at, since these are background images rather than inline images.
Quote from: Sir Osis of Liver on April 26, 2022, 07:10:29 PMThought we were getting rid of sprites?
This was done in 2013, and at the time there was no way to meaningfully do a pure CSS version of this icon that was browser-agnostic and not awkwawrd. These days it would likely be better as an SVG possibly even inlined.
Quote from: Sir Osis of Liver on April 26, 2022, 07:10:29 PMInspect element wasn't giving me the file name.
Funny, I found it with inspect element... sometimes you have to go up an element or two.
I see it now. It's easy to find if you know what to look for. Did a quick edit on the sprite, needs some prettying up but works.
Ok, I've eliminated the sprite, back to individual images. Thanks, but no thanks. :P
.board_icon a {
/* background: url(../images/boardicons.png) no-repeat 0 0 / 90px;*/
background: url(../images/on.png) no-repeat 0 0 / 60px;
display: inline-block;
width: 65px;
height: 65px;
}
.board_icon a.board_on2 {
background: url(../images/on2.png) no-repeat 0 0 / 60px;
background-position: 0px 0;
}
.board_icon a.board_off {
background: url(../images/off.png) no-repeat 0 0 / 60px;
background-position: 0 0px;
}
.board_icon a.board_redirect {
background: url(../images/redirect.png) no-repeat 0 0 / 60px;
background-position: -5px 0px;
}
Personally, I replaced them with gradient circles and fafa (or, in my case, starwars font) icons
He has custom board icons, that's what we'll be using. Bit of trouble to edit css to resize and position, but they look ok now.
Took me a couple hours to find this. >:( Forum has a custom header with dropdown menus, title and link colors were incorrect in some menus. Looked like a conflict between header and forum css, that's what it was, but don't know why. Some of the links were wrapped in <strong></strong> tags, this was callimg .strong class from forum index.css. Fiixed it by replacing all <strong> tags with <b>. It's not a class, it's an html tag, why would it affect css?
Strong is a css target-able html... like most html tags actually
<strong> is what <b> used to be.
<b> was briefly deprecated, now it's just irrelevant despite being back.
I'd rather use <span class="strong"> with 2.1 css, or simply <strong>, than using <b>
So if it sees <strong> it applies the .strong class, same as a <div>, <h1>, etc.? There were several conflicts between header and forum css, but this was the most difficult to find. Any way to avoid something like that?
The strong tag is for importance/emphasis, while the b tag is just a substitute for CSS styling (not recommended to use b tag these days). So not really what b used to be. Strong has been around for ages too.
Quote from: Diego Andrés on April 30, 2022, 08:05:22 PM<strong> is what <b> used to be.
<b> was briefly deprecated, now it's just irrelevant despite being back.
I'd rather use <span class="strong"> with 2.1 css, or simply <strong>, than using <b>
That's what caused the problem, there's a .strong class in index.css, and it was different from the css in the header, so it changed colors in the dropdowns. <b> looks the same as <strong> in FF, so it should be ok.
Quote from: Sir Osis of Liver on April 30, 2022, 08:09:03 PMSo if it sees <strong> it applies the .strong class...
No. If it sees this, it applies this:
strong, .strong {
font-weight: bold;
color: #444;
}IOW, the colour and font-weight are applied to both the tag and the class.
That's what it was doing, changed link color and killed mouseover highlight. Don't know what changed menu titles, but adding color to .column h3 fixed it. Trying not to make too many changes in website code, some of it is quite old but still works, and it's not what I'm there for. Just integrating custom header/footer onto forum without breaking anything.
Where is the css for the login window? Not the contents (.login, etc.), the popup window itself. Having some conflicts with custom header css, need to mess with z-index to get it on top of things.
Look for .popup_container in index.css (document inspector FTW).
(https://thekrashsite.com/pics/banghead.gif) Whack-a-mole. Working with this -
.popup_container {
display: none;
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: rgba(40, 64, 80, 0.5);
z-index: 6;
}
With z-index: 6 header dropdowns are good, but login window is behind header menubar. At z-index: 10 or higher, login window is on top, but forum menu buttons are on top of header dropdowns. Will leave it like that until tonight, you can see it here (https://www.nukeworker.com/forumtest/index.php). Can move login window down with margin-top: 100px, but would rather fix it with z-index.
Basically, you want to assign the highest z-index value to .popup_container, the second highest to the menu nearest the top of the page, the third highest to the next menu moving down the page, and so on.
Think I'll just go with margin-top: 100px. Doesn't seem to break anything in mobile view. The custom header pushes everything down the page, so with 100px margin it's actually higher than it is on forum only. Don't want to mess with header code more than necessary, and I can do this with forum css. The basic problem here is browser loads forum and header css, and tries to apply both to both, so there've been some conflicts. Trying to minimize collateral damage.
Ant's sidebars don't inherit css formatting from custom themes, it's always Curve2. Would be nice if it did, save a lot of hunting and pecking.
Then stop ******ing about it and rewrite the CSS. That's what I did. :P
Well, I fixed it for the theme I'm working on, but would have to repeat the process for every theme. Is there any way to rewrite it so it's more global? I'd imagine it would be difficult to do, as custom css varies quite a bit.
Well you could strip out all the eye candy, and just leave the structural stuff. Then it should pick most of the eye candy up from the theme in question.
ETA: One point though is that because it is a presentation override of the default drop menus, it will never automatically match any theme completely. For example, the sidebar is actually top level menu buttons + first level drop menus, re-styled to suit a sidebar look.
So if you take all the eye candy out, it will inevitably want to style the section headers like top level menu buttons, and the list of sections like drop menus. That's what it will pick up from any theme, because that's what it is as far as any theme knows.
So you will still have some work to do cleaning it all up. Best option is probably to strip out as much as you can, and comment the thing very heavily so you know exactly what each bit of CSS is doing. Then you can just copy in eye candy to suit the rest of the theme.
Maybe will give it a try. Other thing is, once you've installed sidebars everything else in ACP is superfluous or redundant. But how do you fill up all that space? Can sidebars be columnated?
Not sure what you mean there.
Sidebars occupy around 25% left side, if you remove welcome message (not needed), smf news (nobody reads news), support info block (you get more in support & credits), and new cpanel style menu (nice idea, but it's offscreen and redundant), you end up with a lot of blank space. Can sidebars be rearranged to fill it?
Ah. In that case you mean not bother making it a sidebar, and just display the first level drop menus all the time (with eye candy to suit). Which, yes, is very easy to do in principle. I haven't played with that idea yet, but it may have potential.
And there's no need to remove any default stuff. The drop menus display across the top anyway. You'd just be making them look a bit different.
The dropmenus as they are don't display like the sidebars, you have to drop them to see what's in there. Sidebars give you all the top level <li>s so you don't have to hunt around for them, that's what makes them easier to use. There are five main categories, if you could put them two or three across it would consolidate everything into a compact arrangement and eliminate a lot of dead space.
And you have to retool a LARGE amount of the admin panel to do that. It's not just presentational.
Yes I knew what you meant. My point is the sidebars ARE the drop menus. Just with different eye candy. So, sticking them in a row horizontally instead of vertically is very easy. Same with putting them in a grid of blocks. Still easy.
The catch is that depending on area, permissions, mods installed, etc, there will be different numbers of "buttons" and "drop menus", so a nifty "looks perfect with any content" arrangement is going to be pretty much impossible. There are going to be spaces left at the end of the last row sometimes.
Quote from: Arantor on May 08, 2022, 06:58:57 PMAnd you have to retool a LARGE amount of the admin panel to do that. It's not just presentational.
He's just talking about frigging with the menus. I think he has been talked out of frigging with the rest (I hope so). ;)
Yes, just moving things between menus is a chronically bad idea and requires serious surgery to actually do.
I wasn't thinking of moving things between menus. As I understand it, he was saying that he likes the idea of arranging the five main sections of the sidebar (which are really just the five default admin buttons and their associated first level drops) and putting them in a row or grid across the top of the page (which is where they are by default) instead of floating them in a sidebar.
That's a pretty trivial presentation tweak. :)
Yes, that's what I was thinking. Would it be too difficult to accommodate additional first levels or blocks from mods?
No that would not be difficult as such, but see the caveat earlier: with varying numbers of first level "buttons" you aren't going to be able to guarantee a fully-filled grid all the time. For example, if you set it to three across and you have five sections, there will only be two in the second row.
You could center two under three, but you'd have to be able to add more first levels to the grid for mods that add them.
Yes, you could do that, or you could use any other of the standard flex options. Any of which can deal with adding more buttons, as long as you set flex-wrap: wrap; on the parent ul. :)
/* Positional alignment */
justify-content: center; /* Pack items around the center */
justify-content: start; /* Pack items from the start */
justify-content: end; /* Pack items from the end */
justify-content: flex-start; /* Pack flex items from the start */
justify-content: flex-end; /* Pack flex items from the end */
justify-content: left; /* Pack items from the left */
justify-content: right; /* Pack items from the right */
/* Normal alignment */
justify-content: normal;
/* Distributed alignment */
justify-content: space-between; /* Distribute items evenly
The first item is flush with the start,
the last is flush with the end */
justify-content: space-around; /* Distribute items evenly
Items have a half-size space
on either end */
justify-content: space-evenly; /* Distribute items evenly
Items have equal space around them */
justify-content: stretch; /* Distribute items evenly
Stretch 'auto'-sized items to fit
the container */
Here ya go. This is just a quick presentation revamp of the standard admin CP mess, with superfluous stuff shunted out of the way. Can be run with or without sidebar.
Why would you run it with sidebars?
Because that is just the admin home page. That content is not on any other page. But, you could do something similar with the default drop menu system easily enough.
ETA: In general, I think I prefer a sidebar.
What is this for? It's causing a problem for me in custom theme.
.noup {
border-top-left-radius: 0;
border-top-right-radius: 0;
margin: 0 0 10px 0 !important;
}
Want to add margins in profile summary, but have to comment out margin in .noup to do it.
That is there especially to demonstrate the principle that class names should be clearly descriptive. :D
It's for divs that by default do not have a gap between them and a header bar.
It overrides margin settings in .roundframe in custom.css, I'd like to change the one without removing the other.
Ok, so use your browser's document inspector which is faster thhn posting threads about it, and grab the #profileview from that, then use that to target your CSS for that area.
I've done that, but .noup overrides margin in .roundframe, I can't change margins unless I remove .noup.
You can see it here -
Well tell us what code you are running and we might have a chance of diagnosing the issue. It's bound to be something trivial.
.roundframe is in custom.css -
.roundframe {
background: #1A1A1A;
border-top: 1px solid #0669d5;
border-left: none;
border-right: none;
border-bottom: none;
box-shadow: none;
padding: 0;
margin: 0;
}
.noup is in index.css -
.noup {
border-top-left-radius: 0;
border-top-right-radius: 0;
margin: 0 0 10px 0 !important;
}
I can fix it with padding in .roundframe (hadn't tried that), will have to see if it causes problems elsewhere.
Ok, so if you really have to, use !important on your .roundframe margin in custom.css.
If they're both !important, which is used? There's also .roundframe in index.css -
.roundframe {
margin: 10px 0 0 0;
padding: 12px 16px;
background: #f8f8f8;
border: 1px solid #c5c5c5;
border-radius: 7px;
box-shadow: 0 -2px 2px rgba(0, 0, 0, 0.1);
overflow: auto;
}
How is it decided which is used?
I'll go with padding, it doesn't reposition the container, just the content, so it's less likely to break something else.
If they are both equally specific, the one that is last will be used. That's the C in CSS - Cascading.
This theme was a bit different for adding your sidebar code. Usually place it at the end of index.css, but if I do that in custom.css it messes up the entire forum. It's at the beginning, doesn't affect anything else, just had to fix the formatting to match the theme.
Y'know on second thought I think I could get to like the admin menu across the top of each page, with the first drops permanently expanded. It's certainly a convenient layout, with everything available, and with the default 5 sections it's fine down to about 960px wide. So no problems adminning on desktop or tablet, or even on most phones in landscape mode.
Might fall down if mods add too many sections of their own. Not sure I'll be using any mods that do that though. :P
Need something else on a phone in portrait mode, obviously, but then you can go to a hidden sidebar called by hamburger, or even just split the menu into more rows (again, called by hamburger).
Much easier to scan than the default "Admin CP", which is really too jumbled to be any use, and hardly worth revamping.
Anything is an improvement over core ACP.
Do you *really* need to rub it in? We get it that you don't like it already.
It really is too jumbled. I had been looking at it, wondering if it was worth trying to do anything with it. The problem is that the icons are large and colourful, the text is small (and not colourful), the text is centre-aligned (which is always harder to read), frequently breaks to two lines (ditto), and comes after the icons.
The result is that if you want to use it as a source of information, you really have to make an effort to search for the information. It does not scan quickly or easily. To make it scan quickly and easily, the presentation would need to be revamped to make the text the main feature and the icons not overpowering the text. IOW, it would have to be redone to be more like a good menu.
At which point I find myself wondering if it doesn't make more sense to just deal with the actual menu and not bother with the CP, since the CP is only available on one page that has no other functionality, while the menu is available on all relevant pages. Really, the admin home page is only useful for seeing update warnings. Nobody ever really cares about anything else on that page. If update warnings were visible elsewhere, like maintenance mode warnings, the whole admin home page would be redundant.
Anyway, the screenshot shows what I'm playing with at the moment.
Like the direction you're heading in there Antechinus. It's just what we need - a full overview of the Admin panel. I often have to hunt around looking for stuff. If that could be done in a single screen, it would be very useful.
For the existing CP itself, you could do something like this. It's a quick bash at basic CSS on default markup, to make it more like the cPanel home page (which actually is easy to scan). Haven't bothered doing responsive yet, but it wouldn't be difficult.
Another tweak which would make sense is dropping opacity on the icons to about .8, which would work well on the default colour scheme and be a lot more usable on a dark theme.
Admin_CP_revamp.jpg
Having everything left justified is definitely easier to read than the current centred style. And it looks snappy too.
Admin_menu_revamp.jpg
But the all text style is great for actually finding stuff. Particularly if the all the drop downs work so you can get to any menu level from the one page.
They all work. Essentially it's the standard drop menu, but with the first lot of drops being permanently on display.
An alternative way of looking at it is that it's the old sidebar menu, with drops, and rearranged as a top panel in columns (which is what I actually developed that example from). That same markup can easily be done as a sidebar, and of course the sidebar can be off screen on a phone, sliding in via tap on a hamburger.
I have thought of getting rid of all icons, because on a complex menu they do tend to be nothing more than a distraction. Nobody can remember all the icons anyway, so it's the text you need to tell you what does what. It might work better with icons if they were more subdued. The "box of fluorescent crayons" look doesn't really work on a menu, IMO.
"Admin_CP_revamp" was just me doing what could be done with it quickly, with only basic CSS tweaks, as a change from grumbling that it was useless. It's still no good for general navigation because it's only available on the admin home page but, since it is there by default, someone might want it easier to use and looking snappier.
Quote from: Arantor on May 16, 2022, 01:53:57 PMDo you *really* need to rub it in? We get it that you don't like it already.
I'm not trying to rub it in, but it should never have come down to this after ten years of development. I still have some files I posted in 2015, possibly on team board (you might be able to find it), with a suggested modification to ACP, which, whether good or bad, were not d/l'd even once, no one even bothered to look. Ant's been knocking out better alternatives one after the other for a couple weeks now in his spare time, why weren't they considered back in alpha? The reason is the people who were running the project at the time had pretty much everything chiseled in stone before alpha was even released, and those of us who disagreed with the plan were rebuffed (or worse), and any unfavorable criticisms or suggestions were ignored. Not surprising that most of the devs who started 2.1 were long gone by the time it was released.
Brings to mind the Win 8 fiasco. MS devs ignored the overwhelmingly negative feedback from beta testers (what do they know), released a crappy ui, and wouldn't admit they'd laid an egg until oems started screaming about all the new computers that were being returned.
Sad thing is, we're probably stuck with what we have for the next ten years or so. Any improvements will only be made available as mods.
Look, I made these changes in 2013. I even posted screenshots at the time. No one seemed to dislike it much *then*.
I can't vouch for what happened after that though. 2015 was a time I wasn't here much. Nor was I team...
We did not have negative feedback from the beta testers.....
Obvious question: did they actually use it?
My guess (based on my own experience) is that people didn't bother complaining about it because it's down the bottom, of one page only. Invisible even on that page unless you go looking for it, and not accessible at all on any other page, so they simply used the menu instead.
Quote from: Kindred on May 25, 2022, 05:53:58 PMWe did not have negative feedback from the beta testers.....
I can only speak for myself, but when beta testing I focus on technical issues, not functional...
But since there are many people around that see functional improvements today, perhaps they can join the beta test team as well?