W3C home > Mailing lists > Public > www-html@w3.org > September 2005

Re: XHTML2: Proposal for total separation of semantics from structure

From: Junk Account <avoid.spam.account@gmail.com>
Date: Mon, 26 Sep 2005 00:50:01 -0300
Message-ID: <a0d591205092520505efa758e@mail.gmail.com>
To: www-html@w3.org
Within the context of total separation of semantics from structure...I have
something more to add.

----- Proposal: Separation of specification mechanisms: -----

The "class" atribute serves for specification. As such, is generic. General
purpose.
However, if we split semantics, in the same way we split presentation
before, I have another proposal.
To add two more atributes: "style" and "meaning" (or "semantic", or
something similar).
Why so?

First let me pre-empt a future objection.
I can hear a lot of people asking: "Is it really necessary?"
The answer is "No".
But then the next question is... "Since when necessity is the only
criteria?"
While a minimalistic approach is obviously desirable as a designing
principle, and it has served as well...is it an iron-rule? Or, precisely, a
principle, a guide?
Necessity is *not* the only criteria. There are others. Like robustness
(prevention of common usage mistakes). And overall clarity.

Now, to answer the question...Why so? Why to add two new attributes?
Because is way clearer for Grandma and Grandpa.

<p style="mystyle" meaning="mymeaning"> foo </p>

...is, for a plumber, for a carpenter, for an audio fan, for Grandma and for
Grandpa, *way* more simple, understandable, than

<p class="123" class=xyz"> foo </p>

...where 123 *might* (or might not) mean some style, and xyz *might* (or
might not) mean some sort of semantic use.

Regarding class="foo", however, I sustain it *should* be mantained. Why so?
For exactly the same reason as before: to have a generic mechanism for
specification, for any unforeseen purpose that might show up.
What's the true cost of this whole operation? Just about zilch, really.
With the added value that if some particular special functionality is ever
attached to presentational or semantic processing, XHTML does already have a
mechanism to handle it already in place (with just class for both uses, this
could not be done).
And there are yet more reasons to do it too. Yep, more potential benefits.
In fact, very important ones.
It relates to an apparently big missing functionality in today's XHTML/CSS.
In fact, potentially two of them:
1) XHTML copy and pasting *with* format (and potentially, meaning).
2) XHTML WYSIWYG editing *with* perfect code generation.
Each of those is *so* big and important, however, that deserve a post apart.

The present message refers, mainly, but not restricted to, to point 1)
above, about which I'll post soon, separately.

Fernando Franco
Received on Monday, 26 September 2005 03:50:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:04 GMT