- From: Brad Kemper <brkemper@comcast.net>
- Date: Mon, 25 Feb 2008 22:15:42 -0800
- To: James Elmore <James.Elmore@cox.net>
- Cc: www-style mailing list <www-style@w3.org>
- Message-Id: <4D1BAF4A-72D4-49E2-929A-1D807E57D10F@comcast.net>
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>. > I am not disagreeing with you. Using 'type' might make sense as an > overall solution to providing the ability to have states which CSS > can control. I liked your suggestion of using <select> elements > (again a part of forms) to create the nested structures for future > collapsable outlines/menus and using CSS to control that collapse/ > expansion. I am just trying to be careful and keep the discussion > of changes to HTML separate from changes to CSS. (I have been > 'dinged' often in the past for not being careful about this > separation; it makes sense to do so most of the time.) I understand. It would seem to require a joint effort, unless we use existing elements that carry state information (existitng elements that can be "checked"). Or unless CSS decides that labels can reflect the "checked" state of their associated inputs. >> Even if we don't use the same words, at least we have a good, >> workable model, that would assist in easy understandability of >> similar state changing mechanisms that can be styled with pseudo- >> class selectors. > > Right. There is no need to reinvent the wheel. The ability to > create a 'drop-down' menu is very similar to the ability to > collapse/expand an element. I agree. That seemed to be one of Andrew's conceptions as well. > It may be that the solution has already been found and implemented, > and the CSS group only needs to point that solution out and have it > apply to more elements. (This would be similar to my suggestion of > using 'visibility:collapse;' for more than just table rows and > columns.) That would prevent "::outer" from being visible though, wouldn't it ("outer" inherits from its insides, because that is its real parent)? Does it have any advantage over { height:0; overflow:hidden; } other than not having to hide its descendants too? > Just be careful to keep the HTML elements separate from the styling > of those elements. This has been one of my personal peeves for a > long time, starting with tables, which have many built-in styling > abilities not found anywhere else. So tables have been used to > STYLE web pages, since there is no way in either CSS or HTML to do > many of the things authors/designers want, outside of tables. I agree totally with every sentence in that paragraph. Which is why I am less favorable towards something like <div type="collapsible" expanded> (since those words imply a certain styling), and more favorable towards <div changeable=" 2-states" state="1"> or <div states=" 2" initial-state="1">, which could be styled in any way you wish. That would be much more of an abstract state for the element to carry, but could conceivably be carried by anything (except possibly form elements and anchors, that handle clicks and keyboard activations on their own, and would be thus difficult to change other states on by user action).
Received on Tuesday, 26 February 2008 06:15:59 UTC