forked from w3c/csswg-drafts
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathOverview.bs
More file actions
187 lines (144 loc) · 6.11 KB
/
Copy pathOverview.bs
File metadata and controls
187 lines (144 loc) · 6.11 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
<pre class='metadata'>
Title: CSS Form Styling Module Level 1
Shortname: css-forms
Level: 1
Status: DREAM
Work Status: Exploring
ED: https://drafts.csswg.org/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 {
<declaration-list>
}
@control input {
<declaration-list>
}
input::selection {
<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.
Miscellaneous Control-Specific Suggestions {#misc}
==================================================
Issue: <a href="http://blog.teamtreehouse.com/use-meter-progress-elements"><progress> and <meter> styling</a>
Issue: Insert <select> and <datalist> styling proposal and/or whiteboard photo.
Select/Datalist Dropdown {#select-dropdown}
----------------------------------
1. Only allow styling if both 'color!!property' and 'background' are set.
2. Option container:
* backgrounds
* borders
* padding
3. <{option}>
* padding
* borders
* border-collapse?
* backgrounds
* display-inside is allowed, automatically blockified
* not margins, position, float, width, height
All options are contain:paint and BFCs.
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>
Date Pickers {#date-examples}
-----------------------------
<figure>
<img src="images/date01.png">
<figcaption>Android date picker</figcaption>
</figure>