[css-forms] Commit initial idea document.

Author: tabatkins

css-forms/Overview.bs

@@ -0,0 +1,150 @@
+<pre class='metadata'>
+Title: CSS Form Styling Module Level 1
+Shortname: css-forms
+Level: 1
+Status: DREAM
+ED: http://dev.w3.org/csswg/css-forms/
+No Editor: true
+Abstract: This document is currently a loosely-structured set of ideas and inspiration for CSS form styling.
+	It is not an implementable standard. Do not look at this as anything but a collection of ideas.
+Warning: not ready
+</pre>
+
+Basic Styling Proposals {#ideas}
+================================
+
+This section sketches a few proposals for solving the form styling problem.
+
+Prototypes {#prototypes}
+------------------------
+
+This idea, originally suggested by fantasai,
+is that we can style a handful of "prototype" elements.
+Browser UI designers can then take the styling of those elements
+and extrapolate the design into their own UIs.
+At minimum, things like text, backgrounds, and borders can be used.
+At the limit, things like internal padding, border-radius, etc might be used.
+
+<pre class='lang-css'>
+	@control button {
+		&lt;declaration-list>
+	}
+
+	@control input {
+		&lt;declaration-list>
+	}
+
+	input::selection {
+		&lt;declaration-list>
+	}
+
+	...
+</pre>
+
+<blockquote cite="https://lists.w3.org/Archives/Public/www-style/2015Jan/0490.html">
+	You would be able to use styles for:
+
+	* font selection (css-fonts)
+	* text decoration (css-text-decor)
+	* text layout (css-text)
+	* backgrounds & drop-shadow (css-backgrounds)
+	* borders & padding (css-backgrounds)
+	* filters
+	* anything else we or a UA decides seems relevant
+
+	Most form controls, even a calendar widget or clock, are a combination of
+	these three primitives in some way. If the UA is given the styling for
+	these three primitives, and perhaps one or two more it can figure out how
+	to style the rest.
+
+	For example, a calendar widget might have the month, the year, some buttons
+	to move them around, the ability to click into them and edit them directly,
+	and a representation of the days of the month. The selected day is selected.
+	Perhaps the buttons only show up on :hover or :focus -- the UA decides. But
+	it knows that a button should be this particular shade of blue with that
+	particular border-radius and drop-shadow. The calendar might be shown in the
+	colors of the input field, and the selected day in the selection color, and
+	in all ways it will match the way the input fields look in the rest of the
+	page.
+
+	Now, the author can't decide, for example, the spacing between the year
+	and the month name, or whether the button to change years has a solid
+	arrow or a hollow arrow or a frilly one, and she can't decide that there
+	should be a black solid half-border between the month and the day field
+	below it with 5px spacing. But the calendar will look like it belongs to
+	the page, and the UA can come up with a different calendar layout when it
+	ships one on a wide but short smart watch where the month and year are
+	better placed on the side without breaking anything.
+</blockquote>
+
+<div class='example'>
+	<img src=images/time01.png>
+
+	<blockquote cite="https://lists.w3.org/Archives/Public/www-style/2015Jan/0622.html">
+		The black area is the button color; a very light transparency of it
+		can be the glass color. The rollers are the input colors.
+	</blockquote>
+</div>
+
+<div class='example'>
+	<img src=images/time02.png>
+
+	<blockquote cite="https://lists.w3.org/Archives/Public/www-style/2015Jan/0622.html">
+		It's hard to tell without more context, but for the one on the right,
+		the clock face and the digital readout are @input colors, the highlighted
+		bits are the highlight color, the Done button is the button styling,
+		and the shaded area around the clock face is the same color as the
+		button background.
+</div>
+
+
+Inverse System Colors {#inverse-system}
+---------------------------------------
+
+This idea, originally sketched by Florian and Tab,
+is to define an abstract set of colors
+that UI designers can then choose from when coloring their UI.
+
+Tab's suggested set of colors, from an Android color-extraction API proposal:
+
+* Light/Normal/Dark Vibrant
+* Light/Normal/Dark Muted
+* Vibrant Complementary (for call-out buttons and such that need to be visually distinct)
+
+(where light ~75% lightness, normal is ~50%, dark is ~25%; vibrant is
+at least 30% saturation, ideally 100%, and muted is at most 40%
+saturation, ideally 30%)
+
+* Light/Dark Contrasting Text
+* Light/Dark Contrasting Secondary Text
+
+That's 11 colors, many of which should be drawable from the webpage's own color scheme.
+We can auto-gen a bunch of them if you specify at least some of them,
+like genning the light/dark variants from the "normal-vibrant" color,
+or automatically setting text colors to white/black as appropriate.
+
+There's no guarantee that the input UIs will use the colors in the *same way* that the rest of the page does, though.
+
+
+Input UI Examples {#examples}
+=============================
+
+This section catalogues as many input UI examples as we can screenshot,
+especially on mobile devices where they're a bit "weirder".
+
+Time Pickers {#time-examples}
+-----------------------------
+<figure>
+	<img src="images/time01.png">
+	<figcaption>iOS time picker</figcaption>
+</figure>
+
+<figure>
+	<img src="images/time02.png">
+	<figcaption>Android time picker 1</figcaption>
+</figure>
+
+<figure>
+	<img src="images/time03.png">
+	<figcaption>Android time picker 2</figcaption>
+</figure>