Do hidden input fields have a physical location within the page?
I know this question probably sounds dumb (I definitely feel like it for asking), but recently I created a website with a lot of hidden fields (created with JavaScript DOM), and I noticed there is a huge, empty area at the bottom of the page.
I checked the code and I can't find anything that could cause this problem.
var hiddenfield = document.createElement('input');
hiddenfield.setAttribute("type","hidden");
hiddenfield.name = "hiddenfield";
hiddenfield.id = "hiddenfield";
hiddenfield.setAttribute("value", document.getElementById("select1 4").value);
formNew.appendChild(hiddenfield);
I edited in some code to show the way I created the hidden fields.
No, input type="hidden" fields aren't causing this. Possibly some css style or width and height settings.
They do have a location, try to change hidden in text from the developer console and you will see it's position. They are just collapsed. The don't influence layout in any way.
If you are using <input type="hidden"> then as Patrick answered they will not influence layout. As in this example explained by Patrick.
BUT if you are hiding your input fields using visibility:hidden then YES it will take the space. See THIS example.
As according to W3
"visibility:hidden hides an element, but it will still take up the same space as before. The element will be hidden, but still affect the layout."
You can hide your fields using display:none. According to W3
display:none hides an element, and it will not take up any space. The element will be hidden, and the page will be displayed as if the element is not there
Related
I'm aware that for input and textarea tags you can specify autocapitalize as off. Is there a way to do this when you are using a content editable div, as they do not have the autocapitalize attribute?
I have seen similar thinks achieved elsewhere, on the likes of online code editors. The orion editor for example uses an editable div and doesn't suffer this problem.
I have found a workaround to this. I fill the content editable with a zero width space () that the user can't see. Then when they tap and start typing, no auto upper casing!
Add this to the divs style :)
text-transform:lowercase;
I hope this helps!
EDIT
Okay now I understand fully. In an editable div this is not possible to achieve. The variable for this function cannot be controlled by HTML or JS. This is hardcoded into the objective-c of IOS. Nothing can change this unfortuatnly. The only way you could possible achieve what you are trying to do and that is to change the div to an input field, and then use the auto-capitalisation: off.
Apologies its not good news but I hope this helps!
I have a website and I'm making it available for keyboard users. This might have been asked before but I haven't found a way to make it work yet. :(
The issues that I'm having is that on a certain point there is a slideshow and a pauze/play link. When a users tabs through the site, he first has to go through the entire slideshow and then the focus lands on the pauze/play link.
I've tried recreating it as best and simple as possible.
Fiddle here
When you tab through the elements you notice that the focus goes directly on the slides and afterwards goes to the pauze/play link. I know this is normal behaviour because of the HTML structure.
My question is: How can I manipulate this order that whenever I tab from the last "link" the focus goes straight to the pauze/play instead of going to the slides.
I've tried messing around with tabindex="0 / 1"; but then I need to put this on all the elements?
(sidenote: on the website are a lot more HTML elements above this 'slideshow' and I cannot change the structure that is given)
Thanks in advance!
The only way to change this order is to reorder your HTML elements.
tabindex itself can do 2 things:
it sets the order of "focusable" elements
it makes element "focusable".
tabindex = -1 Element will not get focus
tabindex = 0 Element will be focusable in the normal tab (semantic) order
tabindex = 1 Element with positive values will be focused first
There is no way to change the tab selection without using tabindex (or JavaScript).
jsfiddle
I am looking to disable a few html controls and I am running into cross browser issues with the differences between IE and Firefox/Webkit browsers. The primary issue is evident with the following line:
<input type="text" name="badIE" disabled="disabled" style="color:blue;" value="IE won't show this correctly" />
In IE, the above input would have grey text, while the text is blue in every other browser I have tested. It would appear that IE allows the disabled field of a text input to take precedence over the CSS rules for the text color. Is there any established best practice or IE CSS hack to address this type of issue?
According to the upvoted (but not accepted) answer here, you're kind of stuck with using 'readonly'.
Just out of curiousity - why are you displaying text in a textarea that you don't even want your users to be able to focus on? Seems to me you'd be better off displaying that in a regular text HTML element (e.g. <p>).
It turns out that there are few different ways to attack this problem but there isn't one exact answer. In order to provide the most complete answer possible, here is a list of the possible solutions.
Accept the differences between browsers and continue using the disabled field. This is probably the right answer. As chipcullen suggested on his comment, there is rarely a necessity that all browsers look identical. It is better to simply accept the differences between and work with them.
Use the readonly attribute instead of disabled. The problem with this method is that a user can still interact with a readonly control. For example, users could focus on the control or stick a blinking cursor in the middle of the text. If interaction is a major concern, you can always shield the disabled control behind an invisible element, although that method is on the hacky side.
The option I chose was to replace the input elements with a pure text element. Although this method might not be as straightforward as it might sound. My page was interactive and certain elements would be enabled/disabled depending on client side actions. In order to handle the transition, I threw together the following Javascript (after chipcullen's suggestion and with the help of jQuery):
function disabledToSpan() {
$('input[type=text]:disabled, textarea:disabled').replaceWith(function () {
return $('<span>' + $(this).val() + '</span>').attr('class',
$(this).attr('class')).addClass('disabledTextInput');
});
}
In summary, this will find all disabled text inputs and textareas, switch them to spans while preserving both their values and classes, before finally adding a disabledTextInput class to specially stylize the disabled elements.
Is there any alternative to <div>? My website is losing "accessibility" because I cannot set focus on a <div>. What control should I use in order to replicate <div> and still hold focus?
This is what my HTML looks like:
<div style="height:70px; overflow:hidden" id="divMsg">
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
</div>
You can add tabindex to make it focusable; however, this is usually not enough. If you want the element to be clickable, you will also need to add a keydown or keypress handler so that the user can activate it using ENTER, similar to a A link. Otherwise the user will be able to tab to it, but may not be able to do anything with the link after.
If you are trying to create a clickable element, it is sometimes simpler to start with a A tag, and then style it so that doesn't look like a link. A elements respond to both keyboard and mouse and fire onclick for both, so you don't have to do additional keyboard input handing like you do with a DIV.
Finally, if you are making a DIV or A that visually looks like a button or some other control, add the appropriate ARIA role so that a screenreader will call out the appropriate element type - eg.
Complete Transaction
Just give it a tabindex attribute.
If you are specifically looking for accessibility, try out the new HTML 5 tags like <article>. So for example a textreader knows what to read, and your page is much better structured.
Check out this site.
To answer your exact question, it depends why you are using the div; I'm guessing for layout. The tab ordering is dependent upon more than tabindex, as defaults and overflow affects positioning and focus.
To be more specific, you won't use a div to latch onto for tabindex. Rely upon JavaScript and a unique ID; <div class="content" id="page1">
This will also provide you an anchor so you could use http://index.html#divMsg to link focus to the exact place in your HTML document. Note you have only one div ID and reuse the same div class twice in your example.
If this is all new to you the article on difference between ID and CLASS may be of interest to you
Links (element a) and form elements (input text and alike, file, radio and checkbox, submit, image and type button, select, textarea, button element, etc) are focusable by default.
Thumb rule: if an element does something, it should be a link or a form element part of a form. (OT: I guess I've a problem with conjugation here but can't find exactly what - english isn't my mothertongue)
Think twice (at least :)) before using the tabindex attribute: it'll work for a while in your project and then you make some modification elsewhere and suddenly all is broken. And it'll break again, again and again.
For testing with Safari, you'll need to modify Preferences: this browser (maybe also Chrome?) only cycle by default through form elements and not links. Users of keyboard cycle through every focusable elements I guess, like in IE and Firefox.
To learn further, Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have Sufficient Techniques (and "Failure(s)" also) about keyboard use.
I want to practive, and even best-practice, with Html+JS+CSS.
I use a one page client-only Sudoku page.
My Sudoku markup is basically a <table>, with <td>.
(I'm open to suggestions to improve this).
My requirements :
Have a cell under focus (the keyboard notion of focus) (highlighed with css to a yellow background)
Navigate through cells with arrow keys (plus Home etc).
type-in an integer value sets that value to the currently focused cell
I use an input button inside each cell.
The Javascript works fine.
My only problem is with the display.
When a cell has the focus, it's highlighted display doesn't cover the whole TD, rather only the visual space included in the input button. I have some space around the button that isn't 'yellow'.
I don't think I could go up in the CSS selection, to select the parent of the input, could I ? Such as :
input:focus '?? how to go up ??' td { background-color:yellow;
I tried a few tricks, like having always 5 characters in each button display (5 spaces when empty, changing the middle character when set), but nothing is visually satisfying.
Even worse, it is clearly against best-practices to alter the content for the sake of visualizing. That's what the MVC distinction between Html/Css/Js is for !
I already searched this site for answer, I found close but distinct questions and answer.
I'm hoping someone could help improve my page ... and my markup skill :-)
It is not possible to construct a css selector which matches a parent node dependent on a (pseudo-)class of child node.
Basically you have two options to choose from:
Try to fill the td with the input completely using height and width rules in your css.
Set 'focused' and 'unfocused' class on your tds with javascript using the onfocus and onblur events of the inputs.
Could you not use a dash of jQuery to set a .focused class and then apply some style to it?