I am Trying to find out the "correct"(best practice) way of creating toggleable sidebar with bootstrap 4. Gone through the examples on the internet and not so sure if those were so good...so If someone can send me related resource links ,it would be great so that I can analyze it.
-I am from android platform so I'm a newbie when it comes to web development but I'm trying to achieve that kind of sidebar like on this side: link -notice: sidebar doesn't change its width(stretching) while changeing the size of a browser -until a point when it jumps over to icons width.
Bootstrap does not have an "official" sidebar implementation so nothing is "correct" here. As long as it works cross-browser/cross-device, anything is good to go.
Regarding the sidebar implementation itself, there are various options:
opens above the content,
pushes the content to the opposite side
squeezes the content
The above options and the array of animation possibilities for:
the sidebar itself,
the menu item containers,
the menu names/labels
and the menu icons...,
...make any attempt at providing an example prone to subjective preference and would render your question off-topic.
Other possible features are
auto-open above certain width,
auto-close below certain width,
reordering of elements,
three-state (full, min and off).
But on topic, the only objective answer to your question is: there is none (official).
As a starter, you might want to take a look at this simple sidebar. It works prefectly fine with v4. Just import the simple-sidebar.css and adjust the calls to match your project's elements.
In the end, the sidebar is all about two containers and applying a class (plus, ideally, some aria- attributes for screen readers). What you put in those containers and how you adjust the contents to look in each element state is all about your own (or the designer's, or the client's) personal preference.
Related
I need to show certain content in a modal/fullscreen panel on small devices, triggered by a button. On large devices, this same content, is just always shown and the trigger is then hidden.
How do you approach this for accessibility?
Currently, I have this setup
<button type="button" aria-expanded="false" aria-controls="filter-panel">Filter</button>
<div class="o-panel" id="filter-panel">Form</div>
Initially, the o-panel is hidden on small devices via CSS (in a media query that targets small devices). I set aria-expanded to true when the trigger is hit, and add an active class to the panel itself, which shows the fullscreen o-panel via CSS. On large devices, I hide the button and always display the content from o-panel via CSS (in a media query that targets large devices), inline, where it is found in the HTML.
Does this make sense for accessibility? My panel doesn't say role="dialog", becuase on large devices it's just content, not a dialog. Is it a problem that my button is hidden on these large devices?
I'm really stuck at what I should do here. If I add role="dialog" to my o-panel, should I remove this property for large devices, where it is actually not a modal?
Or should I move copy/move the content from my o-panel in a div with role="dialog", in case the trigger is hit? I just don't want two copies of the same content.
On large devices you need to do a couple of things.
Hide the button properly
First make sure the button is display:none, not visibility:hidden or anything else or it will still show up in the accessibility tree.
The main (<main>) problem
A modal should appear outside of your <main>.
This is so you can add aria-hidden="true" to the <main> element when the modal is active, so as to stop people navigating outside of the modal on a screen reader. (Screen reader users use headings, links etc. to navigate a page so you can't just intercept the tab key.)
Now I come from a mobile first philosophy so I would say your markup should be mobile first. That means putting the modal outside of your <main> as discussed earlier.
This obviously causes a huge problem on a desktop. You now have the content sat somewhere it shouldn't be.
Because of this you only really have two options here.
Option 1
Use JavaScript to reposition the modal content in a predefined placeholder <div>.
So you keep your mobile first design, then use JavaScript to find the innerHTML of your modal and move it into the body within your holder. Then delete the modal itself just to be sure.
While you are at it I would also delete the button, just in case someone resizes the screen to a mobile view, we don't want a button leading nowhere.
Alternatively don't delete the second content then people can resize the browser, just means a few extra DOM nodes (so as long as your modal content isn't over 100 DOM elements I would say do this.)
If you decide to keep the modal make sure that is also display: none for the same reason as the button, we don't want people accidentally accessing it.
Option 2
Duplicate content.
I know, I know, duplicate content is just, urgh.
But sometimes you just have to put up with it if it is for the best.
By duplicating the content into a div from the start you do get a few advantages.
Advantages
If the user resizes the screen you can just use CSS to switch between views.
No need for JavaScript, great for if your site functions without JS or when your JavaScript fails.
Although it adds page weight it is likely to be better for performance overall, the potential for layout shifts with the first option resulting in a high Cumulative Layout Shift is quite high (although avoidable). With Google putting so much emphasis on Web Vitals I would start considering them now. Additionally you might find you write nearly as much JavaScript as there is HTML if your modal only contains a couple of elements.
Disadvantages
You would have extra page weight due to duplicated HTML.
You may have to adjust scripts etc. to account for the second duplicate item (although this should be minor).
This would still be my preference, Keep It Simple! This is far more robust
Option 3 (for the future)
Client Hints are one way you could solve this, turning responsive design into a hybrid of mobile vs desktop and responsive.
When client hints has enough of a market share you could simply use the header to decide which version of the page to send from the initial request.
You could possibly implement this today if you are willing for 25% of users to see the mobile version of your information on desktop, depends how important the info is.
Other considerations
There are a few other things to consider that you haven't mentioned so I thought I would add for reference.
I already mentioned adding aria-hidden to all elements outside of the modal when it is active.
To future proof your application use inert on items outside of the modal. Support isn't great (none existent!), but every little helps and it is quite likely to get implemented!
You can polyfill it if you want but I don't think it has moved outside of the draft spec yet so we just use it as is.
Also add aria-modal="true" to your modal.
I covered a lot of these points in a bit more detail in this answer if you want a bit more info.
Make sure you include <meta name="viewport" content="width=device-width, initial-scale=1.0"> in your <head> tag.Then in your style, you can play around with
#media only screen and (max-width:620px) {
/* For mobile phones: */
}
You can learn more about the #media rule here: W3Schools Media Rule.
If you have any more questions be sure to ask!
The accessibilitys properties are only aria-expanded="false" aria-controls="filter-panel" don't change it.
Your class and ID names doesn't have any impact on accessibility.
If you only want to show the content by default on large device, and display a call to action to show it only on smartphone device, you could do that with javascript and media-query.
I'd like to implement a sidebar, where each entry will have an Icon along to it's text.
In deactivated state, the sidebar shall display only the icons, wheres in activated state, the sidebar shall expand to its whole width, showing its entries with both icons and text.
Just like the menu button in Expanding Menu Button, but this behaviour for the whole sidebar.
Can this be done using Semantic UI?
I have asked a similar question a while ago here, and I managed to solve it myself, by modifying some of Semantic-UI's source code.
Unfortunately, the modifications were too extensive to post them directly in this answer, so I have created a github repo with an example here. Hopefully it helps. Due to the fact that the source code from Semantic-UI was modified, normal sidebars will probably be buggy.
I have a navigation bar on the mobile version of a website and want it to be always as wide as the screen, i.e. when the user zooms in, the bar is supposed to not zoom in with the rest of the page.
Illustration of the problem:
Without zoom
With zoom
I know this is possible with JavaScript as described in this approach: https://stackoverflow.com/a/14466070/695457
But is there a way without JS? If not, are there any other libraries for this except detect-zoom?
There is no way without JavaScript. I suggest you leave it as it to be honest as those menu items look mighty small on the first screenshot if it was on a phone. You may be introducing an accessibility issue by disabling the functionality to let people with poorer eyesight view the menu text.
I´m using awesome Brad Frosts left nav flyout for my responsive design navigation. (http://codepen.io/bradfrost/pen/IEBrz).
I need some advice for the flyout. I need the flyout-area to be scrolled separately, not affecting the main content area — like the facebook app.
My experience so far is pretty bad when it comes to crossover support for fixed, scrollable areas (with complex elements inside) for smartphones combined with relative heights and meaures (the site is responsive). I´ve tried iScroll and jQuery mobile so far.
Would it be possible to accomplish scrolling the flyout ONLY without a huge amount of javascript-plugins, client-sniffing and CSS vendor-specific hacks?
My client really likes the flyout pattern. Performance, crossdevice support and non-hacky code is a "must have". Native look and feel is a "could have". I have no problem recommend another way to solve the navigation, I just need to be sure of my decision. Of course everything can be done — but to what cost?
Do you have any recommendations or advice before I cut the rope :) ?
The preview you've put up is looking really promising!
What I would suggest is that you use a little JavaScript to detect the window height. You can then set the height of the fly-out panel to the same height as the page and use display: block; overflow: auto. (It's possible that it already has block-display set).
This will force the panel to scroll within itself rather than flow further.
A few things worth bearing in mind:
You'll need to recalculate the height on window change or orientation change;
Touch-screen devices tend not to display scroll bars, this is a double-edged sword because it means you get a really nice app-like feel when you swipe up/down. However, it also means that users may need a little more of a visual hint that there's something to scroll for!
Can you explain to me, at a very high level, what I would need to build an image carousel for the web, please. You can use data structures and general computer science terminology - but nothing language specific.
E.g:
Store all the images in an array or linked list
When the carousel is loaded, resize the displayed images as X% window size
When the next button is pressed, imageA moves to a hidden html element.
Et cetera.
I hope that makes sense.
Thanks.
You don't want anything language specific but you want to know about carousels on the web and you've tagged this with 'html' and 'css' so I'm going to assume that I can talk about HTML and CSS but I'll try to keep it high level.
If we ignore Flash, then you're left with HTML + CSS + Javascript. The common way to do this is to arrange the images or their thumbnails (don't resize via HTML - its doesn't look good and can increase your page load time) in HTML elements that are themselves contained in one or more layers of wrapping elements. So the whole set of images strung together might be wider than the viewing window. CSS is used to manage their exact layout and to keep them from overflowing the viewing window. When I say window, I just mean the portion of the page in which you want the carousel to appear. Then Javascript is used to change the CSS properties of one of the HTML elements that is wrapping the images, causing it to scroll or shift position.
With HTML5, you have more options, but the above is the way things have usually been done until now.
Finally, if you are going to actually implement this, there are a number of scripts available that will probably meet your needs, but if not I highly recommend using a Javascript framework like JQuery - it will make things much, much easier.
If you want to build it by yourself, one straightforward way would be to have a master div and all the images in it, lined up horizontally. Have the overflow set to hidden on the master div. Then use javascript and set scrollLeft as the user clicks the next, previous buttons.