Re: Simple template-based editing

Andrew Fedoniouk wrote:
>[Matthew Raymond wrote:]
>>  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).
> 
> Couple of examples:
> 
> http://terrainformatica.com/hsmile/images/controls2.jpg
> http://terrainformatica.com/hsmile/images/hsmileselect.png
> 
> Again <select> here is just a div with overflow:auto
> correspondent behavior knows of how to select
> contained <option>s.
> 
> And more:
> <select>
>     <ul>
>           <li style="role:option">one</li>
>           <li style="role:option">two</li>
>           <li><option>two</option></li>
>     </ul>
> </select>

   This is all kinds of corrupt. First of all, the unordered list markup
serves no semantic purpose. The <select> is already a list of options to
select from, so I can only assume that you're using the list markup for
list-like presentation. This is clearly the domain of CSS, and could
probably be achieved with just the <option> elements using existing CSS
selectors and properties.

   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.

>>>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.
> 
> Again these are just my personal experiments. I am not proposing them 
> formally.
> Consider them as a proof of concept - system of input elements
> can be build using CSS and some arbitrary XML alike DOM.
> Just need two additional attributes: role and behavior in CSS.

   If I understand this, "role" is a semantic property, while behavior
is very similar to the "behavior" property used by HTML Controls (HTCs).
While there is value in binding markup and script via CSS, semantic CSS
properties are a horrific idea. It essentially relegates markup elements
to being placeholders for user-defined semantics. The actual markup
would become something web authors would ignore, even when using an
external stylesheet, which could result in pages that have meaningless
markup that does nothing when the stylesheet fails to load.

> Behaviors can be intrinsic and/or defined as ECMAScript objects.
> The main point - they are assignable through CSS. Having this
> we can define what we have in HTML now but for any arbitrary
> markup language.

   You're just transferring semantic definitions from the markup to CSS.
This doesn't actually solve anything. All it does is move language
definitions from XML and HTML into CSS.

> The reality:
> No one UA now is using native UI widgets nor following OS guidlines.
> as they are trying to be OS agnostic. Good it or bad - I don't know.

   That's misleading. Most browsers do have their own widgets, but only
because the original operating system widgets didn't support the range
of features required for web browsing. In most cases it's considered a
bug when HTML widgets deviate from the native UI conventions. Programs
with themes/skins are a special case, but even those have user interface
conventions, even if they're not those of the operating system. In the
case of Mozilla, I believe their design philosophy is to allow the user
interface to be as close to the OS and the theme author chooses, so
themes that exactly duplicate the local UI are entirely possible (at
least in theory).

   The bottom line, though, is that breaking UI conventions confuses
users. The user expects certain behavior and presentation when
performing a certain task. It's poor design to deviate from those
conventions without cause.

>>>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.
> 
> I am experimenting by my own and not hacking legacy browsers
> I have my own engine for that.

   Who said anything about hacking. I just observed how the browsers
respond to specific markup, and it didn't turn out too well. You can
implement new features in your own code, but that doesn't result in old
content utilizing your new features, nor does it allow legacy browser to
make use of content using your new markup in any reasonable fashion.

Received on Monday, 3 October 2005 03:06:42 UTC