Re: Collapsing elements

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