- From: Henrik Andersson <henke@henke37.cjb.net>
- Date: Tue, 19 Feb 2013 03:57:29 +0100
- To: www-style@w3.org
CSS is a wonderful and powerful language. But there is one thing it does not currently address: styling elements that are composited of subcomponents. By subcomponents I do not mean child elements, but rather complicated elements that has clearly identifiable subparts in common renderings. Many, but not all of the examples are interactive. Here is a list of the features in HTML (that I could find) that can be assumed to have composite elements: * Scrollbars, both the main viewport ones, overflow caused ones and the ones belonging to frames * The audio and video elements, when set to show playback controls * Date and time input elements * File upload elements * The progress element * The meter element * The details element * The drop down menu of size one select elements I believe that it may be a good idea to allow CSS to define how these components should be rendered. However, many of the listed examples may be platform specific. I will now elaborate on the subcomponents in the given examples: Scrollbars Always composited of two buttons at the end, a scroll track and a variable size scroll bar. Per axis that is. Some scrollbars allow for 2D scrolling. Some applications (Such as word processors) also add additional elements, such as page up and down buttons. Audio/video playback controls May contain playlist navigation buttons (prev, next, etc...), media controll buttons (play, pause, play/pause, stop, step frame, etc...), a seekbar (possibly with several layered bars to status like show media buffering and playback progress as well as traditionally having a dragable seek head), a volume control (popularly a triangle that masks a bar that indicates loudness by how long the masked bar is) + mute button, fullscreen toggle button, closed caption controls as well as additional controls. Date and time input elements Commonly shows a calendar. Sometimes the calendar is hidden beneath a dropdown menu. The calendar commonly has a header that allows for month and year selection. File upload elements Commonly implemented as a textfield for a local file path with a browse button afterwards. Progress element A HTML 5 addition that draws a bar in a box that indicates how far a process has progressed. The bar is normally anchored to the left edge of the box. It may sometimes show an indication that progress is being made, but it is indeterminable how far the task has progressed. The indicator is commonly either a diagonal stripe fill of the entire bar or a bouncing, non anchored small bar. Meter element Another HTML 5 addition. It lacks a common control on most platforms, so browser vendors may get creative here. One possible rendering would be a bar in a box, but with marked zones in the box corresponding to the set high, low, min, max and optimum values. A more elaborate rendering could be to do it in the style of a circularly bent bar, possibly with a needle. Like in car display panels. Details element Yet another HTML 5 addition. This element allows content to be selectively collapsed (think display: none) with a small summary displayed. Most of the content here is real child elements. But the actual matter of how the user indicates to open or close the details view is left unspecified. The example illustration shows that a clickable arrow could be used as a toggle button. Drop down menus A textfield style control that shows a list of options, a normal box model box that is hidden unless the user "opens" the drop down, usually by clicking on the closed control. Selecting an option typically closes the list. The control shows the selected value in the textfield when the list is closed. The control traditionally includes an arrow button aligned to the right edge of the label of the selected value, this to indicate that it is not a normal text field control. CSS could potentially handle a lot of these cases by adding additional pseudo elements to represent the various subcomponents. Some of these elements may use pseudo classes, like active, disabled and so on. The progress and meter elements are prime candidates for the attr() syntax, since they could read the attribute values and compute appropriate style values. However, an issue that I do not know the answer to is how to let authors work with what currently has been platform and/or application specific parts of the rendering. To refer to my examples, the set of possible controls for a media player is huge and existing players have a big variation in which ones they use, sometimes the same player might even select them based on the context! How can CSS be enhanced to do to these cases to ensure consistent rendering? And what of that should CSS do?
Received on Wednesday, 20 February 2013 14:02:00 UTC