Hide input text
I what to hide an input element and the following text. I have the
selector for the input working and just need to grab the text following
it.
form display:table;
text-align:center;
>
form>input[value=»0″][name=»denominator»] visibility:hidden;
>
—
C.W.Holeman II | cw***@Julian5Locals.com-5 http://JulianLocals.com/cwhii
To only a fraction of the human race does God give the privilege of
earning one’s bread doing what one would have gladly pursued free, for
passion. I am very thankful. The Mythical Man-Month Epilogue/F.P.Brooks
I what to hide an input element and the following text. I have the
selector for the input working and just need to grab the text following
it.
form>input[value=»0″][name=»denominator»],form>input[value=»0″]
[name=»denominator»]+span visibility:hidden;
>
form>input:after
form>input[value=»0″][name=»denominator»],form>input[value=»0″]
[name=»denominator»]:after visibility:hidden;content:»»
>
No you don’t. It contains several constructs not supported by IE 6, which is
still the most common browser.
You should wrap interrelated radio buttons inside a
Then you can simply use
..dummy
After the input element, the text following it, in this case the «0».
No you don’t. It contains several constructs not supported by IE 6, I forgot to include:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3)
Gecko/20070309 Firefox/2.0.0.3
Windows Internet Explorer Version: 7.0.5730.11
The example I created produced the effect I am asking about on both of
the above browsers: they displayed two rows of radio buttons with the
buttons and text aligned vertically and the «0» denominator button was
hidden but the «0» text was visible.
I am not near the point of considering how that will effect what I am
doing. What is now the «most common browser» may be different or
irrelevant by release time.
Wrap the text inside an element and develop a suitable selector. I am hoping to not have to add that. If there is some selector that
will work without adding something like a span I would prefer to
understand that method.
4. There must be a DOCTYPE declaration in the document prior to the
root element. The public identifier included in the DOCTYPE
declaration must reference one of the three DTDs found in DTDs using
the respective Formal Public Identifier. The system identifier may be
changed to reflect local system conventions.
.
PUBLIC «-//W3C//DTD XHTML 1.0 Transitional//EN»
«http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd»>
I caught that in http://emle.sourceforge.net/emle020000/testf1.xsl
but missed it in the text of the posting.
I created a fragment to make it as easy as possible for readers to
follow my question. The two browsers I tested the example on appeared to
not be effected by the simplification.
You should wrap interrelated radio buttons inside a and you should associate labels with fields in markup, e.g. The sample I am using is just a fragment. Thank you for the reference to
how needed or related to the issue of hiding the «0»?
Then you can simply use
.dummy
Yes, that works. If that is the only solution I will use it but I would
like to not have to create an name like «dummy» to tie the XSL content
to the CSS file.
—
C.W.Holeman II | cw***@Julian5Locals.com-5 http://JulianLocals.com/cwhii
To only a fraction of the human race does God give the privilege of
earning one’s bread doing what one would have gladly pursued free, for
passion. I am very thankful. The Mythical Man-Month Epilogue/F.P.Brooks
Jukka K. Korpela wrote: >Scripsit C.W.Holeman II:
>>I what to hide an input element and the following text.
What?
An introduction with specific details shown below it. What I wondered wasn’t so much the details or the meaning of «what», which
is probably «want», but rather _why_ you would do such things. I can make
some guesses, but the idea of hiding the dummy preselected alternative —
which is probably what you are trying to achieve — is questionable. When
it’s hidden, a normal user has no way of restoring the setting to that
default, except by destroying the entire input data by using an eventual
destroy button (aka. «reset button»).
No you don’t. It contains several constructs not supported by IE 6,
I forgot to include:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3)
Gecko/20070309 Firefox/2.0.0.3
Windows Internet Explorer Version: 7.0.5730.11 No you didn’t. You forgot to check the topic of this group, which is CSS
authoring for the World Wide Web. Your personal choice of browser(s) is
ridiculously unimportant in this context. (The «ridiculously» part comes
from listing down the browsers down to the build of a variant of a minor
version.)
I am not near the point of considering how that will effect what I am
doing. Perhaps not much if you are not authoring for the WWW, but why did you post
to this group then and even claiming that something works when it clearly
doesn’t in the majority of cases on the WWW?
I am hoping to not have to add that. That’s wrong hope. You should use label markup anyway. When you add it, it
should be rather trivial to add the markup you need for styling.
That’s pointless.
From http://www.w3.org/TR/xhtml1/ Section 3.1.1. XHTML 1.0 is pointless on the WWW, and XHTML 1.0 Transitional even more so.
Besides, you are not actually complying with the DTD given, so what’s the
point?
I created a fragment to make it as easy as possible for readers to
follow my question. How would invalid markup help then?
And you should have posted a URL.
That’s one of your problems. You threw just a fragment of your problem at
us, and one that isn’t even a real extract from the real page. So you should
expect to get, at most, fragments of answers.
Then you can simply use
.dummy
Yes, that works. If that is the only solution I will use it With the given incomplete information, it pretty much is.
Css hide input value text
Note: The input and change events do not apply to this input type. Hidden inputs cannot be focused even using JavaScript (e.g. hiddenInput.focus() ).
Value
The element’s value attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This specifically can’t be edited or seen by the user via the user interface, although you could edit the value via browser developer tools.
Warning: While the value isn’t displayed to the user in the page’s content, it is visible—and can be edited—using any browser’s developer tools or «View Source» functionality. Do not rely on hidden inputs as a form of security.
Additional attributes
name
This is actually one of the common attributes, but it has a special meaning available for hidden inputs. Normally, the name attribute functions on hidden inputs just like on any other input. However, when the form is submitted, a hidden input whose name is set to _charset_ will automatically be reported with the value set to the character encoding used to submit the form.
Using hidden inputs
As mentioned above, hidden inputs can be used anywhere that you want to include data the user can’t see or edit along with the form when it’s submitted to the server. Let’s look at some examples that illustrate its use.
Tracking edited content
One of the most common uses for hidden inputs is to keep track of what database record needs to be updated when an edit form is submitted. A typical workflow looks like this:
- User decides to edit some content they have control over, such as a blog post, or a product entry. They get started by pressing the edit button.
- The content to be edited is taken from the database and loaded into an HTML form to allow the user to make changes.
- After editing, the user submits the form, and the updated data is sent back to the server to be updated in the database.
The idea here is that during step 2, the ID of the record being updated is kept in a hidden input. When the form is submitted in step 3, the ID is automatically sent back to the server with the record content. The ID lets the site’s server-side component know exactly which record needs to be updated with the submitted data.
You can see a full example of what this might look like in the Examples section below.
Improving website security
Hidden inputs are also used to store and submit security tokens or secrets, for the purposes of improving website security. The basic idea is that if a user is filling in a sensitive form, such as a form on their banking website to transfer some money to another account, the secret they would be provided with would prove that they are who they say they are, and that they are using the correct form to submit the transfer request.
This would stop a malicious user from creating a fake form, pretending to be a bank, and emailing the form to unsuspecting users to trick them into transferring money to the wrong place. This kind of attack is called a Cross Site Request Forgery (CSRF); pretty much any reputable server-side framework uses hidden secrets to prevent such attacks.
Note: Placing the secret in a hidden input doesn’t inherently make it secure. The key’s composition and encoding would do that. The value of the hidden input is that it keeps the secret associated with the data and automatically includes it when the form is sent to the server. You need to use well-designed secrets to actually secure your website.
Validation
Hidden inputs don’t participate in constraint validation; they have no real value to be constrained.
Examples
Let’s look at how we might implement a simple version of the edit form we described earlier (see Tracking edited content), using a hidden input to remember the ID of the record being edited.
The edit form’s HTML might look a bit like this:
form> div> label for="title">Post title:label> input type="text" id="title" name="title" value="My excellent blog post" /> div> div> label for="content">Post content:label> textarea id="content" name="content" cols="60" rows="5"> This is the content of my excellent blog post. I hope you enjoy it! textarea> div> div> button type="submit">Update postbutton> div> input type="hidden" id="postId" name="postId" value="34657" /> form>
Let’s also add some simple CSS:
html font-family: sans-serif; > form width: 500px; > div display: flex; margin-bottom: 10px; > label flex: 2; line-height: 2; text-align: right; padding-right: 20px; > input, textarea flex: 7; font-family: sans-serif; font-size: 1.1rem; padding: 5px; > textarea height: 60px; > The server would set the value of the hidden input with the ID » postID » to the ID of the post in its database before sending the form to the user’s browser and would use that information when the form is returned to know which database record to update with modified information. No scripting is needed in the content to handle this.
The output looks like this:
Note: You can also find the example on GitHub (see the source code, and also see it running live).
When submitted, the form data sent to the server will look something like this:
Even though the hidden input cannot be seen at all, its data is still submitted.
Technical summary
Specifications
Browser compatibility
BCD tables only load in the browser
See also
Found a content problem with this page?
This page was last modified on Mar 13, 2023 by MDN contributors.
Your blueprint for a better internet.
MDN
Support
Our communities
Developers
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.