2020-12-13

1 files changed, 27 insertions, 22 deletions

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
 ---
 <p>{{LearnSidebar}}{{PreviousMenuNext("Learn/Forms/Advanced_form_styling", "Learn/Forms/Form_validation", "Learn/Forms")}}</p>
 
-<p>In the previous articles we covered the styling of various form controls, in a general manner. This included some usage of pseudo-classes, 例えば、using <code>:checked</code> to target a checkbox only when it is selected. <span class="seoSummary">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.</span></p>
+<p>In the previous articles, we covered the styling of various form controls, in a general manner. This included some usage of pseudo-classes, 例えば、using <code>:checked</code> to target a checkbox only when it is selected. <span class="seoSummary">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.</span></p>
 
 <table class="learn-box standard-table">
  <tbody>
@@ -49,7 +49,7 @@ translation_of: Learn/Forms/UI_pseudo-classes
  <li>{{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 <code><a href="/ja/docs/Web/HTML/Element/input/checkbox">&lt;input type="checkbox"&gt;</a></code> with the <code>checked</code> attribute set, or an <code><a href="/ja/docs/Web/HTML/Element/option">&lt;option&gt;</a></code> element with the <code>selected</code> attribute set).</li>
 </ul>
 
-<p>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.</p>
+<p>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.</p>
 
 <div class="blockIndicator note">
 <p><strong>注</strong>: 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 — <a href="/ja/docs/Learn/Forms/Form_validation">Client-side form validation</a> — but for now we'll keep things simple with regards to form validation, so it doesn't confuse things.</p>
@@ -96,11 +96,11 @@ input:optional {
 
 <p>{{EmbedGHLiveSample("learning-area/html/forms/pseudo-classes/basic-required-optional.html", '100%', 400)}}</p>
 
-<p>You can also try submitting the form without flling it in, to see the client-side validation error messages browsers give you 既定では.</p>
+<p>You can also try submitting the form without filling it in, to see the client-side validation error messages browsers give you 既定では.</p>
 
 <p>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.</p>
 
-<p>In the next section we'll look at a better example of indicating required fields using <code>:required</code>, which also digs into using generated content.</p>
+<p>In the next section, we'll look at a better example of indicating required fields using <code>:required</code>, which also digs into using generated content.</p>
 
 <div class="blockIndicator note">
 <p><strong>注</strong>: You'll probably not find yourself using the <code>:optional</code> pseudo-class very often. Form controls are optional 既定では, so you could just do your optional styling 既定では, and add styles on top for required controls.</p>
@@ -112,7 +112,7 @@ input:optional {
 
 <h2 id="Using_generated_content_with_pseudo-classes" name="Using_generated_content_with_pseudo-classes">疑似クラスでコンテンツを生成する</h2>
 
-<p>In previous articles we've seen usage of <a href="/ja/docs/Web/CSS/CSS_Generated_Content">generated content</a>, but we thought now would be a good time to talk about it in a bit more detail.</p>
+<p>In previous articles, we've seen the usage of <a href="/ja/docs/Web/CSS/CSS_Generated_Content">generated content</a>, but we thought now would be a good time to talk about it in a bit more detail.</p>
 
 <p>The idea is that we can use the <code><a href="/ja/docs/Web/CSS/::before">::before</a></code> and <code><a href="/ja/docs/Web/CSS/::after">::after</a></code> pseudo-elements along with the <code><a href="/ja/docs/Web/CSS/content">content</a></code> 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.</p>
 
@@ -158,7 +158,7 @@ input[type="radio"]:checked::before {
   &lt;span&gt;&lt;/span&gt;
 &lt;/div&gt;</pre>
 
-<p>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 <code>width: 100%</code>. To fix this we style the parent <code>&lt;div&gt;</code> to become a flex container, but also tell it to wrap its contents onto new lines if the content becomes too long:</p>
+<p>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 <code>width: 100%</code>. To fix this we style the parent <code>&lt;div&gt;</code> to become a flex container, but also tell it to wrap its contents onto new lines if the content becomes too long:</p>
 
 <pre class="brush: css notranslate">fieldset &gt; div {
   margin-bottom: 20px;
@@ -263,7 +263,7 @@ input:valid + span::before {
 <p><strong>注</strong>: Numeric input types are <code>date</code>, <code>month</code>, <code>week</code>, <code>time</code>, <code>datetime-local</code>, <code>number</code>, and <code>range</code>.</p>
 </div>
 
-<p>It is worth noting that inputs whose data is in-range will also be matched by the <code>:valid</code> pseudo-class, and inputs whose data is out-of-range will also be matched by the <code>:invalid</code> 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.</p>
+<p>It is worth noting that inputs whose data is in-range will also be matched by the <code>:valid</code> pseudo-class and inputs whose data is out-of-range will also be matched by the <code>:invalid</code> 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.</p>
 
 <p>Let's look at an example that does exactly this. Our <a href="https://mdn.github.io/learning-area/html/forms/pseudo-classes/out-of-range.html">out-of-range.html</a> demo (see also the <a href="https://github.com/mdn/learning-area/blob/master/html/forms/pseudo-classes/out-of-range.html">source code</a>) 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.</p>
 
@@ -362,7 +362,7 @@ input:out-of-range + span::after {
   &lt;div&gt;&lt;button&gt;Submit&lt;/button&gt;&lt;/div&gt;
 &lt;/form&gt;</pre>
 
-<p>Now onto the CSS. The most relevant parts to this example are as follows:</p>
+<p>Now onto the CSS. The most relevant parts of this example are as follows:</p>
 
 <pre class="brush: css notranslate">input[type="text"]:disabled {
     background: #eee;
@@ -424,26 +424,27 @@ function toggleBilling() {
          value="Mr Soft" readonly&gt;
 &lt;/div&gt;</pre>
 
-<p>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 <code>:read-only</code> pseudo-class, like so:</p>
+<p>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 <code>:read-only</code> and <code>:read-write</code> pseudo-classes, like so:</p>
 
-<pre class="brush: css notranslate">input:-moz-read-only, textarea:-moz-read-only {
-  border: 0;
-  box-shadow: none;
-  resize: none;
-  background-color: white;
+<pre class="brush: css notranslate">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;
 }</pre>
 
-<p>Yes, you've guessed it — Firefox only supports it with a prefix, hence having to double up the ruleset.</p>
+<p>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:</p>
+
+<p>{{EmbedGHLiveSample("learning-area/html/forms/pseudo-classes/readonly-confirmation.html", '100%', 660)}}</p>
 
 <div class="blockIndicator note">
-<p><strong>注</strong>: <code>:enabled</code> and <code>read-write</code> are two more pseudo-classes that you'll probably rarely use, given that they describe the default states of input elements.</p>
+<p><strong>注</strong>: <code>:enabled</code> and <code>:read-write</code> are two more pseudo-classes that you'll probably rarely use, given that they describe the default states of input elements.</p>
 </div>
 
 <h2 id="ラジオとチェックボックスの状態_—_チェック済み、既定、中間">ラジオとチェックボックスの状態 — チェック済み、既定、中間</h2>
@@ -459,7 +460,7 @@ input:read-only, textarea:read-only {
 
 <p>When checked, they will be matched by the {{cssxref(":checked")}} pseudo-class.</p>
 
-<p>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 <code>appearance: none;</code> and want to build the styles back up yourself. We saw examples of this in the previous article, when we talked about <a href="/ja/docs/Learn/Forms/Advanced_form_styling#Using_appearence_none_on_radioscheckboxes">Using <code>appearence: none</code> on radios/checkboxes</a>.</p>
+<p>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 <code>appearance: none;</code> and want to build the styles back up yourself. We saw examples of this in the previous article when we talked about <a href="/ja/docs/Learn/Forms/Advanced_form_styling#Using_appearence_none_on_radioscheckboxes">Using <code>appearence: none</code> on radios/checkboxes</a>.</p>
 
 <p>As a recap, the <code>:checked</code> code from our <a href="https://mdn.github.io/learning-area/html/forms/styling-examples/radios-styled.html">Styled radio buttons</a> example looks like so:</p>
 
@@ -586,6 +587,10 @@ input:default ~ span::after {
  <li>The <code><a href="https://drafts.csswg.org/selectors-4/#user-invalid-pseudo">:user-invalid</a></code> 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 <code>:invalid</code> as the user enters data if the value is temporarily invalid, but will only match <code>:user-invalid</code> when the element loses focus. If the value was originally invalid, it will match both <code>:invalid</code> and <code>:user-invalid</code> for the whole duration of the focus. In a similar manner to <code>:invalid</code>, it will stop matching <code>:user-invalid</code> if the value does become valid.</li>
 </ul>
 
+<h2 id="Test_your_skills!">Test your skills!</h2>
+
+<p>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 <a href="https://wiki.developer.mozilla.org/en-US/docs/Learn/Forms/Test_your_skills:_Advanced_styling">Test your skills: Advanced styling</a>.</p>
+
 <h2 id="Summary" name="Summary">まとめ</h2>
 
 <p>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 — <a href="/ja/docs/Learn/Forms/Form_validation">client-side form validation</a>.</p>