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

Re: 'role' should be property

From: Dmitry Turin <html60@narod.ru>
Date: Fri, 15 Jun 2007 09:55:31 +0300
Message-ID: <1607267609.20070615095531@narod.ru>
To: public-html@w3.org

Excuse me for a long break.

MR> you could have your styling out of sync with your semantics.
MR>  "role sheet" ... increase the number of HTTP requests.

_Synchronizing_ and _quantity of HTTP requests _ are additional reasons
to merge visual and semantic properties into one space.
(they may be added into list of reasons under #1.4 and #1.5)

MR> With the semantics in markup, you can bind to the markup
MR> itself and always know that you're binding a specific presentation onto
MR> a specific set of semantics.
MR>  In the former scenario, you could have a
MR> dedicated person specialized in CSS who handles styling and a second
MR> person who specializes in HTML. In the latter scenario, you have one
MR> person who does BOTH presentation and semantics so that the selectors
MR> are kept straight between files, and maybe a separate person who does
MR> structural HTML markup. Thus you have altered the traditional division
MR> of labor.

It means,
that reference (from attribute |class|) into two sheets simultaneously

<... class="a">
.a {
  color: red;
.a {
  role: error;

should be replaced by reference into one sheet

<... class="a">
.a {
  color: red;
  role: error;

Let's look at 'role' like at _visual_ property,
which is empty (doing nothing) in browsers,
but which is additional axis (characteristic) in other UAs.

MR> wouldn't you just be repeating a class name in the markup instead of a
MR> role name? Is saying |class="tree"| and then having ".tree {role: tree}"

First, tree is not semantic, it's construction's category,
i.e. 'role: tree' is wrong (in point of logic).
Second, it's very bad practice in general
to carry value of role into name of class,
i.e. ".a {role: a}" is __quite crime__.
Do you write ".red {color:red; font:bold}" ??

D> A <roles> element

Let's use razor of Occam: don't add item (tag) without necessity.
Let's reduce quantiny of items.
<div style="role: ...">

JB> if a use case for "role" is very common, may that role should warrant its own element

If "very commnon", than all tags (including ancient) must have default role's value.

D> An individual element's role attribute
D> could be used to override the default roles.

Like the previous cue:
there is no need in attribute |role|, because it's possible to write
<... style="role: ...">

Dmitry Turin
Received on Thursday, 21 June 2007 05:22:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:22 UTC