Re: 'role' should be property

Dannii wrote:
> On 6/4/07, *Matthew Raymond* <mattraymond@earthlink.net
> <mailto:mattraymond@earthlink.net>> wrote:
> 
>>    Explain this to me: How does performing the same action in a new
>> language in a document separate from your original source document make
>> it easier to do a task than simply revising the language of the original
>> source document? Exactly where are the repetitive semantics that justify
>> a separate CSS-like language in the first place, and how does one bind
>> to the HTML elements in question without generating markup for binding
>> that would be roughly equivalent to the amount of markup created with
>> |role| or |class|? After all, |scope| and |header|, when they need to be
>> declared, often apply to a relatively small percentage of the elements
>> in an HTML document.
> 
> 
> The example I came up with earlier would be a page with 20 or more
> hcalendar events, or something with a syntax as complicated as they are.
> Each event needs as many as eight classes to specify the data, and most
> of those classes have [ridiculous] names. That could be 160 classes.

   According to the profile[1], there are twenty class names that could
be used over and over again. Of those twenty, maybe a dozen would
actually be used for any one calendar item by an average web author. In
order to get around using class names for binding to a "role sheet", the
data would have to be stored in a unique element for each of the 20
classes. In other words, you need twenty unique elements. That's absurd.

   Now, perhaps you could save on the number of |class| declarations,
but only for items where the data is store in an element that is unique
to a particular data class in the microformat. Thus, for twenty
hcalendar events, you perhaps save a dozen or so declarations. However,
I strongly suspect that if you were doing 20 of anything, you'd be using
a template to generate them, so the number of times you declare a class
is pretty much a bandwidth argument. Yet, having a separate "role sheet"
would itself take up a certain amount of bandwidth, and in addition it
would increase the number of HTTP requests.

   So in the end, you save maybe a kilobyte of bandwidth per page while
doubling the number of HTTP requests to the website, separating some
(but not all) of the semantics from the document structure, and
significantly increasing the parser complexity for the average user agent.

> They
> could be replaced with one class on the root element of the event, or
> maybe even just a single class on the container of all events.

   That assumes they all have the exact same markup structure and
include the same classes of information in the same places, and that all
of the 20 classes can be replaced with selectors for |class|-free
markup. Keep in mind also that class selectors are just about the
easiest kind of selectors to write.

> If
> additional classes were needed, the users could choose their own, rather
> than using silly things like "dtstamp" and "uid".

   Great! That way I'm forced to read the role sheet just to know what
the classes mean.

> I know what they mean
> after examining the spec, but could you expect anyone else to guess what
> they mean?

   As opposed to something you would think up that makes perfect sense
to you, but not to someone else. Don't you think that someone must have
thought that "uid" and "dtstamp" made sense at one point? Furthermore,
throw in people who don't speak your language very well. How are they
supposed to understand what "uident" or "dtcreate" means?

[1] http://microformats.org/wiki/hcalendar-profile

Received on Wednesday, 6 June 2007 11:34:15 UTC