From a5fcfafb665e96cae5d04dfba927db8dcdfd7f14 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Sun, 13 Dec 2020 17:16:08 -0500 Subject: 2020-12-13 --- files/ja/learn/forms/ui_pseudo-classes/index.html | 49 +++++++++++++---------- 1 file changed, 27 insertions(+), 22 deletions(-) (limited to 'files/ja/learn/forms/ui_pseudo-classes') diff --git a/files/ja/learn/forms/ui_pseudo-classes/index.html b/files/ja/learn/forms/ui_pseudo-classes/index.html index 8ab11cbac6..36c83f9155 100644 --- a/files/ja/learn/forms/ui_pseudo-classes/index.html +++ b/files/ja/learn/forms/ui_pseudo-classes/index.html @@ -15,7 +15,7 @@ translation_of: Learn/Forms/UI_pseudo-classes ---

{{LearnSidebar}}{{PreviousMenuNext("Learn/Forms/Advanced_form_styling", "Learn/Forms/Form_validation", "Learn/Forms")}}

-

In the previous articles we covered the styling of various form controls, in a general manner. This included some usage of pseudo-classes, 例えば、using :checked to target a checkbox only when it is selected. In this article, we will explore in detail the different UI pseudo-classes available to us in modern browsers for styling forms in different states.

+

In the previous articles, we covered the styling of various form controls, in a general manner. This included some usage of pseudo-classes, 例えば、using :checked to target a checkbox only when it is selected. In this article, we will explore in detail the different UI pseudo-classes available to us in modern browsers for styling forms in different states.

