<select> dropdown a few pixels off - html

Consider this Bootstrap bug report. Basically, the <select> dropdown is not aligned with the <select> element on Chrome and Safari (both tested only a Mac). #mdo thinks there there is no fix. I just want a second opinion.
Can the <select> dropdown be aligned with the base <select> element?

You will NEVER style browser built-in tools the same across multiple browsers and across multiple OS.
I have been doing this a very long time and my best advise it to style as-best-as possible and reserve quirky css hacks for old IE browsers.
If you want to be super-anal about exact pixels, you need to not use the select html tag and instead use a ul tag. Then use css to list-style: none;
<ul id="my_selectbox">
<li>Option 1</li>
<li>Option 2</li>
</ul>
Then, style the menu to look exactly how you want it to look.
So think of this as a menu instead of a selectbox.
Then use javascript to make the menu drop down like a select tag.
(but that sure is a lot of work for a few pixels isn't it?)
Remember, you will NEVER EVER write a CSS file that makes all browsers look identical. Just isn't how they are designed. If you have a manager that demands it, they need to learn how this stuff works.
further note: you will have to also use javascript to store a selection. I can write you a quick script that does this if you need it. Not sure how proficient you are with javascript.

This additional style to the element may help:
-webkit-appearance: none;

Related

Is this <ul><li> text alignment a bug in Firefox?

Opening this simple jsfiddle in Firefox renders differently than in Chrome and other browsers.
CHROME
FIREFOX
I have actually been trying to make it look like Firefox in other browsers, i.e the bullet position follows the alignment of the text. Note that i'd also want the next list items to be centered, i.e not aligned based on the bullet position of the first one, see screenshot example. Anyone know a way?
I have seen answers using list-style-position: inside, but can't live with the side effect of the difference in the gap between the bullet and the text.
<ul>
<li style="text-align: center;">Hello I'm Centered</li>
</ul>
You could try using a pseudo element like :before instead to get the desired effect across all browsers. By setting the margin-right you can choose the spacing yourself too.
li{
text-align:center;
list-style:none;
}
li:before{
content:'•';
margin-right:7px
}
What's happening is that list-style:none hides the default bullet and by using :before you're able to add it back in as an inline pseudo element.
Traditionally browsers are rather free what exactly to do with the dot in lists. I can easily imagine situations, where Firefox’ solution results in a better rendering.
If the <li> makes trouble, move the text alignment one element farther down, i.e., add a helper element:
<ul>
<li><div style="text-align: center;">Hello I'm Centered</div></li>
</ul>
Disadvantage is, that you introduce an element solely for reasons of styling, but in my experience pragmatism beats purism in such an isolated case.

Make Navigation accessible for text readers

(navigation layout picture)
I have the navigation-layout of tabs and sub-tabs, which i want to make accessible via text-reader/lynx. It consists of the main pages "Startseite", "Über", "Interessant", "Orte", as well as the sub-pages "Linköping", "München" and "Baustelle". The logical structure would thus be:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
But since I use a layout of several div-tags, it only yields this in lynx:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
The questions (or solutions I don't know how to implement yet) now are:
(1) how do I improve my layout to make it accessible via text-reader/lynx
... or
(2) how do I adjust a layout of unorderd lists and sub-lists (see code) too look like my current tabbed navigation-layout?
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</li>
<li>Orte</li>
</ul>
</nav>
keep in mind that my main tasks is making it text-reader/lynx accessible. I though of using a layout like this, since it is easily styled with #some_ul_id {display: inline-block}:
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant</li>
<li>Orte</li>
</ul>
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</nav>
My third question is:
(3) Is this good practice? Should I do it?
It is the easiest way, though solution (2) would be nicer, since it is more logical.
From an accessibility perspective, the way to markup the solution so that it semantically represents what you are trying to achieve is to use the WAI-ARIA menubar, menu and the various menuitem roles. You should also use the aria-haspopup="true" attribute to show sub-menus and the aria-expanded attribute to track when the menu is expanded. In order to achieve the semantic markup of the hierarchy, you will want to have hierarchical lists as this is the easiest way to represent the hierarchy in an understandable way.
Here is a link to a full dynamic ARIA menu example http://dylanb.github.io/bower_components/a11yfy/examples/menu.html
You will need to ensure that each menu item is keyboard focusable using an href attribute on an anchor tag will do this for you as long as you look for the 'click' event and don't do anything funky with mousedown/mouseup etc.
One way to achieve this could be to absolutely position the sub-menu – of course that requires that you know beforehand that there’ll be enough space, so that items don’t go over multiple lines (resp. you have an alternative at hand for smaller screens via media queries).
So you would position the outer ul (or the nav itself) relative, and then on :hover over a main menu item you make the sub-ul visible, that is positioned absolutely in such a way that it comes to lay underneath the line of main menu items – like this: http://jsfiddle.net/0rpyLqtn/
Other slight variations are easily imaginable; if you don’t want “blank space” underneath the single line of main menu items, you could f.e. give that ul a border-bottom instead of a margin-bottom, and have the border color of it visible at all times, like this: http://jsfiddle.net/0rpyLqtn/1/
Since you have accessibility in mind, you might also want to pay attention to how this kind of menu behaves on devices that do not have a “mouse” as input device. Getting such a menu to be accessible via keyboard can be tricky, and on touchscreens a menu based on :hover might not work that well either. Anyhow, such issues have been discussed on the net already, so with a little research you should be able to find solutions/workarounds for these issues as well.

Having line breaks between <li>s

I have a horizontal menu consisting of <li> elements with display: inline.
The elements are supposed to be next to each other seamlessly.
In the source code, I would like to have each li on one line for easier debugging:
<li class="item1 first"> ... </li>
<li class="item2"> ... </li>
...
However, if I add a \n after each element, the menu items have a gap between each other. I gather this is the intended behaviour, but is there any way to turn it off using a clever "white-space" setting or something?
Edit: I can't use float, this is in a CMS with the option to center the list items.
You can avoid the rendering issues but keep the code maintainable like this:
<ul
><li>item 1</li
><li>item 2</li
><li>item 3</li
></ul>
It removes the whitespace but it's still easy to edit the items in a text editor, provided your CMS doesn't mess with the markup you enter!
Do you have the ability to edit the CSS? If so, you could try adjusting the padding/margins on the <li> element. It does seem to be a lot of effort of readability.
Depending on what browser you are using you can get the HTML Tidy http://users.skynet.be/mgueury/mozilla/, which gives you the option to Tidy up your source, which might be useful enough for debugging
CSS+float is your friend.
HTML is whitespace independent - so adding line breaks should have no effect. Some browser's rendering engines don't quite get this right however.
What you probably want to do is add
float: left;
to your li tags to get them next to each other.

Rendering error with a list on IE8, 7, 6

What is the trick to getting IE to display a <ul>? I am working on a page with a php extension. I have a simple list.
<ul>
<li>Stuff one</li>
<li>Stuff two</li>
<li>Stuff three</li>
<li>Stuff four</li>
</ul>
While on Safari and Firefox I get a list that renders properly, on IE it just displays a paragraph. I have not found one consistant answer on any websites about what could be the problem.
What's happening?
The template is from Matthew James Taylor's 3 column blog style layout.
http://matthewjamestaylor.com/blog/perfect-3-column-blog-style.htm
The css is right in the page. Even when I go back and strip the site to bare bones the lists do not display.
Is there the possibility of screwing up the css because of a div style?
IE 6,7,8 should all display unordered lists just fine...
My guess is you have something going on with CSS and/or JS that's causing the list not to be shown in IE.
There is nothing wrong with the code, you should get a list of four items in all browsers (and all versions).
Check your code for conditional (MS specific) comments such as:
<!--IE > Hidden code, could be some CSS <![endif]-->
That works fine in IE 6, do have you any css applied to the list?
No, IE does not display <ul>'s as paragraphs. Something else is wrong. Is it possible that IE-specific css is altering the appearance?
It could be that your CSS rules aren't complete. IE and Opera have a different interpretation of default list styles than other browsers, regarding whether the indentation is done with margins or padding. If you aren't applying the styles correctly, you can end up with a list that looks wrong on the browser you aren't testing on. Here is an article that goes into great detail on the differences between the browsers:
A List Apart: Articles: CSS Design: Taming Lists
Edit: And this one:
Consistent List Indentation

How can I create a menu in HTML without using Javascript?

Since many years a GUI-standard are the menu-bars of applications with menus popping up, if you click or hover an entry in the menu-bar. Some websites implement this feature too, but they are using Javascript, as far as I can see. For different reasons Javascript can be a problem, so the question: Is this possible to implement without Javascript, only using HTML and CSS?
I've done something like this before, and it's a trick pulled off by placing the menu items in anchor tags, with submenus in hidden divs INSIDE those anchor tags. The CSS trick is to make the inner div appear during the a:hover event.
It looks something like:
<style>
A DIV { display: none; }
A:hover DIV { display: block; }
</style>
<a href="blah.htm">
Top Level Menu Text
<div><ul>
<li>Sub Item 1</li>
<li>Sub Item 2</li>
<li>Sub Item 3</li>
</ul></div>
</a>
Your mileage may vary...
EDIT: Internet Explorer 6 and lower do NOT support the :hover pseudo-class on other elements besides A. In more 'modern' browsers, it is accepted to be able to use this trick with LI, TD, DIV, SPAN, and most any tag.
Have a look at CSS Menu Maker.
Best known technique is the suckerfish menus. Searching for that will result in a lot of interesting menu's. It only needs javascript in IE6 and lower.
Here's a list of the sons of the suckerfish menus.
Consider using the CSS methods as a backup for when JavaScript is unavailable. JavaScript can* provide a better user experience for drop-down menus because you can add some delay factors to stop menus immediately disappearing if the mouse briefly leaves their hover area. Pure-CSS menus can sometimes be a bit finicky to use, especially if the hover targets are small.
*: of course, not all menu scripts actually bother to do this...
You can use the pseudoclass :hover to get an hover effect.
a:link {
color: blue;
}
a:hover {
color: red;
}
I can give a more extensive example but not right now (need to get the kids to the dentist).
There's also Eric Meyer's original article on pure CSS menus.
There are bound to be much more robust and modern takes out there now mentioned by others, but I thought I'd mention it for posterity. :)