W3C home > Mailing lists > Public > www-html@w3.org > November 2003

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

From: Karl Dubost <karl@w3.org>
Date: Sun, 2 Nov 2003 22:07:10 -0500
Cc: <www-html@w3.org>
To: Tantek Çelik <tantek@cs.stanford.edu>
Message-Id: <D0A6648C-0DAA-11D8-B46E-0003934BEBF0@w3.org>


Le dimanche, 2 nov 2003, à 13:12 America/Montreal, Tantek Çelik a écrit 
:
> 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.

> 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.

	:) agreed on that at 100% and here come the possibility to create 
another attribute sem="" for semantics. I don't say it's mandatory, 
just a possibility.

> 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).

Agreed on that :) which was not my initial point.

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

	s/class/sem/g

> 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.

	yep.

> 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?

Flexibility. A set of values for an attributes defines in different 
specifications: Time, Physics, geography, etc... could move forward 
faster and could be easily extensible.

<pre>
<code meaning="computing fortran maths">
C --- piece of code of a math program
C -------- IPRINT FOR MONITORING THE PRINTING
       IF(IWORK(3).EQ.0)THEN
          IPRINT=6
       ELSE
          IPRINT=IWORK(3)
       END IF
</code>
</pre>

The possible advantage I see is a link to ontologies but easily usable 
by other people.

Imagine that the defined keys, like "computing", "fortan" and "maths" 
are part of ontologies, and that you have a possibility to refer to 
them in such a way that it links to an ontology like a

<link href="http://www.example.org/defined/semantics.cow" rel="meaning" 
type="text/cow"/>

You could have a Cascading Ontology for the Web without the hurdle of 
RDF inside the document, but with the power outside of it.

> 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.

except that how many elements you will have to define for each very 
useful cases. :)

I agree that time will be wonderful  and in a sense I dream about it, 
but at the same time, I wonder if it's always the best solution.

>> * 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.

agreed. All W3C markup languages are like that and they are all english 
centric ;)

> 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.

It was my intention. Sorry to have not been clear enough.

> 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*.

:) I would like to have a study on all people writing Web documents. 
How many of them are using Frontpage, dreamweaver in wysiwyg mode, how 
many of them are looking at the source code. I wish to have such a 
study too.

To have been a teacher in University for the Web, I can tell that tags 
are the last thing they want to see and as soon as they have a wysiwyg, 
they use the wysiwyg mode.


> <time> element.  In fact, sounds like in (1) you agree with me.

I do. As I said I want a solution which is elegant ;)

> 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.

Let say. not necessary the name in the spec, but maybe a recommendation 
to authorize the editors in a visual interface to show them in other 
languages. Nothing forbids it in the spec, I just think that software 
editors didn't think about it.
Received on Sunday, 2 November 2003 22:07:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:40:09 UTC