As 2014 winds down, we’ll take an opportunity to look back at some of our most-read posts from this year, in case you missed them the first time.
Via JMack on StackOverflow
Christopher Keefer is back, showing a useful technique for selectively hiding option values from inside of select controls:
Via JMack on StackOverflow
Here’s the situation:
You’ve got a select. Maybe a whole bunch of selects, with a ton of options each (metric ton – let’s keep our imaginary hyperbolic units straight here); and these are meant to be complex interactive elements, with options made visible or not as some programmatic condition dictates.
Traditionally, if you wanted to selectively display options, you had to do it the hard way – remove the non-visible option nodes entirely. What, did you want to filter on some state information stored on the node? Too bad – you’ll have to keep track of the full structure outside of the DOM and filter on that, inserting or removing elements as needed.
This is sub-optimal. It’s much tidier if we can just set
on our options elements, and have them hidden like any other DOM element:
and in most modern browsers (Firefox, IE9+, Safari), this works just fine. We can then filter in place on the elements, and selectively display them.
Have you noticed the glaring omission yet? Yes, Chrome isn’t among the browsers this works ‘just fine’ in.
You can set
on your disabled options to hide them, and that will work – but as stackoverflow user JMack discovered, and per this long-standing chromium bug (open since Jul 30 2012, with the most recent activity on it a downgrade in priority), when you have hidden options in your select, the select dropdown will fail to resize itself appropriately – to the point that the dropdown may not show anything beyond the initial visible option, with the rest of the visible options hidden beneath. They’re still selectable, and can be scrolled to, but the dropdown list will be tiny and scrolling won’t work quite right, often leaving you with the top and bottom of the next two options visible.
We’re not here to complain, though – we’re here to get things done. Let’s whip up a workaround, and then discuss how to use it, how and why it works. (more…)
TABLE vs DIV grid layout
The above diagram shows two ways to place a grid on an HTML page. The
version on the left is the old school way of managing layout. The web was positively littered with such code before widespread use of CSS (and browser manufacturer adoption of standards), which freed designers from use of tables or framesets for managing layout. The
version on the right is a sample of modern accepted practice, specifically in this example, using Bootstrap 3 styling.
You will find no one suggesting using tables for HTML layout (except when it comes to formatting HTML email. It’s ugly out there) today. Many a rant exists on the web exhorting all to separate presentation from structure, yet aren’t the two examples shockingly similar? Can the
version be that much better, when it looks like a one-for-one mapping of one element to another?
To answer the questions asked in the image, yes, the HTML on the left is bad layout and the sample on the right is OK. The reasons behind the answers come with an understanding of semantic HTML.
jQuery Mobile is a web application framework designed primarily for making sites interact well on smartphones and tablets. However, many of the features are useful for interaction across all devices. This series is focusing on the page transition effects included with jQuery Mobile.
In Part I of this series, I introduced a basic two page site and then integrated jQuery Mobile to create a sliding transition between the two pages. The first step was to include all page elements in the transition. The next step, which is covered in this post, is to perform the transition with some static content; some specific elements not included in the transition effect.