Re: 'role' should be property

Andrew Fedoniouk wrote:
>> Andrew Fedoniouk wrote:
>>> About the role: it should be role DOM attribute and role CSS [property]
>>> that allowed to override value of the DOM attribute.
>>   Note that this is actually contradictory to the way CSS is handled.
>> If a specify a |style| attribute on an element, that element will have
>> that style regardless of what's in the style sheet. What you propose
>> would be the equivalent of having the style sheet override the |style|
>> element.
> 
> Correct, but where you see the problem? CSS already is capable to change
> rendered content of the document:
> 
> P.note:before { content: "Note: " }

   And the styling can be overridden by either the <style> element or
the |style| attribute, so what's your point? It's still contradictory to
the way CSS operates. In fact, when you use "role" in a |style|
attribute, it just makes things more complicated:

| <span style="role: note">[...]</span>

   ...Versus...

| <span role="note">[...]</span>

   (Not that I'm defending |role|, mind you. A <note> element might be
just as good.)

> I do not see any problem with say:
> 
> select[ type="tree" ]
> {
>    role: tree-vew;
>    border: 1px solid orange;
>    ...
> }

   Well, for one, there's no way to bind to the role using XBL 2.0 to
implement support for it in case the user agent doesn't support that
role. Also, there's no separation of content and presentation. You'd
also have to find a way to handle default styling for the role value and
define how CSS should handle namespaces as parts of attribute values.

> If component designer will have a single place where she/he can 
> define/declare
> his component (that is CSS and some code in terms of Web Applications) then
> chances that we will have usable constructions are significantly higher.

   That's what XBL 2.0 is for, and it's already a Candidate Recommendation.

> In the case above [HTML] will have simple insertion point:
> 
> <select type="tree">
>     <option >...</option>
> </select>
> 
> HTML/CSS as a public media simply cannot use obligatory
> standards. The only feasible way is to define a set of easy to use
> and simple features that will motivate to use them
> (motivational standards (probably makes sense to put it as one more
> design principle?)).
> 
> Say we will have 'role' as a CSS attribute and some feature in ECMAScript 
> that
> will allow to register your own event handlers for the 'roled' elements:
> 
> document.addRoleHandler("tree",
> {
>      onClick: function() {...},
>      onMouseDown: function() {...}
>      onMouseUp: function() {...}
> }) ;

   This can already be done via XBL 2.0. In fact, XBL 2.0 allows you to
bind XHTML and XML markup to a page and allows the use of localized
style sheets that only apply to the elements in the shadow tree.

> Having this you can expect that 1) 'role' will be used and 2) will have
> meaningful values.

   Don't count on it.

Received on Saturday, 26 May 2007 16:23:15 UTC