Re: Simple template-based editing

Andrew Fedoniouk wrote:
> Matthew, you are in captivity of stereotypes. Forget about legacy browsers 
> and HTML specification for the sec.

   On the contrary, you have yet to convince me that you have developed
a system superior to a combination of existing HTML, CSS and XBL2.

> selects, set of radios and checkboxes are all lists semantically speaking :)
> 
> select is a list of radios, multi-select is a list of checkboxes .
> They differ only by style of presentation (nb!) and very slightly by
> behavior.

   Wrong. The <select> element is a form control with specific
form-related attributes. Even if you make another element a form control
via styling, you'll still need those attributes. Behavior isn't enough.

> Semanticly (sic!) <select> or set of radios or set of checkboxes
> are just lists:
> 
> <ul style="presentation-and-behavior">
>           <li>one</li>
>           <li>two</li>
>           <li>three</li>
> </ul>

   Aside from what I mentioned above, you also have to consider that
<option> elements have |value| attributes for determining the value to
send back to the server, |label| attributes for displaying short version
of the label, and a |selected| attribute, which is pretty much
self-explanatory. The <li> element doesn't have these attributes.

> Having this it would be possible for example to better style inputs for
> different media, e.g. for printing.

   Why not just improve the way CSS styles controls? There have already
been discussions on that.

> Having this also it would be possible to say
> 
> <ul style="presentation-and-behavior">
>           <li>one</li>
>           <li>node
>              <ul>....</ul>
>           </li>
>           <li>three</li>
> </ul>
> 
> to represent hierarchical or groupped lists, etc.

   Not an issue:

   http://whatwg.org/specs/web-forms/current-work/#nested-optgroup

>>  Secondly, you're using CSS, which is supposed to be exclusively
>>presentational, as a way of assigning semantics to specific markup. This
>>is totally backwards. The markup holds the semantics, and CSS holds
>>presentation. For that matter, a CSS property is supposed to be a
>>_hint_, and therefore may be disregarded by the user agent. As a result,
>>your list item markup isn't even guaranteed to behave like an option,
>>even if the user agent is fully compliant with CSS.
> 
> [skipped]
> 
> Style definition is presentational entity - no doubts here.
> In contrary, style selector as an entity is universal thing
> - by adding 'behavior' to the list of attributes we are not
> changing presentational nature of CSS - we just reuse
> existing CSS selector mechanism.

   Reusing it inside of a CSS stylesheet, thereby defeating the purpose
of putting styling in a separate file in the first place: separation of
semantics, behavior and presentation. You also still have the problem
when external stylesheets fail to load. For example...

HTML:
| <ul class="selectLikeList">
|   <li>one</li>
|   <li>two</li>
|   <li>three</li>
| </ul>

"CSS":
| ul.selectLikeList { role: option-list }

   What happens to the unordered list when the stylesheet fails to load?
That's right, the carriage turns back into a pumpkin.

> Imagine that you have such 'behaviors' as a system of
> ready to use lego elements. Then you can construct
> not only existing widget set of HTML but something
> more rich in order of magnitude. Theoretically :)

   I keep asking you how this is better than XBL-style technologies, and
you keep failing to answer the question. Is it that you don't understand
the technology? I'm sure any number of people on this mailing list could
explain it to you.

Received on Monday, 3 October 2005 06:59:17 UTC