Re: 'role' should be property

Dannii wrote:
> [Matthew Raymond] wrote:
>> Dannii wrote:
>>> A <roles> element or a <link rel="rolesheet"> seems to me to be a
>>> better idea.
>> 
>>    Sure, because then you could have your styling out of sync with your
>> semantics. With the semantics in markup, you can bind to the markup
>> itself and always know that you're binding a specific presentation onto
>> a specific set of semantics. When you roll those semantics into a
>> separate files, you have ensure that both files use the same selectors
>> to keep the two in sync. In the former scenario, you could have a
>> dedicated person specialized in CSS who handles styling and a second
>> person who specializes in HTML. In the latter scenario, you have one
>> person who does BOTH presentation and semantics so that the selectors
>> are kept straight between files, and maybe a separate person who does
>> structural HTML markup. Thus you have altered the traditional division
>> of labor.
> 
> This has nothing to do with presentation at all. You have one person who
> does semantics  and structure, as it is now, except they have an extra
> option for specifying custom semantics to use if they like. Yes they
> would have to learn selectors as you mention later, but selectors aren't
> very complicated, and if they're making up new custom semantic roles
> then I'd presume they're pretty competent already.

   What you're really talking is increasing the baseline knowledge of an
author in order to use semantics in HTML, and doing so in a way that
largely overlaps CSS. Furthermore, the Selectors used in the "role
sheet" will have to match those in the CSS Selectors in order to style
elements with specific roles. Thus we're talking about a situation where
one person edits three files, and that is not conducive to a division of
labor.

   The bottom line is that you shouldn't need three different
technologies for a single task.

[Snip!]
>>    Considering you have to have something to select via W3C Selectors,
>> wouldn't you just be repeating a class name in the markup instead of a
>> role name? Is saying |class="tree"| and then having ".tree {role: tree}"
>> in a separate file that may fail to load better than just |role="tree"|,
>> or |class="tree"| with some means of specifying a microformat to
>> associate with the class name? To me, it doesn't really sound like it
>> saves much effort, and it requires the HTML author to learn Selectors
>> just to add semantics to their own markup.
> 
> I'm thinking more of roles with the complexity level of hcalendar. You
> could easily have 50 calendar events on a page. Instead of marking up
> the same class names/roles on each hcalendar, you could just set a
> single class to the container of the hcalendar, and specify the rest in
> a [role sheet].

   I doubt it. Otherwise, you wouldn't need the class names in the
microformat to begin with. Essentially, you'd need to use specific
markup in a specific order to avoid using classes, which doesn't seem
very practical to me.

>>> People have said that having external rolesheets is a bad idea, but
>>> isn't this what we already have, except that instead of having
>>> them on your site, they're internal to the user-agent and based of
>>> the HTML spec?
>> 
>>    So we need external stuff because we have native, internally
>> implemented stuff?!?... Wha?!!
> 
> We don't need anything. But we could have it.

   You're right. We don't need anything, because we already have XBL 2.0.

>>> User-agents will already have some sort of system to understand
>>> the semantics of a page, they could then augment that on a per-page
>>> basis based on the rolesheet, rather than based on individual
>>> elements' role attributes.
>> 
>>    I think you're being a little too presumptuous about browser
>> architecture. I can easily see scenarios where role sheet implementation
>> would be non-trivial, especially for non-CSS user agents.
> 
> Selectors aren't too complicated... but I'm suggesting this mostly from
> a author's point of view. If selectors are too hard to implement, then
> maybe the Selectors API WG should make it easier.

   First of all, you're talking about two working groups, the CSS
Working Group and the Web API Working Group. As far as I know, there is
on "Selectors API Working Group". The Selectors API edited under the Web
API WG and Selectors themselves are under the CSS WG.

   Secondly, because there are multiple levels for Selectors, you can
have significantly different levels of support depending on the user
agent, ranging from UAs that support most of Level 3 to UAs that don't
support Selectors at all. What you're really talking about is a
significant barrier to entry for implementors of new user agents.

   As for complexity, it's not so much an issue of Selectors being too
complicated for its purpose. It's about the fact that it's unnecessary
for assigning semantics, thus making web development /unnecessarily/
complex.

Received on Tuesday, 29 May 2007 11:13:19 UTC