@@ -49,7 +49,7 @@ translation_of: Learn/Forms/UI_pseudo-classes
  • {{cssxref(":checked")}}, {{cssxref(":indeterminate")}}, and {{cssxref(":default")}}: Respectively target checkboxes and radio buttons that are checked, in an indeterminate state (neither checked or not checked), and the default selected option when the page loads (e.g. an <input type="checkbox"> with the checked attribute set, or an <option> element with the selected attribute set).
    • -

    There are many others too, but the ones listed above are the most obviously useful. Some of the others are aimed at solving very specific niche problems, or simply not very well supported in browsers yet. The ones listed above all have pretty good browser support, but of course you should test your form implementations carefully to make sure they work for your target audience.

    +

    There are many others too, but the ones listed above are the most obviously useful. Some of the others are aimed at solving very specific niche problems, or simply not very well supported in browsers yet. The ones listed above all have pretty good browser support, but of course, you should test your form implementations carefully to make sure they work for your target audience.

    注: A number of the pseudo-classes discussed here are concerned with styling form controls based on their validation state (is their data valid, or not?) You'll learn much more about setting and controlling validation constraints in our next article — Client-side form validation — but for now we'll keep things simple with regards to form validation, so it doesn't confuse things.

    @@ -96,11 +96,11 @@ input:optional {

    {{EmbedGHLiveSample("learning-area/html/forms/pseudo-classes/basic-required-optional.html", '100%', 400)}}

    -

    You can also try submitting the form without flling it in, to see the client-side validation error messages browsers give you 既定では.

    +

    You can also try submitting the form without filling it in, to see the client-side validation error messages browsers give you 既定では.

    The above form isn't bad, but it isn't great either. For a start, we are signalling required versus optional status using color alone, which isn't great for colorblind people. Second, the standard convention on the web for required status is an asterisk (*), or the word "required" being associated with the controls in question.

    -

    In the next section we'll look at a better example of indicating required fields using :required, which also digs into using generated content.

    +

    In the next section, we'll look at a better example of indicating required fields using :required, which also digs into using generated content.

    注: You'll probably not find yourself using the :optional pseudo-class very often. Form controls are optional 既定では, so you could just do your optional styling 既定では, and add styles on top for required controls.

    @@ -112,7 +112,7 @@ input:optional {

    疑似クラスでコンテンツを生成する

    -

    In previous articles we've seen usage of generated content, but we thought now would be a good time to talk about it in a bit more detail.

    +

    In previous articles, we've seen the usage of generated content, but we thought now would be a good time to talk about it in a bit more detail.

    The idea is that we can use the ::before and ::after pseudo-elements along with the content property to make a chunk of content appear before or after the affected element. The chunk of content is not added to the DOM, so is invisible to screenreaders; it is part of the document's styles. Because it is a pseudo element, it can be targetted with styles in the same way that any actual DOM node can.

    @@ -158,7 +158,7 @@ input[type="radio"]:checked::before { <span></span> </div> -

    The immediate problem with this was that the span was dropping onto a new line below the input, because the input and label are both set with width: 100%. To fix this we style the parent <div> to become a flex container, but also tell it to wrap its contents onto new lines if the content becomes too long:

    +

    The immediate problem with this was that the span was dropping onto a new line below the input because the input and label are both set with width: 100%. To fix this we style the parent <div> to become a flex container, but also tell it to wrap its contents onto new lines if the content becomes too long:

    fieldset > div {
   margin-bottom: 20px;
@@ -263,7 +263,7 @@ input:valid + span::before {
 
    注: Numeric input types are date, month, week, time, datetime-local, number, and range.
    -

    It is worth noting that inputs whose data is in-range will also be matched by the :valid pseudo-class, and inputs whose data is out-of-range will also be matched by the :invalid pseudo-class. So why have both? The issue is really one of semantics — out-of-range is a more specific type of invalid communication, so you might want to provide a different message for out-of-range inputs, which will be more helpful to users than just saying "invalid". You might even want to provide both.

    +

    It is worth noting that inputs whose data is in-range will also be matched by the :valid pseudo-class and inputs whose data is out-of-range will also be matched by the :invalid pseudo-class. So why have both? The issue is really one of semantics — out-of-range is a more specific type of invalid communication, so you might want to provide a different message for out-of-range inputs, which will be more helpful to users than just saying "invalid". You might even want to provide both.

    Let's look at an example that does exactly this. Our out-of-range.html demo (see also the source code) builds on top of the previous example to provide out-of-range messages for the numeric inputs, as well as saying whether they are required.

    @@ -362,7 +362,7 @@ input:out-of-range + span::after { <div><button>Submit</button></div> </form> -

    Now onto the CSS. The most relevant parts to this example are as follows:

    +

    Now onto the CSS. The most relevant parts of this example are as follows:

    input[type="text"]:disabled {
     background: #eee;
@@ -424,26 +424,27 @@ function toggleBilling() {
          value="Mr Soft" readonly>
 </div>
    -

    If you try the live example, you'll see that the top set of form elements are not focusable, however the values are submitted when the form is submitted. We've also styled the read-only form controls using the :read-only pseudo-class, like so:

    +

    If you try the live example, you'll see that the top set of form elements are not focusable, however the values are submitted when the form is submitted. We've styled the form controls using the :read-only and :read-write pseudo-classes, like so:

    -
    input:-moz-read-only, textarea:-moz-read-only {
-  border: 0;
-  box-shadow: none;
-  resize: none;
-  background-color: white;
+
    input:-moz-read-only, textarea:-moz-read-only,
+input:read-only, textarea:read-only {
+  border: 0;
+  box-shadow: none;
+  background-color: white;
 }
 
-input:read-only, textarea:read-only {
-  border: 0;
-  box-shadow: none;
-  resize: none;
-  background-color: white;
+textarea:-moz-read-write,
+textarea:read-write {
+  box-shadow: inset 1px 1px 3px #ccc;
+  border-radius: 5px;
 }
    
 
-
    Yes, you've guessed it — Firefox only supports it with a prefix, hence having to double up the ruleset.
    
+
    Firefox only supported these pseudo-classes with a prefix up to version 78; at which point it started to support the unprefixed version. The full example looks like so:
    
+
+
    {{EmbedGHLiveSample("learning-area/html/forms/pseudo-classes/readonly-confirmation.html", '100%', 660)}}
    
 
 
    
-
    注: :enabled and read-write are two more pseudo-classes that you'll probably rarely use, given that they describe the default states of input elements.
    
+
    注: :enabled and :read-write are two more pseudo-classes that you'll probably rarely use, given that they describe the default states of input elements.
    
 
    
 
 
    ラジオとチェックボックスの状態 — チェック済み、既定、中間
    
@@ -459,7 +460,7 @@ input:read-only, textarea:read-only {
 
 
    When checked, they will be matched by the {{cssxref(":checked")}} pseudo-class.
    
 
-
    The most common use of this is to add a different style onto the checkbox/radiobutton when it is checked, in cases where you've removed the system default styling with appearance: none; and want to build the styles back up yourself. We saw examples of this in the previous article, when we talked about Using appearence: none on radios/checkboxes.
    
+
    The most common use of this is to add a different style onto the checkbox/radiobutton when it is checked, in cases where you've removed the system default styling with appearance: none; and want to build the styles back up yourself. We saw examples of this in the previous article when we talked about Using appearence: none on radios/checkboxes.
    
 
 
    As a recap, the :checked code from our Styled radio buttons example looks like so:
    
 
@@ -586,6 +587,10 @@ input:default ~ span::after {
  
  • The :user-invalid pseudo-class, when supported, will be similar to {{cssxref(":invalid")}}, but with better user experience. If the value is valid when the input receives focus, the element may match :invalid as the user enters data if the value is temporarily invalid, but will only match :user-invalid when the element loses focus. If the value was originally invalid, it will match both :invalid and :user-invalid for the whole duration of the focus. In a similar manner to :invalid, it will stop matching :user-invalid if the value does become valid.
    • 
 
 
+
    Test your skills!
    
+
+
    You've reached the end of this article, but can you remember the most important information? You can find some further tests to verify that you've retained this information before you move on — see Test your skills: Advanced styling.
    
+
 
    まとめ
    
 
 
    This completes our look at UI pseudo-classes that relate to form inputs. Keep playing with them, and create some fun form styles! Next up, we'll move on to something different — client-side form validation.
    
-- 
cgit v1.2.3-54-g00ecf