Re: 'class' and English element names (was Re: Semantics/Profiles/Namespaces/Modules)

On 11/2/03 6:01 AM, "Karl Dubost" <karl@w3.org> wrote:

> 
> 
> Le dimanche, 2 nov 2003, à 06:07 America/Montreal, Tantek Çelik a écrit
> :
>> On 10/30/03 11:29 AM, "Karl Dubost" <karl@w3.org> wrote:
>>> Le Jeudi, 30 octo 2003, à 04:00 America/Montreal, Tantek Çelik a écrit
>>>> <time> is more semantic than <span class="time">
>>> 
>>> not exactly. More interoperable semantics :)
>> 
>> No, exactly.
>> The 'class' attribute, by definition, has no defined semantics.
>> A new tag, defined by a new spec, has defined semantics.
>> Therefore <time> would be more semantic than <span class="time">
> 
> I maintain what I have said because you didn't read what I have written
> and you agree with me in your comments.

Sounds like we were arguing different points.


>>> a <span class="time"></span> could have a lot of semantics as well if
>>> there was clearly defined profiles attributes by the HTML WG and IMHO
>>> it would be easier to move forward the spec.
>> But even *with* all that, my statement above stands, because a tag
>> defined by a specification from a standards organization would be more
>> semantic than an attribute value defined by a web author.
> 
> 
> * Semantics is defined by a spec
> =================================
> 
> I never said attribute value defined by a web author. :)

Aha. Ok.  

Profiles enable (and were intended to enable) web authors to define
semantics today, specifically for <meta> 'name' values (metadata property
names) and 'rel' values (link/hyperlink relationship semantics).

> The semantics 
> is not defined by the name of the element but ***by the specification
> and the WG***.

I think it is a *bad idea* for HTML specs and WG to define semantics of
particular 'class' values, whether through a profile or through prose in a
spec.

The 'class' attribute was specifically added so that *authors* could
"subclass" any element defined in the spec with their own particular
meanings.

In fact, *authors* could already be using *any* legitimate class value (like
class='time') to mean something in their documents.  It would be very bad
for W3C to come along now and say, no your meaning is invalid, nevermind
that previous specification, here is the meaning that class='time' really
has.

W3C can defined semantics of tags.  Let's let authors keep and use the class
attribute for themselves.   There is no need for W3C to encroach upon this
author space.

This is why <time> (defined by a spec) is more semantic than <span
class='time'> (restricted to being defined by an author since 'class' is
reserved for authors).


> The word by itself without definition doesn't define any semantics. And
> that's my point. If you create the mechanism, where you have a set of
> values for an attribute which is *mandatory defined by a spec* it has
> the same value than an element.

I agree with that statement in general for attributes vs. elements.
I *disagree* that W3C specs should define semantics for class values.

Thus you could have <span meaning='time'> be as semantic as <time> where
'meaning' would be a new attribute introduced by a spec and have values
defined by W3C.

But this is silly because if <time> is as semantic as <span meaning='time'>
or even <span m='time'> then why choose the longer alternative?  What value
does it bring?

Thus it still makes more sense (at least in this example) to define a new
element rather than define a new attribute with new values.


> * Usability and illusion of usability
> ======================================
> 
> The problem is that
> - every people fluent in english and

The issue of using English element names is not unique to a <time> element.

While you may have good points about English vs. non-English element names,
and while I may even agree with you about them, you should make such
arguments about *all* new element names and attribute names and value names
etc.

If you truly believe this is a problem, then why should any W3C spec
introduce any new English named elements, attributes, values, properties
etc.?

Answering that question is beyond my expertise/experience so I will step
aside an let others step in.

AFAICT there is already a convention for W3C to use English names for
elements etc. and thus I work within what I perceive to be the established
convention.

You can continue to argue that convention independent of the particular
debates for specific elements.


> - defending the argument of usability and readability of documents
> never think in terms of real people.

Of course they do.  I refer to the more rapid growth of HTML above all other
document formats which has been widely attribute to not only its usefulness
but to the fact that millions of *real* people could view source and make
their own.

> The real usability will be not see the tags at all.

<sarcasm>
Right.  That's why we have a web of hyperlinked Word documents.  Or a Web of
hyperlinked PDF documents.  Or any document format with a decent tool that
hides the tags/dataformat.
</sarcasm>

Karl, unless you can point to some studies or empirical data, I say this
point is while theoretically attractive (sure seems like it would be easier
to not deal with tags!), it is empirically *false*.

> The second real usability would be to have your elements in your own
> languages.

This is part of the above argument about the convention of English names of
elements etc.

Perhaps this is usability vs. interoperability problem.

> I know many computing engineers in France who do not speak english,
> and it's worse in some parts of the population.
> 
> Per se
> <time> is less readable than <temps> for a french
> <time> is less readable than <??> for a chinese.

No argument from me about that -- see above.

I will follow on another on-topic thread, since this has become about use of
'class' and (non)-English element names which has *nothing* in particular to
do with XHTML <time> element proposal.


> A solution to this last problem could be realized if you have 3 levels.
> 
> 1. The document itself on the disc with elements in english (for the
> sake of backward compatibility, but just representing bits)
> 
> 2. The document displayed in an Authoring tool with your own language.
> (Here a need to define the equivalent names for the document in each
> languages. It could be done by reviewed bindings.)
> 
> 3. The rendering in the User Agent. (as usual)
> 
> This would improve the usability for those who wants to read the code.
> Maybe I could ask to Daniel if we could demonstrate that in Composer in
> View source mode.

This all sounds fine to me but again is not an argument against have a
<time> element.  In fact, sounds like in (1) you agree with me.


>> A big point of simplicity is to actually reduce expressivity ("power")
>> in
>> order to increase ease of readability/understanding/use, some might
>> even say accessibility as well.
> 
> <time> is not readable for a chinese.

Again this is the argument against the W3C convention of English element
names and has nothing to do with the <time> proposal in particular.  You
might as well argue against all new elements in XHTML2.0 and all other W3C
languages.

Tantek

Received on Sunday, 2 November 2003 13:15:45 UTC