Re: Simple template-based editing

Andrew Fedoniouk wrote:
> From: "Dimitri Glazkov" <dimitri.glazkov@gmail.com>
> | Is this what you mean by input behavior? I would think that term
> | should refer to how the actual UI element works in the browser.
> 
> As you know these two lists being placed in form will produce exactly
> the same GET/POST request to the server:
> 
> <select size=3 name="list">
>    <option value="1" selected>One</option>
>    <option value="2" >Two</option>
>    <option value="3" >Three</option>
> </select>
> -and-
> <ul style="overflow:auto">
>     <li><input type=["]radio["] name="list" value="1" checked />One</li>
>     <li><input type=["]radio["] name="list" value="2" />Two</li>
>     <li><input type=["]radio["] name="list" value="3" />Three</li>
> [</ul>]

   Actually, that's wrong. First of all, you forgot the labels:

| <ul style="overflow:auto">
|   <li><label>
|     <input type="radio" name="list" value="1" checked />
|     One
|   </label></li>
|   <li><label>
|     <input type="radio" name="list" value="2" />
|     Two
|   </label></li>
|   <li><label>
|     <input type="radio" name="list" value="3" />
|     Three
|   </label></li>
| </ul>

   Another problem is that <input checked> matches the :checked
pseudo-class, while <option selected> matches selected. So the styling
would not be equivalent. Also, |value| must always be specified for
<input type="radio">, whereas <option> can simply use its text contents:

| <select size=3 name="list">
|   <option selected>1</option>
|   <option>2</option>
|   <option>3</option>
| </select>

   ...As opposed to this...

| <ul class="selectList">
|   <li><label>
|     <input type="radio" name="list" value="1" checked />1
|   </label></li>
|   <li><label>
|     <input type="radio" name="list" value="2" />2
|   </label></li>
|   <li><label>
|     <input type="radio" name="list" value="3" />3
|   </label></li>
| </ul>

> These lists differ only by presentational style

   You don't know that. That's left up to the user agent. They could
have the same presentation or radically different presentations
depending on the decisions of the UA developers.

> and, again, very slightly
> by behavior ( e.g. second one enumerates items by tab, first one by arrow 
> keys ).

   HTML does not define how items are selected within a user agent. You
are simply taking user agent conventions on a particular platform and
treating them as if they were part of the HTML spec. They're not.

> "...That's not something ordinary lists can do..."
> 
> Imagine that you have something like this:
> 
> ul { overflow:auto; }
> ul > li { behavior:radio; role:form-field; }
> 
> <ul name="list">
>     <li value="1" checked>One</li>
>     <li value="2">Two</li>
>     <li value="3">Three</li>
> <li>
> 
> Then on submit smart UA can enumerate all elements
> in the form(or other container) with role == "form-field" and send them to the 
> server.

   This is a bad idea because:

1) It requires that a user agent supports of CSS.
2) It forces web authors to include CSS in their HTML documents in case
the separate style sheet file doesn't load.
3) It requires that form control attributes exist for all elements.
4) You need the user agent to support all values of "behavior" and
"role". Otherwise, someone could use an unsupported value on something
like a <span>, and the result would end up being semantically
meaningless to the user agent.

> Some comments on 'role'/'behavior' attributes:
> 
> 'behavior' defines interaction style of the element.

   AKA Behavioral styling.

> 'role' defines its purpose e.g. form-field.

   AKA Semantic styling. So everything is handled by CSS. With a couple
more properties, we can eliminate markup all together.

> Another example:
> in-place WYSIWYG editing may require something like:
> <span style="behavior:checkbox; role:observer" name="strong-state" />
> near some <htmlarea> to show strong/non-strong state at its caret position.
> Having role:observer defined will ommit sending its value to the server on 
> Submit.

   I have a better idea:

| Strong State: <span id="strong-state">No</span>

   When the state changes, just make the <span> element's
.innerHTML="Yes". Or you can make it an image:

| var spanStrong = document.getElementById("strong-state");
|
| if (bStrongState) {
|   spanStrong.innerHTML='<img src="yes.png" alt="Yes">';
| } else {
|   spanStrong.innerHTML='<img src="no.png" alt="No">';
| }

   Well, my scripting skills may be rusty, but you get the idea. Since
you have to be monitoring a state at the caret position, you need
scripting to change the element content to reflect that state anyways.

   Now let's look at your markup again:

| <span style="behavior:checkbox; role:observer" name="strong-state" />

   If you're coming from an HTML 4.01 and CSS 2.1 background, what does
all that styling mean to you? What does the |name| mean in the context
of a <span>? A web author who knows existing standards would see it as
an empty <span> element with no |id|. I think most HTML 4.01 validation
tools would actually throw a warning on it. If you were to move the
style to an external style sheet, and the style sheet didn't get loaded,
the <span> wouldn't even render.

   What I've been trying to understand the most is why you feel
compelled to abandon the XHTML2 |role| attribute. You seem to be
declaring a role in the markup anyways, since every example you use has
the style inline, so why not just use role?

   Your whole idea feels like a really bad solution in search of a
problem. Can you come up with even one use case that can't be handled by
 a technology like XBL or HTC? And remember, those technologies have
implementations. The sXBL draft came out a month and a half ago. What is
the use case you're trying to address?

Received on Tuesday, 4 October 2005 19:16:16 UTC