- From: Karl Dubost <karl@w3.org>
- Date: Sun, 2 Nov 2003 22:07:10 -0500
- To: Tantek Çelik <tantek@cs.stanford.edu>
- Cc: <www-html@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