iOS9, Safari with VoiceOver enabled.
Not 100% reproducible but simply selecting an option will cause the VoiceOver focus to jump to the button at the top of the page.
Now can listen for the option being selected and then force focus on the element over a couple of seconds but that leads to undesired UX.
:focus {
background-color: pink;
}
<div>
<button tabindex="-1">close</button><br/><br/><br/><br/><br/><br/><br/><br/>
<select>
<option>Email</option>
<option>Tobias</option>
<option>Linus</option>
</select>
</div>
<p>This example shows how to fill a dropdown list</p>
In production code (which uses AngularJS) explicitly setting focus after a 2 second timeout fixed the problem but that's not ideal! Thanks.
Maybe it may come in handy this css property:
.button {
speak: spell-out;
}
Edit: this only works in firefox, see Mozilla docs
Related
I have this simple code
<style>input:hover{border: 3px solid blue;}</style>
<input type="text">
Expected behavior: when I hover the mouse over the input, new style should appear in the devtools styles section, but it only appears when I force the hover state through the devtools(not with the mouse). As I can remember it should show styles in both cases, am I wrong? This happens both in chrome and firefox devtools, so I can't really understand what is happening, I use css for 3 years and I can't remember this problem.
I believe most dev tools used to show hover states, but now I don't think any do (without clicking). Probably because they added support for so many element states that if they showed them all it could become confusing.
In IE 10 and 11, a rendered options list of a <select> element doesn't seem to be considered a child of its parent element, at least as far as transitions are concerned.
Assume we have a <div> that is styled using CSS transitions such that on hover, it slides right 100px and off hover, it slides back.
If we add a <select> element inside the <div>, it still slides right on hover. However, if I click the <select> and hover inside the list of <option>'s, the <div> slides back into its original position as if I've moved the cursor outside the <div>, rather than staying transitioned. The only explanation for this I can come up with is that somehow, IE is interpreting the select list or the options themselves as being outside of the parent element.
This snippet shows how it plays out. Try it in Chrome/FF/Safari vs IE10+.
.test {
position: absolute;
left: 0;
transition: left 1s;
padding: 20px;
border: 1px solid red;
}
.test:hover {
left: 100px;
}
<div class="test">
Move me
<select>
<option>Test</option>
<option>Test</option>
<option>Test</option>
<option>Test</option>
<option>Test</option>
<option>Test</option>
</select>
</div>
I've tried this same example in Chrome, Firefox, and Safari and I get the expected behavior - the <div> stays transitioned even when my cursor is on the <select> list. I only see it slide back in IE and I'm thinking it's a browser bug.
If this is somehow intentional by the developers of IE, is there some way to style the elements such that my transition still works?
UPDATE 12/10/14 - At the time of writing, the only two select replacement libraries I found that implement the options list such that it is a child element of the select's parent are Selecter and Chosen. Ended up going with Selecter.
In Internet Explorer we actually implement the dropdown list as a separate window. I am able to see the issue in IE 11 though, and can certainly see how that is frustrating. The good news is it appears we have already addressed this, and shipped the code on http://remote.modern.ie (run from Mac OS X, or Windows).
Expect the change in behavior to land in a future build of IE.
Sometimes I see some an unwanted border or another element in the web page and I have a lot of troubles identifying just to which element it belongs.
There may be many enclosed elements, any of which may or may not have the border in question, for example. Right now I have to go through each of them and check the border property of each, which takes a lot of effort.
So is there a way to see which element owns any given on-screen pixel with Firefox, Firebug, Chrome or any other web development tool?
I just want to point my mouse cursor at any pixel in question and see the corresponding element and/or rule.
There's usually an option to inspect any chosen element, but right-clicking on the border of an element and choosing to inspect the element doesn't seem to show the exact element the border of which was clicked.
The only way I could think of is to use the "element picker" function which exists in any developer tool.
In Chrome it is a "magnifying glass" and in Firefox a "square with an arrow" - both at the top left.
Click to activate and move the cursor around the page to inspect. The respective element is highlighted.
So you should easily find the element you are looking for.
An example:
The element inspector should do the job. The only reason I could think of for why it fails is when the element in question is covered by another element. See example:
#test-1 {
float: right;
width: 50%;
}
#test-1 >div {
border-bottom: 1px solid;
}
#test-2 {
float: left;
width: 50%;
}
#test-2 > div {
width: 200%;
}
<div id="test-1">
<div>Inspect me</div>
</div>
<div id="test-2">
<div>Obstructive element</div>
</div>
And the solution is simple: right-click on the element in question and click inspect element (zoom the page if necessary). If it is not the correct element, hit the del button on the keyboard. This removes the element you just selected. Repeat until necessary.
As far as browser functionality goes, there are two thoughts that come to mind:
The 'elements' tab of Chrome Developer Tools. If you hover over elements within the tab, that area of the page will be highlighted, complete with a height/width tooltip. (I do realize this is sort of the opposite of your use case, but it could still be useful).
Similarly, the Firefox page inspector has similar functionality.
It might be worth writing a small script to get the functionality you're looking for. You might look into jQuery's elementFromPoint. Example: http://jsfiddle.net/t8vapLwr/2/
Why don't you try this chrome extension if you don't want to rely on the element picker.
https://chrome.google.com/webstore/detail/pesticide-for-chrome/bblbgcheenepgnnajgfpiicnbbdmmooh
what it does is highlight the different elements on chrome.
I totally understand your problem. I have been thought it. So what i do is the following:
Obviously you can use the inspect tool which sometimes doesn't shows us what we exactly need.
You can use this chrome extension Precise Element Picker Tool and then select the specific element.
I am sure the 2nd option will solve your problem.
Using "Inspect Element" on a border has always worked for me, but potentially this could help.
It was mentioned by Sculper, but you could do something really quick yourself using document.elementFromPoint.
Just copy and paste this into the console:
window.addEventListener('click', function(e) {
e.preventDefault();
console.log(document.elementFromPoint(e.clientX, e.clientY));
}, true);
Then you can click around the page to find the element in question.
In Chrome, Firefox, and Firebug, that outputs the element to the console, which you can then click (or for Chrome right-click and "Reveal in Elements Panel") to see it in the Elements Panel.
If you need clicking for navigation (for a single-page app or the like), you can simply change the event being captured to mousemove or dblclick.
I am making a HTML/CSS and jQuery-based file manager aimed at mobile devices. Part of it involves the use of CSS=based modal dialog boxes for various file operations (copy, delete etc.).
I achieve the modal dialog behaviour like this:
<div id="overlay">
<div id="modalBoxControls">[close]</div>
<div id="modalBox">
<div id="modalBoxContent"></div>
</div>
</div>
And the CSS is:
#overlay {
position: fixed;
left: 0px;
top: 0px;
width:100%;
height:100%;
text-align:center;
z-index: 1000;
background: ([semi-transparent png]);
display: none;
}
#modalBox {
width: 80%;
background-color: #fff;
margin: 0px auto;
opacity: 1;
}
I use jQuery to show and hide it by calling .fadeIn() and .fadeOut() on the overlay element.
So far so good - this works great in all the browsers on my dev machine.
However, when testing on my WP7 (Samsung Omnia 7), a rather bizarre thing happens. The modal dialog shows up fine, the page behind it is blacked out. But clicks (or taps) go through the #overlay and activate anything behind it, even though it totally covers up everything behind and it's z-index is 1000.
I also tested this with the well-known "Lightview" plugin from Nick Stakenburg (a well-tested and refined piece of code) and found the same behaviour on IE on WP7.
So it seems like this could be a bug with the browser itself.
Does anyone know any solution for this?
Edit - jsFiddle with example of problem
So, check this out in your WP7 device and see how the files can still be clicked even when there is an overlay over the top of them: http://jsfiddle.net/michaelbromley/CHU76/
If by "activate anything behind it" means input controls like text input then I had the same issue. To be honesty I don't know a good solution. My workaround was disabling input controls during popup is showed and then activating them back by removing disabled attribute. The problem seems not to be related to jqmobile, but supposed to be a general behavior.
OK, so it seems that there may be no "proper" solution to this problem (hey, 24 hours is a long time on SO!), so I have come up with my own hack solution:
I when the modal dialog box is opened, I simultaneously set the "visibility" CSS property of all the elements "behind" the overlay (i.e. links and anything else that would otherwise erroneously respond to taps/clicks) to "hidden" (by using jQuery's .css() function). This means that the page layout is not affected, and that there is now nothing there to be clicked on.
As I said, this is a bit of a hack and will not be suitable for everyone who runs into this problem. However, it works well for me.
Code in jsFiddle: http://jsfiddle.net/michaelbromley/CHU76/1/
Yes, this is clearly a bug in Window Phone 7 and it is not even fixed in Windows Phone 10.
I will report this bug to Microsoft and hopefully it will be fixed.
For some reason my checkboxes and dropdown arrows are not visible in chrome, however, they still work.
They are perfectly visible in IE. When I load the page in IE, then try loading the page in chrome, they usually appear until I refresh the page again in chrome.
Anyone know what the problem might be?
Reference image: http://i.imgur.com/Q66w6.png
A 'solution' to this Chrome problem is to
open Task Manager
refresh the page in Chrome while the Taks Manager is open in front of the browser.
I couldn't believe this would actually work when I read about it, but I've seen it with my very eyes. This issue apparently exists since the early versions of Chrome and still exists in current versions, though it only occasionally occurs. It seems to be permanently gone after this 'fix'.
In webkit browsers the following code will remove dropdown arrows.
select{
-webkit-appearance:none;
}
Checking in your browsers inspector will indicate if it's being applied in your case or not.
Found this question while having the same problem.
Setting:
input {
width:100%
}
was the cause of the problem for me. This:
input[text] {
width:100%
}
was what I wanted (leave checkbox widths unchanged) -- setting the width of checkboxes in chrome seems to make them disappear.
As user48956 mentioned; setting input width to 100% causes checkboxes to vanish in chrome.
I use bootstrap and often have forms where I want all inputs to stretch 100% and don't want to use bootstraps form methods and this issue still comes up.
If you have defined input {width:100%} you can put a width on the div containing the checkbox and it will fix. e.g.
<div style="display:inline-block; width:20px"><input type="checkbox" name="read_privacy_policy" id="read_privacy_policy" class="pull-left"></div>
<div style="display:inline-block">I have read and understand the Privacy Policy.*</div>
or you can set style="width:auto" on the input itself
I had the same issue
Try this css style supression all style that acts in the input checkbox element.
-webkit-appearance: checkbox!important;
I think it's a bug and it's still there. I use checkboxes in a ligthbox window and they don't show. I'm on OS-X using Chrome 21.