News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

Has anyone improved /main_block.png to have transparent rounded edges?

Started by Biology Forums, August 30, 2019, 11:35:58 AM

Previous topic - Next topic

Antechinus

Probably could do it with extra markup, but at that point is it really any better than a background image that shifts X position on hover or focus? Has the advantage that you can change colour by editing the CSS instead of the image, but apart from that? Bear in mind that I want hidden text for a11y as well, so it's just more rigmarole if I start nesting markup.

Although I have to say that I am currently sold on visible text labelling, at least for the admin/profile/etc menus. Having two unlabelled hamburgers on screen at the same time is not really all that good, IMO.

ETA: Oh hey, here's a cunning idea, just for fun. CSS gradients can have stops anywhere you like. It wouldn't be at all difficult to set up a gradient that had solid top, middle and bottom bars with transparent blocks in between. Should only need 8 stops, which is not a lot of code at all. That would be easy to edit, and no positioning or width worries at all. No need for a pseudo or span either. This is probably the best solution, if you are wanting a hamburger.

Height of the hamburger is defined as 21 px overall (including borders) so this should work:

.class_stuff_here {
    background-image: linear-gradient(#77899d 0, #77899d 5px, #0000 5px, #0000 8px, #77899d 8px, #77899d 13px, #0000 13px, #0000 16px, #77899d 16px);}


And it will just automatically fill with #77899d from 16px down to the bottom (21px).

Bloc

Yeah, I figured you rather knock about the pseudos a bit more before giving in heh. :) This is all about keeping the markup and just changing the CSS. Whereas my current obsessiondirection is throwing both at the bonfire and start fresh up. Its kind of liberating..which I suspect is my biggest motivator for working with it lol.


Antechinus

Hey just check an edit I threw in. I reckon linear-gradient is the way to go. ;)

And this is not SMF markup anyway. I've been changing markup where I think it makes sense.

Bloc

Gradients masking as a hamburger/symbol? Yes, tried that on a different scenario actually, its not too accurate tbh, sometimes the browser smushes the bars/gradients a bit, other times not. Could work well on smaller things I suppose. :)

I am using the spans I mentioned as block objects allowing them to transform to a cross when pressed/activated. Turns out theres a whole "science" about creating these kind of animations so I borrowed and tweaked:

https://jonsuh.com/hamburgers/

Antechinus

Meh. I think that's getting to the point where an image would be more sensible. That's a silly amount of code for a hamburger.

Bloc

Well I would not throw all that in lol, just decide on the animation and optimize it. You know how it is, "libraries" tend to add every conceivable option. If you just pull the parts you need, its quite a nice hamburger effect. Bonus its using "button" as markup and its in line with mobile phones current direction of animating things. No need for javascript to do this kind of animation either nowadays. I was quite fond of Mootools for that reason, several years ago, now its all doable in CSS.

Antechinus

TBH I'm not that keen on the effect anyway, and it requires extra crud in the markup for a11y. I think I'll just stick with what I currently have.

Antechinus

Hey El Blocco, try this:

#testburger {
display: block;
width: 32px;
height: 26px;
margin: 4px 0;
overflow: hidden;
text-indent: 100%;
white-space: nowrap;
background: #77899d;
background: repeating-linear-gradient(#77899d, #77899d 6px, #0000 6px, #0000 10px);
}


Something occurred to me: when you were doing ones that got mushed sometimes, where you using percentages or em for the stop positions? Because I can see how percentages might go a bit funny sometimes, but I think exact pixels should always be safe.

I think this code will be bulletproof. It's using exact pixels for the stripes, so I doubt it can get "mushed" at all. Seems to work at various zoom levels (with "zoom all" or "zoom text only") and it works perfectly on Pale Moon, Firefox, Opera and Chrome. It's quite neat code too. Not much of it, and only one element to worry about.

It doesn't work on Infernal Themebuggerer 11, but then nothing does anyway. :D That's what I threw in the first background declaration for. IE11 will read that but drop the gradient declaration, so IE11 will at least get a basic rectangle (if anyone is daft enough to use IE11) while actual browsers pick up the second declaration for the hamburger.

If anyone thought it important enough it would be easy to tweak the code to get a "hamburger bun" even on IE11. You'd just declare it as border-box and throw a top and bottom border on it. IE11 would display that. There just wouldn't be any meat in the bun (no middle bar). Then real browsers would just need an even simpler gradient, which only had one solid bar with transparent above and below. Hey presto, instant burger. :)

Bloc

Seems you cracked it, its quite elegant coding for that symbol. :)  I do like the effect so I am keeping mine :D but this just shows there so much you can do, half the fun is discovering it. 

Antechinus

Had another play with it. I think this coding is better. It's about the same number of bytes, but it doesn't only work in browsers. It even works in IE11 too.

The other advantage is that it's easier to customise. You only have to edit border colour in three places. Gap between bars is set by padding. Bar thickness is set by border width. Should be friendlier for n00bs.

#beforeburger {
display: block;
width: 32px;
height: 6px;
margin: 4px 0;
padding: 4px 0;
overflow: hidden;
white-space: nowrap;
border: solid #77899d;
border-width: 6px 0;
}

#beforeburger::before {
display: block;
content: "";
border-top: 6px solid #77899d;
}

#beforeburger:hover, #beforeburger:hover::before {
border-color: #f88c00;
}

