W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: 'role' should be property

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 25 May 2007 11:18:58 -0700
Message-ID: <000501c79ef9$2a834600$f502000a@internal.toppro.net>
To: "Matthew Raymond" <mattraymond@earthlink.net>
Cc: <public-html@w3.org>


----- Original Message ----- 
From: "Matthew Raymond" <mattraymond@earthlink.net>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <public-html@w3.org>
Sent: Friday, May 25, 2007 4:35 AM
Subject: Re: 'role' should be property


>
> 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: " }

I do not see any problem with say:

select[ type="tree" ]
{
   role: tree-vew;
   border: 1px solid orange;
   ...
}

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.

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() {...}
}) ;

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

Andrew Fedoniouk.
http://terrainformatica.com


>
>> IAccessible::accRole() [1] is a good example of the case.
>> Currently is just impossible for the web author willing to deliver
>> rich content to make it yet accessible.
> [Snip!]
>> [1] http://msdn2.microsoft.com/en-us/library/ms696152.aspx
>
>   Why can't be just standardize a way of using ARIA with HTML[1]?
> Perhaps we could roll it into some microformats:
>
> | <html lang="en">
> |   <head>
> |     <meta name="microformat"
> |     content="http://www.w3.org/2007/05/aria-microformat" title="axs">
> |   </head>
> |   <body>
> |     <span id="slider"
> |     class="myslider axs slider valuemin-0 valuemax-50 valuenow-33"
> |     tabindex="0" >
> |     </span>
> |   </body>
> | </html>
>
>   In the above, the <meta> tag associates the class name "axs" with an
> accessibility microformat. When the class name is declared in a |class|
> attribute, the element it's declared on and all it's children will have
> their class names checked first against the microformat associated with
> "axs". If there's a match, the class names will only be processed for
> that specific microformat or supersets thereof. Thus, you can specify
> exactly what microformat you want processed and avoid conflicts.
>
>   If the "axs" class name is omitted, the microformat associated with
> "axs" will become the first default to check if no other microformat is
> specified. If the <meta> is omitted as well, the user agent can still
> process the microformat, but the order of processing will be determined
> by the user agent.
>
> [1] http://www.w3.org/WAI/PF/adaptable/HTML4/embedding-20061212.html
>
> 
Received on Friday, 25 May 2007 18:19:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC