- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 26 Feb 2008 00:12:08 -0800
- To: Brad Kemper <brkemper@comcast.net>
- CC: James Elmore <James.Elmore@cox.net>, www-style mailing list <www-style@w3.org>
Brad Kemper wrote: > > On Feb 25, 2008, at 11:41 AM, James Elmore wrote: > >>> HTML already has a way to create and control a binary state. "Type" >>> is used to create a 2-state, click-changeable input ("type=checked" >>> and "type=radio"), and "checked" is used to indicate which of the two >>> states it should start out as. Without the "type", there is already a >>> "non-of-the-above" state. >> >> Right now, if I am reading the HTML spec correctly, 'type' only >> applies to form <input> elements. If your proposal is accepted, that >> means a change in HTML, not a change in CSS. > > Correct. My point is that HTML is best suited to carrying the state > information, as it does already with checkable inputs. (To try to set > the state with CSS and then select in CSS based on that state would be a > path fraught with peril.) So that leaves us with using existing > checkable elements (radio and check-boxes), or else changes to HTML to > allow other elements to be checkable and to be able to set their state > to checked (or not). it is "type" that makes inputs checkable, but it > could be some other attribute as long as we are changing. Conceivably, > it could be <div checkable checked> instead of <input type="tab" checked>. > DOM element is an entity that has state. This state is getting changed as a result of handling of various events. E.g. click (mouse down/up on the same element) may switch :checked state. <img> element that is waiting for some data to arrive may have :busy state flag set. And so on. You may think about HTML/XML loaded into the UA as a system of DOM elements where some elements have "drivers" (behaviors) attached to them. Behavior is a pure functional thing - it is not presentational in almost all cases. Role of behavior is to handle "physical" events (mouse/keyboard) and translate them into logical events and states: :active, :visited, :checked, :expanded, :collapsed, :busy, :invalid, etc. *Any* standard input element can be represented as ordinary DOM element with assigned behavior. Add there set of styles and you will get for example <input type=text>. Behavior here is responsible for handling users actions that causes element.text to be changed. It is a trinity of equally valuable entities: DOM element, style and behavior. De facto there is a set of behaviors already. All <input>s can be presented as set of declarations: input[type="text"] { behavior: single-line-edit; ...} input[type="chekbox"] { behavior: checkbox; ...} input[type="radio"] { behavior: radio; ...} If you will start think this way then suddenly you will discover that you can reuse behaviors for almost all other UA activation needs. E.g. some list with <li> that have assigned behavior:radio to them may behave as an accordion widget with proper styling. So it is a matter of separation of behavior from dom element and styling that according to old "divide et impera" principle will only help us to reach new quality. Dixi :) -- Andrew Fedoniouk. http://terrainformatica.com
Received on Tuesday, 26 February 2008 08:14:33 UTC