News:

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

Main Menu

Regarding Responsive Design (Extremely important)

Started by Jade Elizabeth, January 02, 2015, 08:40:15 AM

Previous topic - Next topic

Jade Elizabeth

I'm developing for 2.1 though, and I don't understand that level of CSS yet ha ha.
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Antechinus

You've been coding longer than I have. :P

I suppose I could always write a Tips and Tricks thingy about how to turn default 2.1 menus into a responsive sidebar.

Jade Elizabeth

That would be great!

I'm new to responsive and I can make vertical menus no problem but I never quite got into the cool little bits like making drops and stuff quite like you did Ant :D. <3

Still trying to wrap my head around % variables....My menu needs to be minimum 160px and max 200px but at 15% it's still 280px+ and on smaller things it's awful. It's got stuff floating around it too so it's a nightmare to figure this out :(.
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Antechinus

Dropses is easy. You just set the buggers to absolute positioned (that makes them overlay other stuff) and shunted way off the left of the screen. Then on hover (or touch) you just reposition them back on screen under the button. It's as simple as changing left positioning. All the rest is just eye candy.

And if it needs to be between 160 and 200px why not just set it to 180px FFS? :D

Jade Elizabeth

Because then what the hell is the width of the float right column beside it?
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Antechinus

Auto? Like it would be anyway if you never bothered to float it. Which is exactly how the 2.0.x sidebar menu works anyway: by defining a width for the floated sidebar and letting the rest take care of itself. :D

If you have a block level element (div or whatever) and you sit it next to a floated element, the non floated one will just fill the available space.

Jade Elizabeth

Oh, why didn't I think of that ha ha.

Thank you, been a long hot day here.
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Antechinus

Melbourne? I saw the fires n ****** on the news last night. Doesn't look like fun at all.

Gwenwyfar

Quote from: Antechinus on January 02, 2015, 05:06:54 PM
Quote from: Fortytwo on January 02, 2015, 01:52:37 PM
Mine is even larger  ;D

Oh here we go. That's what they all say. :D
But it is ;) It has the default user info (which is by default on top), some css sliders, lists of recent topics, "partners", lists of tops and so on. Used to be a problem on the old forum with the admins wanting to put too many things in it and the awful layout which made it all spread out, its smaller now than it was before, but its still pretty big :P

Quote from: Jade Elizabeth on January 03, 2015, 12:51:01 AM
Thank you, been a long hot day here.
It was over 40C here yesterday :P

QuoteDropses is easy. You just set the buggers to absolute positioned (that makes them overlay other stuff) and shunted way off the left of the screen.
I find it easier to just switch the display instead when making dropmenus. In the end you're basically just hiding everything (doesn't matter much how), and displaying it on :hover.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

