The below HTML:
<html>
<body>
<label>field a</label>
<input name="foo1" value=""/><br/>
<label>field b</label><input name="foo2" value="" /><br/>
</body>
</html>
… renders the input of field a slightly off to the right due to the whitespace between the label and the first input element. However, looking at the DOM in Chrome I see this:
I.e. there is no representation of the text node in the DOM. Since the browser renders it with the extra space I think what's happenning is that a whitespace is indeed present in the DOM but the DOM viewer for some reason does not display it. If I understand correctly Firefox DevTools do in fact display whitespace text nodes (see this blog post). Is there anything similar for Chrome?
I don't think there is a way to display them in the DOM view.
However, I've noticed they are somewhat detectable in the Accessibility Tree:
Related
Creating a simple form.
Curious as to why the type='number' has different default size than type='text'?
Form looks like this. I believe with all defaults. Fiddle link below.
<form>
<label for='number' >Age:</label>
<input id='number' type='number' placeholder='Enter your age'>
<label for='name' >Name:</label>
<input id='name' type='text' placeholder='Enter your name'/>
</form>
https://jsfiddle.net/fnbkjcd3/2/
Short answer: that's just the way it is. Different browsers can - and will - implement different <input> types differently - sometimes VERY differently:
Numeric Inputs – A Comparison of Browser Defaults
MDN: input The Input (Form Input) element
MDN: input type="number"
PS:
I looked at your JSFiddle in FF and Chrome and - at least for me - the text input looked identical to the number input. I'm not sure why you're seeing them rendered "differently".
SUGGESTION:
Try to set font/size explicitly in CSS, and see if that makes a difference.
In case you didn’t know, every browser has its own default user agent stylesheet, that it uses to make unstyled websites appear more legible. So field size may vary among browsers, see the following two screenshot:
Firefox:
Chrome:
To apply a standard stylesheet among all 'user-agent' you can use cssrest.
The HTML tag <label> may not contain block elements by definition. The following code is wrong in HTML 4, although ist works in most browsers:
<input type="radio" value="A" name="ABC" id="ABC_A">
<label for="ABC_A">
<p>Option A</p>
<p>Having a good time with HTML.</p>
</label>
I could make a block element from the <label> via CSS, but this still remains invalid HTML code. And in some instances, it makes sense to format one label into multiple paragraphs.
My question is: Is there a valid way in HTML to use block elements as a label for an input?
Possible workarounds, that I have considered inappropriate are:
Creating one label within each paragraph (why should one input have a dozend labels - and which one should a screen reader read, then?)
Using JavaScript to have the input "clicked" when the block element is clicked. I am searching for a solution that will work without scripting (and that is supported by vommon screen readers)
And ideas? Thank you!
I have a hidden input field in my form. I noticed that if that field's value is changed by javascript, and then the user refreshes the page, that same value will be set when the page reloads. From what I've seen, this only happens in Firefox.
I've solved this unwanted behaviour by adding autocomplete="off" to that hidden input, but W3C doesn't like this solution, and if i validate the page I get the error:
Attribute autocomplete not allowed on element input at this point.
Apparently, the autocomplete attribute works only on specific inputs - see here.
So is there any solution that will satisfy both W3C and Firefox?
To validate (which I wouldn't put as much effort into as you are) I think you could use autocomplete="off" on the entire form, then turn it back on selectively, like this:
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<form autocomplete="off">
<input type="hidden" name="test">
<input type="text" name="otherfield" autocomplete="on">
</form>
</body>
</html>
I initially thought this was a Firefox bug but after discussion with robertc in the comments, I think expected behavior depends on specific use cases. The spec doesn't allow autocompletion on hidden fields so my first reaction still feels right, but Firefox's implementation might have some good arguments to support it. Please comment.
Alternatively, you could use <input type="text" style="display: none;" autocomplete="off" /> instead. It's a bit of a hack, but it should work!
The caching in Firefox is actually quite a good feature a lot of the time, but it does cause some problems when you build more dynamic forms.
I noticed the following bug when using $(selector).children().attr("disabled", "disabled") where the children happened to contain a <div>.
Fiddle
<div disabled="disabled">
<input type="text" value="RAGE" />
</div>
Basic testing says FF4/Chrome enable the field. IE9 disables the field.
What is the expected behaviour?
Same for any other non form element (<input>, <select>, etc)
<div> elements do not have a disabled attribute according to the HTML specification. The expected behavior is to prevent your markup from validating correctly.
However, the new HTML5 specification allows for <fieldset> to have a disabled attribute, which disables any nested input fields. It's not widely supported yet though, so you won't be able to rely on this feature for a while.
There is no disabled attribute for the div element. So it should have no effect.
on this page in IE 8, there is the famous phantom element bug. I have researched for two days all possible things I can find that might cause this, including hidden inputs (present) floated elements (not present) and HTML comments <!--...--> (present).
The "phantom element" is the grey div between the login div and the "ny kunde" button.
When trying to view this is the IE dev tools (F12) it cannot be selected, nor viewed. I believe it is because of a rendering issue in IE8.
Removing these did not help at all. Plus we apparently need the hidden input for form validation.
It's worth mentioning that this eCommerce solution doesn't validate out of the box.
I have exhausted every solution I can think of, and it is still present.
Does anyone have any suggestions?
Thanks :)
Starting at line 348, there is this code:
<input type="hidden" name="return" value="/checkout/selectAddress" />
</form>
</div>
If I change it to this:
<input type="hidden" name="return" value="/checkout/selectAddress" />
</div>
</form>
Then the problem is solved.
Simplifying (removing stuff from) your HTML:
<div id="user-wrapper">
<form action="/user/doLogin" method="post" id="loginForm" />
<div id="user-kundelogginn">
</form>
</div>
</div>
You can clearly see the form tag is being closed inside the div.
How did I figure this out?
I used the W3C Validator, which got me on the right track with this:
Line 350, Column 7: end tag for
element "form" which is not open