A presentation at FrontCon in in Riga, Latvia by Stephanie Stimac
Standardizing <select>: What the future holds for HTML Controls FrontCon 2020
Hi! I’m Stephanie. Program Manager for Microsoft Edge Developer Experiences @seaotta
Hi! I’m Stephanie. Designer Front-end developer Dev and Designer Advocate @seaotta
Designer Developer
Mock up Production Site
HTML Controls
Standardizing <select> The Past: why HTML Controls are the way they are The Present: where we’re at now The Future: what’s to come with HTML Controls (select!)
Some History HTML Form Controls
1995
1995
1995
1995
Pre1995
<HTML> 1.0Pre1995
<HTML> 🚫 1.0The primary focus of the specification draft was to capture common HTML practice in web browsers as of June 1994. http://www.blooberry.com/indexdot/history/html20.html
Web Browsers 1991-1994 WorldWideWeb (Nexus) ViolaWWW Erwise MidasWWW MacWWW Mosaic Wikipedia Cello Lynx 2.0 Arena AMosaic 1.0 IBM WebExplorer Netscape Navigator SlipKnot 1.0 MacWeb Ibrowse Agora (Argo) Minuet
1995
1995
1995
CSS IS AWESOME
1997 CSS IS AWESOME
1999
<HTML> 4.01 ❤ CSS IS AWESOME1995
https://www.456bereastreet.com/archive/200409/styling_form_controls/
.form { -webkit-appearance: value; -moz-appearance: value; appearance: value; }
Recap Pre-1995: Lots of browsers pop up 1994: HTML 1.0 draft expires 1995: HTML 2.0 becomes standardized spec Basic HTML form controls standardized No standard for styling Operating system dependency 1999: CSS Supported by HTML 4.01 embraced by more browsers
1999 – present
The Current State of Styling Native Controls
It’s not bad…
But it’s not great either.
Feasibility of Styling Form Controls with CSS
Feasibility of Styling Form Controls with CSS Can be styled with few problems <form> <fieldset> <label> <output> Text-field (<input>) Buttons
Feasibility of Styling Form Controls with CSS Can be styled with few problems Can be styled with complex CSS and hacks
<form> <fieldset> <label> <output> Text-field (<input>) Buttons Checkboxes Radios <legend>Feasibility of Styling Form Controls with CSS Can be styled with few problems Can be styled with complex CSS and hacks Good night and good luck.
<form> <fieldset> <label> <output> Text-field (<input>) Buttons Checkboxes Radios <legend> <select> <option> <optgroup> <datalist> <progress> <meter> Color picker Date controls Dropdown widgets Range File pickerFeasibility of Styling Form Controls with CSS Can be styled with few problems Can be styled with complex CSS and hacks Good night and good luck.
<form> <fieldset> <label> <output> Text-field (<input>) Buttons Checkboxes Radios <legend> <select> <option> <optgroup> <datalist> <progress> <meter> Color picker Date controls Dropdown widgets Range File picker“CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.”
Browser Inconsistencies
Browser Inconsistencies Chrome EdgeHTML Firefox Safari
No extensibility
<video controls width=”1080”> </video>
<video controls width=”1080”> </video>
<video width=”1080”> </video>
Dribbble: Jordan Ranson
Dribbble: Mark Hendriks Dribbble: Seb kay
What do developers really want?
Do they really want better form controls?
Initial Research 1400 respondents
Initial Research: Demographics Full results: https://aka.ms/controls-survey
Initial Research: Demographics Full results: https://aka.ms/controls-survey
Top 10 Re-created Form Controls Full results: https://aka.ms/controls-survey
Reasons Controls Are Created Full results: https://aka.ms/controls-survey
JSConfEU Survey Which form control gives you the most frustration? Why?
JSConfEU Survey Which form control gives you the most frustration?
JSConfEU Survey Why?
“ Requires hacky tricks
“ Can’t style <option> elements at all to the extent we need to
“ …but the amount of work it takes to implement an accessible alternative with complete feature parity is massive.
How painful is it?
TM Important Research
🤬
Clearly, there is an issue
The Future
✨
HTML isn’t done
New Styles & Accessibility Improvements
Chromium Controls Visual Refresh
New Native Components
New native components <virtual-list> https://aka.ms/virtual-scroller <toggle-switch> https://aka.ms/toggle-switch
New native components <virtual-list> More info: https://aka.ms/virtual-scroller
New native components <toggle-switch> More info + links to prototype: https://aka.ms/toggle-switch
From proposal to standard 1. Proposal incubates in the WICG 2. After incubation, multi-implementer interest is required before graduating to an HTML standard
Tell other implementers what you want! 1. @mozhacks on Twitter 2. Mozilla Firefox Platform Status: https://github.com/mozilla/platform-status 3. @webkit on Twitter 4. WebKit Platform Status: https://webkit.org/status/
Fixing the current problems with controls
Customizing Controls UI
Customizing Controls UI Explainer MVC Design Pattern Model (data members, capabilities of control) Controller (intermediary between model and view) View (user interface)
Goals • Style any arbitrary part of a native control • Add arbitrary content into a control • Style a particular part without rewriting the whole UI • Customize UI without reimplementing the data model and code for reacting to user input • Customized controls are accessible by default
3 Customization Options • Using standardized parts and states to override the native control styles via pseudo-classes and pseudo-elements. • Using named <slots> to replace parts of the native control UI with developer content, while optionally leaving some native parts in place. • Replacing the entire UI of the native control with an authorsupplied shadow root.
Solution 1: Standardized Control UI anatomy, parts and behavior
Solution 1: Standardized Control UI anatomy, parts and behavior aka.ms/open-ui
Goals of Open UI • Document component names as they exist today • Define a common language for describing UIs and design systems • Eventual browser standards for web app components • Converging designer processes and developer workflows
<select> investigation
The anatomy of a <select>
<select class=”styled-select”> <option>choice 1</option> <option>choice 2</option> </select>
Solution 2: Named Slots
Standardized Slots
Standardized Slots slot=button slot=listbox
<select> <div slot=“button” part=“button” class=“custom-button”>Choose a pet</div> <div slot=“listbox” part=“listbox” class=“custom-listbox”> <option> <img src=“./cat-icon.jpg”/> <div class=”option-text”>Cat</div> </option> <option> <img src=“./dog-icon.jpg”/> <div class=”option-text”>Dog</div> </option> </div> </select>
Customize selectively <input type=”range”>
Customize selectively <range> <div slot=”thumb” part=”thumb”> <svg><!— Use SVG to draw the thumb icon… —></svg> </div> </range>
Parts and slots
Native controller code + userprovided UI Parts Web Platform Code Native event handlers Part Attributes / element types
Solution 3: Shadow DOM replacement
attachShadow()
attachShadow()
let customSelect = document.createElement(‘select’); customSelect.setAttribute(“custom”, “”); let selectShadow = customSelect.attachShadow({ mode: ‘open’ }); selectShadow.innerHTML = My custom select UI; document.body.appendChild(customSelect);
Don’t forget your parts! part=“button”
Accessibility
https://aka.ms/controls-explainer
We need you!
We need you! • Provide feedback on the current HTML Control prototypes that Chrome has • Contribute to the form control investigations on Open UI • Tell browser vendors what you need from your form controls
Follow these folks • @SoMelanieSaid – Microsoft Edge PM • @gregwhitworth – Salesforce / Open UI • @stubbornella – Google Chrome PM • @seaotta – Microsoft Edge PM
We’re here to listen…
…because these improvements are for you.
Thank you! https://noti.st/seaotta @seaotta ststimac@microsoft.com
Thought HTML was done? Think again! Those who work on the web platform are ready to extend HTML controls with not only updated native web styles, so that we’re no longer stuck in the Windows 95 era of design, but we’re also starting to look at new HTML controls to help solve some of the problems developers encounter when trying to extend the current controls to fit their needs.
If you build for the web, you’ve probably had that moment when you get to a point you need to build and style your controls, the most common one being the select element. You try to use the native element and style it to match the rest of your design language but the amount of CSS required is exhaustive, and you can forget about extensibility or heavy customization of the controls.
In this talk, I’ll discuss the history behind why HTML controls can be so complex to style, the current state of styling them and their extensibility, and what the future looks like for controls, starting with the ‘select’ element. I’ll also touch on how developers and designers can get involved to help drive the future of this area of the web platform forward to ensure browser makers are building the right solutions to this problem.
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.