Why markup should be not only valid, but also logical. Life example
I work in a web-studio, constantly using the services of freelance designers. And if a few years ago, web designers often sent code that was full of markup errors, now this is already a rarity. Unfortunately, a completely different picture with the logic of markup, an automatic validator of which, as far as I know, is not yet available. In the hope of drawing the attention of layout designers to this side of their work, I want to tell you about a recent case that shows that the logic of markup is no less important than its validity.
And it was like that. The customer wanted the site to have “beautiful” input fields in the forms. The layout designer has used the custom-form-elements.js script for this. However, when the layout was installed on the CMS, it turned out that in some browsers, for example in FireFox, a double click is required to change the state of checkboxes, rather than a single click, as usual. The site programmer first suspected custom-form-elements.js. Another similar-purpose script solved the problem with check-boxes, but did not work for other reasons. The programmer started debugging the first script. When it did nothing, he turned to me. I also started by debugging the script and found that the onclick handler is mysteriously called twice. Then I decided to look at the markup, and this is what I saw:
')
Pay attention to the highlighted label. The custom-form-elements.js script hides input with the “styled” class and places a “box” of a check box in front of it. When you click on a span, custom-form-elements.js changes the state of hidden input. But besides the span, the event generated by the same click is passed to the label element that surrounds the span. Which broadcasts this event to the first input input enclosed in it . Thus, the state of the check-box changes twice - once JS, the second - the browser, which leads to the described problem. With all this, the label is completely unnecessary here, since it does not contain the actual label (signature). The signature is placed in a completely different label tag.
If the layout designer followed the logic, he would not wrap this input in a label, the custom-form-elements.js script would work correctly, and neither the programmer nor the layout designer would spend too much time eliminating the checkboxes.
And it was like that. The customer wanted the site to have “beautiful” input fields in the forms. The layout designer has used the custom-form-elements.js script for this. However, when the layout was installed on the CMS, it turned out that in some browsers, for example in FireFox, a double click is required to change the state of checkboxes, rather than a single click, as usual. The site programmer first suspected custom-form-elements.js. Another similar-purpose script solved the problem with check-boxes, but did not work for other reasons. The programmer started debugging the first script. When it did nothing, he turned to me. I also started by debugging the script and found that the onclick handler is mysteriously called twice. Then I decided to look at the markup, and this is what I saw:
<tr>
<td><label> :</label></td>
<td> <label> <input type="checkbox" class="styled" name="credit" value="yes"> </label> </td>
</tr>
')
Pay attention to the highlighted label. The custom-form-elements.js script hides input with the “styled” class and places a “box” of a check box in front of it. When you click on a span, custom-form-elements.js changes the state of hidden input. But besides the span, the event generated by the same click is passed to the label element that surrounds the span. Which broadcasts this event to the first input input enclosed in it . Thus, the state of the check-box changes twice - once JS, the second - the browser, which leads to the described problem. With all this, the label is completely unnecessary here, since it does not contain the actual label (signature). The signature is placed in a completely different label tag.
If the layout designer followed the logic, he would not wrap this input in a label, the custom-form-elements.js script would work correctly, and neither the programmer nor the layout designer would spend too much time eliminating the checkboxes.
Source: https://habr.com/ru/post/37345/
All Articles