Re: Simple template-based editing

Andrew Fedoniouk wrote:
>>>In our experimental engine all input elements
>>>and their components are part of the dom.
>>>So e.g. <select> and their <option>s are accessible
>>>from the DOM and more over can have arbitrary
>>>content.
[Snip!]
>>  Wasn't that already possible? What prevents us from using the DOM to
>>change/add/delete <option> elements now?
> 
> Yes, it is.
> But in our case you may use following:
> <select>
>   <option><img src=.../> text </option>
> </select>
> --another example--
> <select>
>   <table>....
>   <td><option> text </option></td>
>   <td><option> text </option></td>
>   </table>
> </select>
> 
> I mean that <select> as also for example <button>
> can contain any markup inside not only #PCDATA.

   Neither of the examples above are semantic. With the <img> element,
you have to remember that the contents of an <option> are supposed to be
submitted when the <option> doesn't have a |value| attribute. Therefore,
if <img> is allowed in <option>, it should be submitted. Furthermore, if
the native operating system doesn't support the <img>, then the user
won't see it anyways. You can use the :before pseudo-class in CSS to
insert an image in this case, so the <img> isn't even necessary.

   The <table> example just strikes me as being presentational use of
table markup. The <option> elements can be styled as "display:
table-cell", with the <select> styled as "display: table" (or something
like that, since I'm not sure how you want this to look).

> Another example - labeled check box:
> <input type="checkbox">label text</input>
> 
> CSS:
> input[type="checkbox"]
> {
>    display: inline-block;
>    background-image: url(stock:checkbox);
>    background-repeat: no-repeat;
>    background-position: 0 50%;
>    padding-left: 16px;
>    behavior: checkbox;
>    role: form-field;
>    ... etc.
> }
> input[type="checkbox"]:hover
> {
>    background-image: url(stock:checkbox-hover);
> }
> .. etc.

   Not sure what this is about. The "behavior" and "role" properties
sound like they're dangerously close to XBL/HTC territory.

>>>The same apply to the content of <textarea> and <htmlarea>.
>>><textarea> - is the same wysiwyg editor - container of paragraphs
>>>textarea { white-space: pre  }
>>>textarea p { margin:0 }
>>
>>  The problem here is that the contents of <textarea> are not in the
>>DOM. It's the default value of <textarea> that's in the DOM, and
>><textarea> can only contain text. The instant you allow actual elements
>>in the markup, you break backwards-compatibility with XHTML. So you can
>>never have the contents of <textarea> be markup and you can never put
>>the current contents in <textarea>, because they would overwrite the
>>existing contents and prevent the default from being restored when
>>pressing a reset button.
> 
> Yes, it is.
> 
> Conceptually textarea could be represented as
> <textarea style="display:inline-block; white-space: pre">
>     some text
> </textarea>
> 
> Again conceptually nothing stops you from interpreting it this way.

   ...Except the UI guidelines for the underlying platform, but I don't
see what this has to do with backwards-compatibility or the _current_
contents of the control not being in the DOM.

> Restoring (resetting) is a different story and part of undo/redo 
> functionality of
> tes-editor behavior.

   Both the <htmlarea> and |contenteditable| models allow for
manipulation of editable content via scripting and the DOM. So, for
instance, template markup could be inserted at the cursor location when
the user presses a button. This can't happen with <textarea> unless you
want to use hacks like innerHTML and what not.

>>>To be short: In our case all "controls" and their content are
>>>"DOM citizens" with "behaviors" applied, again, through
>>>CSS.
>>
>>  For backwards-compatibility, <textarea> can't contain elements, only
>>text, so there's nothing to style. You could in theory apply styles as
>>if the WYSIWYG content of the control was in the DOM, though, and that's
>>worth considering. You won't be able to see the styling in a legacy
>>browser, though.
> 
> "so there's nothing to style"
> I guess it is a wrong assumption.
> E.g. "code syntax coloriser" may apply different styles to textarea content.

   Not sure what you mean, but specific rules and restrictions would
have to be placed on the user agent regarding how to handle <textarea
accept="text/html"> in order to get consistent CSS support for its
contents. However, consider that a user agent vendor may wish to simply
provide syntax coloring and other additional editing support for HTML
that _isn't_ WYSIWYG. For instance, a toolbar for inserting basic HTML
elements might be added while the actual editing area may remain
text-only. Providing rules for how CSS applies may not make sense
depending on the design decisions of the vendor.

> Plain text representation of textarea is what to be sent to the server as a 
> value of the form field.
> And this is part of behavior to determine what exactly is it.

   Clearly only plain text is sent to the server, since the default
contents are supposed to be plain text.

   When I experimented with placing markup inside <textarea> in an XHTML
area, the elements and their children were ignored in Firefox, while
Opera ignored the entire contents of the <textarea>. So clearly you
can't put markup inside <textarea> in an XHTML document and expect it to
be supported in legacy browsers.

Received on Saturday, 1 October 2005 10:36:38 UTC