Bloc

This is the same as what I use, although I build "bars" with the spans instead, using heights and rounded border-radius. I managed to shrink down the code to more minimal-sized than using the whole shebang from that link.

But got a bit inspired by your efforts in not touching templates, so for my current theme Origo I am not changing any admin templates, but not using any of CSS either, rather my goal is to have a separate admin css that only loads in those tempales I deem as "admin" - I could use the built-in call to admin.css but have to see if it will be loaded only in those places I'd like too. Anyways, this is a new challenge, but it will make me better suited for making new themes using only a "base" index.css and work from there, changing most used templates and its css - but the admin templates(which is drawn form default) get the same adm.css file across themes, meaning I don't have to re-invent the wheel for each new theme, which can be troublesome in regards to admin templates. Get them all working fine and share a more toned down, normal look, and let the others be anything.

Its kind of separating admin parts from the rest, but only so much as to how admin content is shown, the surrounding graphics/styles will draw from index.css of course.

EDIT: mispellings.

Antechinus

I added a border-radius to mine yesterday too. Just a basic border-radius: 4px; on the whole thing. It rounds the exterior corners nicely while leaving the other 8 as square. It fits really well with the hamburger concept IMO. Looks like a proper bun. :D

As for templates: I've edited 14 of them, although some are only really trivial edits. The rest I left alone because they're not that significant to average users. But I was sick of ridiculous things like PM's and post using different markup to do exactly the same job. That really should never have made it past beta. I may still do a bit more rationalisation. I think the best approach (for sanity) is to not try to revamp every template, but on the other hand to not be shy about editing templates where it really makes sense. The former stops you getting lost in template hell, and the latter stops you getting lost in CSS hell.

I think there's some benefit from an a11y perspective in leaving message index (and unread, etc) largely untouched, because those have proper table headers with scope="col" defined on the th's. This is probably the best format for them on screen readers, which will obviously ignore the CSS, and the CSS takes care of things for sighted users.

I like the idea of a separate and consistent admin setup. Default admin is a bit of a pig's breakfast, which is what got me started on Curve 2. In this current thing I edited the Current Theme page just because I was looking at it so much in testing, and it's so damned ugly in default form. So that's a customised Themes.template.php, but only with trivial changes. Looks like this now:

Bloc

Looking very nice. :) The sidebar was always the better one IMHO..time it found its place again.

As we are sharing screenshots :D heres one of my current admin section. The thing to notice is that whats within the admin content area will remain the same, thats a separate css file, as mentioned earlier.

About the messageindex..you suggesting screen readers utilize the headers and apply them automatically to each topic? Must admit "scope" isn't very well known to me, its use that is.

Antechinus

Sure, might as well share whatever shots you feel like sharing. After all, this thread is really only about using CSS3 to replace main_block.png. All the rest is off-topic. :D

That looks pretty clean., once I shrunk it back to the point where the text is normal size on my monitor. How did you take the shot?
I think it might benefit from a little more definition between sections. Even something like a subtle hr, or similar.

And agree about the sidebar. I've even been thinking of removing the other option from my template. Sidebar makes much more sense if you're going with hamburger on smaller screens.

Re screenreaders: as far as I understand it, they use the table headers to tell people what each cell under them does. So all the cells under the "last post" header will be linked to that via the screen reader software, meaning people don't get lost while scanning a bunch of disconnected cells. I really should fire one up sometime and give it a run, so I get a better idea of some of the ramifications. So far I've been going from documentation and common sense. Being very visually oriented, it's hard to get enthused about turning off my vision for a while.

Antechinus

Hey I just had an idea. Those next/previous page links on the page index mod currently use absolute-positioned pseudos for the indicators. I should try revamping the code to make the pseudos standard inline ones, with some sort of padding or margin to push the necessary a11y text out of view. Basic text-indent probably won't work, because that will also shunt the pseudo around, but there is probably an easy solution that will leave the pseudo where I want it but hide the text. This would be better for cross-browser support, and may even save a couple of lines of code.

ETA: Brief article on scope="col", and a few other tricks - https://webaim.org/techniques/tables/data

Biology Forums

Quotehose next/previous page links on the page index mod currently use absolute-positioned pseudos for the indicators. I should try revamping the code to make the pseudos standard inline ones, with some sort of padding or margin to push the necessary a11y text out of view.

The way it currently looks is fine with me. I think we should leave it


Biology Forums

Quote from: Antechinus on September 22, 2019, 10:25:04 PM
Is it ok on Safari/iPhone?

Yes, it looks great. The hamburger menu is the only problem on this browser

Antechinus

Ok, in that case I won't worry about it. The burger will be fixed in the next RC.

Antechinus

Just finalising some tweaks for an RC2. Unless anyone freaks about the idea, I'm going to remove the default drop menu system from admin, etc.

The whole idea of having the theme responsive is that you don't have to change settings for different screens, but the default drop menu system doesn't work on narrow screens, so you'd have to switch to sidebar in profile settings. I could write even more CSS to automatically turn the drops into a hamburgered sidebar on narrow screens, but that seems like a waste of code given there's already a perfectly good sidebar menu (with nifty flyouts).

So the sane option seems to be to just remove the drop menu option and only have the sidebar. Simpler CSS, simpler template, and IMO better functionality even on desktop.

Advertisement: