You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the big issues with HTML Forms is styling form widgets with CSS. Form controls appearance is browser and operating system specific. For example, the input of color type looks different in Safari, Chrome and Firefox browser, but the color picker widget is the same in all browsers on a device as it opens up the operating system's native color picker.
92
+
One of the big issues with HTML forms in legacy browsers is styling them with CSS. As covered elsewhere, you can declare {{cssxref('appearance', 'appearance: none;')}} to remove the default styles and build your own on top. However, legacy browsers are less likely than modern browsers to support the styling techniques covered earlier in the module. It might be better to just leave form controls unstyled in legacy browsers, if you need to support them. See the next section for advice on detecting support for specific input types.
92
93
93
-
It's generally a good idea to not alter the default appearance of form control because altering one CSS property value may alter some input types but not others. For example, if you declare `input { font-size: 2rem; }`, it will impact `number`, `date`, and `text`, but not `color` or `range`. If you alter a property, that may impact the appearance of the widget in unexpected ways. For example, `[value] { background-color: #cccccc; }` may have been used to target every {{HTMLElement("input")}} with a `value` attribute, but changing the background-color or border radius on a {{HTMLElement("meter")}} will lead to likely unexpected results that differ across browsers. You can declare {{cssxref('appearance', 'appearance: none;')}} to remove the browser styles, but that generally defeats the purpose: as you lose all styling, removing the default look and feel your visitors are used to.
94
-
95
-
To summarize, when it comes to styling form control widgets, the side effects of styling them with CSS can be unpredictable. So don't. Even if it's still possible to do a few adjustments on text elements (such as sizing or font color), there are always side effects. The best approach remains to not style HTML Form widgets at all. But you can still apply styles to all the surrounding items. And, if you must alter the default styles of your form widgets, define a style guide to ensure consistency among all your form controls so user experience is not destroyed. You can also investigate some hard techniques such as [rebuilding widgets with JavaScript](/en-US/docs/Learn_web_development/Extensions/Forms/How_to_build_custom_form_controls). But in that case, do not hesitate to [charge your client for such foolishness](https://www.smashingmagazine.com/2011/11/but-the-client-wants-ie-6-support/).
94
+
If you must alter the default styles of your form widgets in legacy browsers, define a style guide to ensure consistency among all your form controls so user experience is not destroyed. You could also investigate some hard techniques such as [rebuilding widgets with JavaScript](/en-US/docs/Learn_web_development/Extensions/Forms/How_to_build_custom_form_controls), but it might be more trouble than it's worth.
96
95
97
96
## Feature detection and polyfills
98
97
99
-
CSS and JavaScript are awesome technologies, but it's important to ensure you don't break legacy browsers. Before using features that aren't fully supported in the browsers your targeting, you should feature detect:
98
+
CSS and JavaScript are awesome technologies, but it's important to ensure you don't break legacy browsers. Before using features that aren't fully supported in the browsers your targeting, you should feature detect.
100
99
101
100
### CSS feature detection
102
101
@@ -113,14 +112,42 @@ Before styling a replaced form control widget, you can check to see if the brows
113
112
114
113
The {{cssxref('appearance')}} property can be used to display an element using platform-native styling, or, as is done with the value of `none`, remove default platform-native based styling.
115
114
115
+
### JavaScript form input detection
116
+
117
+
You can use JavaScript to detect whether a particular input type is supported. This is based on the fact we mentioned before — that every input type falls back to `<input type="text">` in non-supporting browsers.
118
+
119
+
1. Define a test function. The first line of the function body should create a test `<input>` element:
120
+
121
+
```js
122
+
functiontestDatetimeLocalSupport() {
123
+
consttestInput=document.createElement("input");
124
+
```
125
+
126
+
2. Next, set its `type` attribute to the type you want to test:
127
+
128
+
```js-nolint
129
+
testInput.setAttribute("type", "datetime-local");
130
+
```
131
+
132
+
3. Now test the `type` attribute value. In browsers that don't support that input type, the last line will have no effect and the `type` will be returned as `text`. In the below line we are inverting the return value using the negation operator (`!`) because if the `type` isn't `text`, then the type is supported, so we want to return `true`:
133
+
134
+
```js
135
+
returntestInput.type!=="text";
136
+
}
137
+
```
138
+
139
+
The above example shows the basic idea behind such tests. Instead of reinventing the wheel, however, you should use a feature detection library such as [Modernizr](https://modernizr.com/) to handle such tests.
140
+
141
+
Based on the results of that test, you could then for example choose to use JavaScript to build a custom replacement for the non-supported type, or not apply a stylesheet that styles the non-supported type because you want to provide simple default styles to legacy browsers.
142
+
116
143
### Unobtrusive JavaScript
117
144
118
145
One of the biggest problems is the availability of APIs. For that reason, it's considered best practice to work with "unobtrusive" JavaScript. It's a development pattern that defines two requirements:
119
146
120
147
- A strict separation between structure and behaviors.
121
148
- If the code breaks, the content and the basic functionalities must remain accessible and usable.
122
149
123
-
[The principles of unobtrusive JavaScript](https://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript) (originally written by Peter-Paul Koch for Dev.Opera.com) describes these ideas very well.
150
+
[The principles of unobtrusive JavaScript](https://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript) (originally written by Peter-Paul Koch for dev.opera.com) describes these ideas very well.
Copy file name to clipboardExpand all lines: files/en-us/learn_web_development/extensions/forms/index.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,22 +54,23 @@ The above text is a good indicator as to why we've put web forms into its own st
54
54
-[Sending form data](/en-US/docs/Learn_web_development/Extensions/Forms/Sending_and_retrieving_form_data)
55
55
- : This article looks at what happens when a user submits a form — where does the data go, and how do we handle it when it gets there? We also look at some of the security concerns associated with sending form data.
56
56
57
-
## Additional articles
57
+
## Additional tutorials
58
58
59
59
The following articles aren't included in the learning pathway, but they'll prove interesting and useful when you've mastered the above techniques and want to know more.
60
60
61
61
-[How to build custom form controls](/en-US/docs/Learn_web_development/Extensions/Forms/How_to_build_custom_form_controls)
62
62
- : You'll come across some cases where the native form widgets just don't provide what you need, e.g., because of styling or functionality. In such cases, you may need to build your own form widget out of raw HTML. This article explains how you'd do this and the considerations you need to be aware of when doing so, with a practical case study.
63
63
-[Sending forms through JavaScript](/en-US/docs/Learn_web_development/Extensions/Forms/Sending_forms_through_JavaScript)
64
64
- : This article looks at ways to use a form to assemble an HTTP request and send it via custom JavaScript, rather than standard form submission. It also looks at why you'd want to do this, and the implications of doing so. (See also [Using FormData objects](/en-US/docs/Web/API/XMLHttpRequest_API/Using_FormData_Objects).)
- : This article explains how to use dedicated, modern HTML and CSS features together to create fully-customized {{htmlelement("select")}} elements.
65
+
-[HTML forms in legacy browsers](/en-US/docs/Learn_web_development/Extensions/Forms/HTML_forms_in_legacy_browsers)
66
+
- : This article provides tips and tricks to help ease the pain if, and when, you need to support legacy browsers with your HTML forms.
67
+
-[User input methods and controls](/en-US/docs/Learn_web_development/Extensions/Forms/User_input_methods)
68
+
- : This article shows the different ways that users interact with forms and other web content, and provides recommendations for managing user input, real-world examples, and links to further information.
67
69
68
70
## See also
69
71
70
72
-[HTML forms element reference](/en-US/docs/Web/HTML/Reference/Elements#forms)
We've discussed the importance of web performance. You've learned what you need to do to optimize for web performance. But how do you convince your clients and/or management to prioritize and invest in performance? In this section, we discuss creating a clear business case to convince decision-makers to make the investment.
12
12
@@ -55,4 +55,4 @@ Setting key performance indicators (KPI) as objectives can highlight performance
55
55
56
56
Setting conversion rate, time on site, and/or net promotion scores as KPIs give financial and other business goal value to the web performance efforts, and get help boost buy-in, with metrics to prove the efforts worth.
Copy file name to clipboardExpand all lines: files/en-us/learn_web_development/extensions/performance/index.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,11 +43,11 @@ It would also be helpful to go a bit deeper into these topics, with modules such
43
43
- : CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.
44
44
-[The business case for web performance](/en-US/docs/Learn_web_development/Extensions/Performance/business_case_for_performance)
45
45
- : There are many things a developer can do to improve performance, but how fast is fast enough? How can you convince powers that be of the importance of these efforts? Once optimized, how can you ensure bloat doesn't come back? In this article we look at convincing management, developing a performance culture and performance budget, and introduce ways to ensure regressions don't sneak into your code base.
46
+
-[Web Performance best practices & tips](/en-US/docs/Learn_web_development/Extensions/Performance/Best_practices)
47
+
- : This article covers several topics at a basic level and provides links to deeper dives to improve performance for each topic. In addition to front-end topics such as HTML, CSS, JavaScript, and media files, it also covers APIs, developer tools, best practices, and bad practices relating to web performance.
- : In addition to the front end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, developer tools, best practices, and bad practices relating to web performance. Here we'll introduce many of these features at the basic level and provide links to deeper dives to improve performance for each topic.
- : In this article, we'll learn about the concept of responsive images — images that work well on devices with widely differing screen sizes, resolutions, and other such features — and look at what tools HTML provides to help implement them. This helps to improve performance across different devices. Responsive images are just one part of [responsive design](/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design), a future CSS topic for you to learn.
53
53
-[Main web performance section on MDN](/en-US/docs/Web/Performance)
0 commit comments