Grrr - it should have had a date by it. I'll fix all that.
As to the other stuff. I am going to write a 'how to' on the new Forum menu system. But basically, even though the cursor hasn't changed, you can click on a title and something will happen. I was delaying writing it because I want the cursor to change (but Martin needs to do that bit).
Limits are not explained anywhere apart from the 'Drum Roll' thread that I started.
Alan
This is as of the last time you accessed that page. So, it is up to date.
I've removed the '99 new members ...' as that is not rlevant any more.
Alan
I had to click 3 times to get this list of part of the forums.
At the old Dpreview I only hovered "Forums" and did get all subforums.
Yes, I totally agree. Making users click every time they want to see a sub-menu is not very user friendly.
The :onhover selector should be used in the CSS for the submenus instead of giving them an onclick attribute or eventListener reacting to clicks.
The way DPReview handled their menus was much more user friendly.
We started with onhover but all the menus were so close together that a slight twitch of the mouse made different things appear. So we went for onclick.
We are still discussing how that menu should appear. So, nothing's finalised yet. But it's better than what we had before (nothing at all)
Alan
In a group PM with Martin I suggested that in the Beta testing version the child menus were too close to the left edge of their parent menu and to move the child menus to about 10% in from the parent menu's right edge.
That would have made the hovering over menus and submenus much more user friendly.
The submenus should be able to be easily repositioned using CSS positioning.
For some reason clicking menu items instead of repositioning submenus leaving the hovering as is was chosen as the solution.
Ah - I wasn't aware of that conversation. Sorry. I would have supported your idea - and maybe gone further than 10%.
I'll discuss it with the team
Alan
From my experiments with hovering first level submenu is good at 70% (from left) and second level at 40-50%, so must submenu top be about at same level (+ 3-5px) where clicked item is - this way selecting submenus feels almost natural.
Question - should first level menu open on click [to Forums] or on hover?
After the recent migration/update I left the group PM.
43Review (Martin) was the group owner and the participants were DonaldB, Lefteye, NightOwl and myself. So hopefully maybe Martin can add you to the group private thread.
As this is a UK site under UK legal jurisdiction, it is subject to the Equality Act, which means it needs to be accessible. My professional experience was with compliance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which build on the Equality Act and are more onerous (and not legally applicable to private sites) but the compliance requirements in the regulation is common sense for any web site provider. I'm guessing the age demographic for this site is nearer the higher end than the lower, so accessibility is very much in the interests of its readers!
For example, are the menu mechanisms you are building keyboard only operable? If not, they should be. Mouse only operation is not acceptable in a modern website.
EDIT: Just did a keyboard operation check. You can tab a bit into the menu, but it doesn't look like you can successfully operate the menu via keyboard. It probably needs some keyboard events as well as the OnClick.
We used to use the services of the Digital Accessibility Centre (a non profit). They are not cheap, though, but they do provide some free resources including an online automated accessibility checker tool digitalaccessibilitycentre.org/resources.html
Those settings would probably work as well. I suggested 10% from the right but it was only meant as a rough guide as a starting point to experiment with to see what works best. In any case I wouldn't use px as the units for positioning as it can cause issues with different sized screens. My prefernce has always been to use percent or em units for sizing and positioning.
That would be a personal choice for the creator of the web page. Personally I prefer events to happen on hovering for menus rather than clicking where practical.
David, thanks for that. I will add this requirement to our feature list.
Alan
This I can agree, but mixing different kind of units (px / em - absolute vs relative) is even worse. If everything font size related is measured in pixels, then generally all this scales pretty well.
That is certainly not my experience for phone sized screens and desktop screens.
For proper scaling 'em' works best for me when setting styles for different sized screens.
I tend to agree. If people have 4k monitors everything looks tiny.
Exactly 🙂
You can alwys change zoom on desktop, browsers even can remember that per site basis :)
About mobile screens I can't comment.
All what I have created from scratch (what is not much) is not measured in pixels - but tweaking other (older) layouts may need pixels too.
Unfortunately misago/dprevived sources (styles) include many elements sized in pixels and adjusting them in pixels is easier.
Why on earth would you deliberately make visitors adjust the browser zoom when you don't need to if using 'em'.
It sounds like you don't take the variety of devices/screen sizes into account if you use px to size text.
If you use 'em' the font sizes scale correctly for the screen.
But we're straying way off-topic now so I'll leave it at that 🙂