Well it's an a11y thing. If you're using a pure CSS menus then display: none; is not so good for a11y since blind users have no way of knowing there's extra menu stuff there. You can get around that by giving them an indication in other ways, but most people don't bother (and don't even think about it). I figure it's just as easy to give them something they find more usable, since I can easily do droppies without display: none; anyway.

A11y is interesting stuff. I had to swot up on it a bit when I was on the dev team. 2.0.x default menus are pox for a11y. I did change them to use left positioning in the dev cycle but some sod (dunno who) reverted them to display: none; when I wasn't looking, so that's how 2.0.x went out the door. I only found out later when I checked the CSS again. Frigging said why I was changing it too, but apparently made no difference. :P

Anywayz, the WAI-ARIA roles n stuff are excellent for giving notice of hidey menus but most people have never heard of them. Easy as anything to use. Won't validate with HTML<5, but will still work and won't break anything. I'm going to chuck a few into my 2.0.x beastie theme just to annoy the Customize team. They grumble if things don't validate, but I'll give them a lecture about a11y stuffz and tell them I'm not going to rewrite all of 2.0.x to make it valid HTML5. :D.

ETA: Oh the other thing about left positioning is that it enables you to get visible droppy content via keyboard (Tab key access) even with javascript disabled. Not such a big deal these days since hardly anyone has js turned off, but still a handy fallback in the old days and might be useful to someone even now.

Gwenwyfar

I see.

I just don't like to hide content by moving it out of sight, so I always just use display:none.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

I don't care, as long as it works and looks good. :) Hidden is still hidden anyway.

Antechinus

Oh here's a thing. That responsive sidebar I just whipped up uses a width/overflow/opacity transition to show and hide it (positioning never changes, in this case). This relies on the js working to toggle the classes, so if the js broke it would be awkward (although not impossible) to get back to profile>look and layout to switch to the drop menus. You couldn't use the broken sidebar as a sighted user because there would be no way of seeing it.

However, since it's only eye candy that is being switched, anyone who was blind and using a screen reader on mobile (yes, they do this) would have no problem. All the sidebar content would still be sitting there quite happily in the HTML, so they could read it just like normal. :)

And now that I've thought of it, I could use a noscript tag to show an "escape to look and layout" link if js goes down the dunny while someone is using the sidebar on a small screen. Then again, is it worth it? It'd be very much an edge case these days.

Gwenwyfar

"It is impossible to communicate with one that does not wish to communicate"

Antechinus

Yes I know I could. Markup abuse is a wonderful thing. There are some things that can be done with CSS that really shouldn't be done with CSS. Let's face it: you'll be running javascript anyway unless you're nuts. How many sites are pure CSS these days?

To get the same result I'd have to set up a fieldset and two radio buttons, plus sundry other bits. None of which is going to be semantic, and will require more CSS to run it. As it is I have two spans and a few short lines of js. Hey ho.

Gwenwyfar

#35
True, but unless js is the only one that can do something, there is no need to use it. There are many things done in js that should never need to be done in js out there.

And not really, you'd need one input and one label only. For the css it wouldn't be any longer than JS, just two selectors with a display or other position feature, same as the base for dropdowns. Also reutilizable so you only need two lines of css for any toggle you want to put anywhere. The rest is eye candy.
"It is impossible to communicate with one that does not wish to communicate"

Antechinus

Hmm. Well I'm switching the the toggle text on click (changes from "Show sidebar" to "Hide sidebar") so that would at the least, require a pseudo element that could have the content switched. Offhand I can't see how it would be possible to switch the input label directly.

Jade Elizabeth

HA! Like there are things you can do with CSS that you shouldn't ha ha ha :P.

* Jade Elizabeth runs for her life
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Antechinus

:D Oh don't worry. I do some of them myself sometimes. It can get a bit bonkers though. You should see the CSS for the menu I've been working on. Not the toggle sidebar. That one was a piece of cake. No, the nifty eye candy I thought up for my drop menus. I've just got around to testing it when it breaks to two lines, and learned a few more things about menu coding in the process. Suffice to say that its gotten damned tricky. Rock solid stable now, and looks very swish IMO, but def would not be n00b-proof.

I can just see some average admin wanting the theme if I release it, then wanting to change some detail and blowing the whole thing apart. It's sorta Formula One CSS: highly tuned and almost impossible for beginners to play with*. I may need to make a family saloon version for general release. A bit less eye candy, but wouldn't make the average admin crash and burn. :D

*Come to think of it, and I have been, this doesn't just apply to the main menu.

ETA: Oh and speaking of the toggle sidebar, I'm not really against using semantix-buggering CSS for toggles. As long as they work and the users are happy it's all good. I'm just not sure they're a better solution in this case.

Gwenwyfar

The only problem in it for me are the IDs. Technically you can do it with an input only, but then it looks bad because well... inputs are like the css dinosaurs, you should know that well :(

Still thinking of going around testing to see if there isn't a good way to do with them only.


Ante likes to make us curious  ::)
"It is impossible to communicate with one that does not wish to communicate"

Advertisement: