Tsunami [theme]

[Bloc]

v1.22 released with various fixes in mobile view, changed behavoir in buttons and more.

This is primary a "tweak&fix" release for glitches that have popped up. Not tested with any mods so far, but if anyone notice anything: give me a hint.

DEMO & Downloads:
https://bhksite.info/bdownloads/index.php?refreshme

[Biology Forums]

Thank you!

[Antechinus]

Cool. Will take a look.

[Mick.]

Very sweet bruh! 

[Antechinus]

Looks good. I like the way you've handled the main menu (expanded submenus when hamburgered). That makes a lot of sense. It's consistent with the "internal" sidebars and should play well if anyone has coded a second level of drops on their main menu (haven't checked, but assume it will handle that).

Handling of the .buttonlist strips and up/down buttons is also excellent. Not so much the next/previous buttons, I think they need more distinctive styling to make it obvious which half does what. I'd split those into two buttons, or if styled as one bullet have a central divider.

Noticed that your textarea for replies (full replay page) is breaking out of the screen with Pale Moon, even on quite wide windows, which means it probably will with Firefox as well. This is with the bbc editor set, not the wysiwyg. Quick reply is fine. It's only the full reply page that breaks.

Also noticed you've used a trick that I just "invented" myself last night. Setting a max-width on the large inputs in vw is the only way I found that will make them behave. Anything else insists on breaking, one way or another. Shouldn't need it for textareas (I have those sorted without it) but it would probably work for them too.

Oh, and what do the top level icons do in the profile/admin sidebar now? They're clickable, but nothing seems to happen.

[Antechinus]

Ah. Found bug. On ?action=unread;all;start=0 it's showing all the threads as "Awaiting approval" instead of "New". There doesn't appear to be any "New" link as such.

[Bloc]

Great, another bug(or several) lol. They never seem to stop do they?

Uhm, what trick was it that you invented? tbh you lost me there..something about the textareas?

[Antechinus]

No, the .text_input class. I was presumably struggling with the same problem you had, and happened to come up with the same idea last night. The inputs in the .settings dl's seem to be ok, but inputs directly inside an li seem to want to push breakage no matter what you do, unless you max-width them with vw. Made me do a bit of swearing until I thought of it.

Doing these little projects makes it clear how bad 2.0.x is for responsive in default form. Fair enough, it was conceived when IE6 was awesomesauce and before responsive was a thing, but strewth it's a pig's breakfast. Even down to really silly little things like having colons hard-coded in the markup, separate to the language strings they come after.

That's just mental, because even if you aren't doing responsive you might want to change the bloody presentation but no, some defiler of virgin goats has effing hard-coded colons everywhere. You want a hyphen instead? Tough luck, sunshine.

You want to mess with this new-fangled responsive stuff, and cleanly break labels to a separate line with display: block; on narrow screens? No can do, boyo. We're going to leave colons jammed up your colon all over the place. When you have to do multiple template hacks just to deal with stray colons it really is getting ludicrous. They're punctuation. They should be part of the language strings, like any other punctuation.

And another thing! #&&@^@#%! How about you want to cleanly break some stray bit of text, like a percentage count in a poll or something, to a new line with display block? You're screwed there too, because it ain't wrapped in a convenient HTML element so there's no way you can target it without hacking the template! Yay!

And speaking of targeting, now I'm on a roll, WTF is with the same parent ID being shared for several areas of profile or admin or whatever? If they're all frigging "admincenter" then how the flying snot dollops can you use those for accurate CSS declarations if you need to style a particular subaction differently? Heaps of id tags floating around, but hardly any of them are any actual use.

[Antechinus]

Hey I just noticed something while taking a quick look around 2.1. It's not actually responsive. Not really. For example, if you're on a desktop the menu will stay on the default desktop menu regardless of window width. This means the so-called "responsive" menu is not responding to screen size, but is instead relying on user agent sniffing (or something similar) in the back end coding. Which makes me wonder if the loading of "responsive.css" works the same way. If it does, that would be nuts.

Take the example of someone with poor eyesight using a desktop. They will want the text magnified significantly, possibly up to 300% standard size. This is going to throw all sorts of borkness at a standard layout, and if "responsive.css" is not available then you have an a11y problem. Which is why I prefer to set break points for responsiveness in em: because then the layout is matched to the desired text sizing.

[Antechinus]

Actually scrap that last post. I found out the menu doesn't come in until screen width is down to 480px. I expected to see it sooner than that. So it's not relying on back end sniffing, which is good. But the point about setting break points in em still stands. If you zoom text size with break points set in px, they remain inoperative. If you set them in em (or even in rem if you prefer) then the layout fits the content much better.

[Bloc]

Hehe, the colon stuff is not actually a "thing" - until it is, and of course its right when you are making some new templating stuff. In fairness, not all can be attributed to lack of forward vision, its just whats was there and seemingly doing fine at the time...but of course its annoying NOW.

So you mean we should set breakpoints in em/rem instead of pixels? Makes sense, they are just after all pixels at some point anyway, a degree of whatever default text size is. Have to try that. Thanks!

[Antechinus]

I don't know if everyone thinks we "should" set break points in em, but it's seemed like a no-brainer to me for years. This may be down to the fact that I only rarely browse on mobile, so am not naturally mobile-centric in my thinking.

Back when media queries first came out everyone was thinking "Hey cool, now we can fit stuff on tiny phones". OTOH I had been swotting up on a11y stuff and one of my first thoughts was "Hey, now people who need to magnify text will be able to fit stuff on desktops or laptops". It works brilliantly in all three cases, for exactly  the same reason: it arranges layout according to content. When you think about it, media queries on phones are a way of making stuff that cannot be made smaller (IOW, stuff people need to read) fit in a sane layout on limited screen width. So, if you're on a 1280 laptop and you require 24pt text for it to be easy for you to read, then effectively your screen is a 640 in terms of what you want to fit on it.

[Antechinus]

Hey I was just thinking of something. Since we both decided to mess with error log markup, what do you reckon is the most sensible hierarchy for the error stuffz?

At the moment it has member name and IP all bold up the top, but it got me thinking that this isn't all that useful a lot of the time. Most errors are things like undefined index or parse errors. That's usually what you want to filter by first.

Member name and IP are only really relevant for occasional things like brute force attempts on admin login, or some script kiddy trying a hack which hasn't worked since 1993.

So maybe it'd make more sense to rearrange the log entries to have "Type of error" and "Undefined index: ******" in the top row, with file name and line number under that, and member details last.

[Biology Forums]

To be very honest about the theme in general is that I really don't like the long search bar on the left when in desktop view. It's a little too much, and a lot of space is wasted on the left. Have you considered making the length of the bar smaller?

[Bloc]

To be very honest about the theme in general is that I really don't like the long search bar on the left when in desktop view. It's a little too much, and a lot of space is wasted on the left. Have you considered making the length of the bar smaller?

I am not quite following - the seach bar is not taking up much space in height. If you rather mean the whole sidebar and its empty space? Thats staying, but the plan is to have more items transferred there from the main view/area.

[Bloc]

Hey I was just thinking of something. Since we both decided to mess with error log markup, what do you reckon is the most sensible hierarchy for the error stuffz?

At the moment it has member name and IP all bold up the top, but it got me thinking that this isn't all that useful a lot of the time. Most errors are things like undefined index or parse errors. That's usually what you want to filter by first.

Member name and IP are only really relevant for occasional things like brute force attempts on admin login, or some script kiddy trying a hack which hasn't worked since 1993.

So maybe it'd make more sense to rearrange the log entries to have "Type of error" and "Undefined index: ******" in the top row, with file name and line number under that, and member details last.

Sounds logical, currently I am working on other areas and haven't really delved into it yet.

[Biology Forums]

To me a little more clear, here's what I mean.

The sidebar is too wide. More emphasis should be put on the right side. Furthermore, I have an issue dedicating 1 line of real-estate for the open-id image.

[Bloc]

I respect that you feel that way - but its not necessarily things I agreed with.

The sidebar width is fine as it is, it was a consideration after all, not something randomly chosen. The OpenID icon is a bit alone there, but it will probably be added with a text next to it.