Re: [xhtml2] Questions

>> Such a guide might be nice. Although I think that a tight 
>> specification should be enough. The above addressed questions should 
>> be clear from the specification.
> 
> Not necessary, you can't cover all the usage of an attribute or an 
> element. It really depends on the context and the use. Don't think 
> uniquely in terms of visual Desktop browsers with a human behind.

I don't. I agree that you can't specify all use cases for a particular 
element or attribute, but I do think a lot of elements could be better 
defined on what they should/must contain and should/must not contain.


>> Maybe some RDF attribute should be developed? So elements can be given
>> more specific semantics without the need for CLASS "hacks" or "ugly
>> workarounds".
> 
> There's no hacks at all. It's because CSS 1, 2, 2.1 doesn't support 
> namespaces at all, and "dc:title" has no more value than "title" and 
> XHTML 2.0 will have a mechanism to create Graph-like assertions.

As it has no more value than "foo". However, that was exactly my point.

(Having namespaces in values (qnames iirc) makes things look like a mess 
by the way. But that's just my humble opinion.)


>> Maybe because the specification doesn't define how a browser should
>> treat the attribute exactly? It doesn't sound really like good design
>> either to hide information that should be displayed inside an attribute.
> 
> Because it's not easy to define. Some people will want it displayed, 
> some others not, some will want to have this behaviour, etc. It's always 
> the balance between the Meaning and the Behaviour of your language.

Which will make it not usable (and not used) in the end. The same as 
with the LONGDESC attribute from HTML 4.01. (Maybe not a really good 
example, since IMG was evil by design from the beginning.)


>>> When there is for example an "http-like" URI. You may wish to have a
>>> contextual menu to go to the source.
>>
>> Exactly. Or having elements so people can describe the source of 
>> quotation.
>>
>>  <blockquote>
>>   <p>...</p>
>>   <p>...</p>
>>   <source href="http://example.org/">...</source>
>>  </blockquote>
>>
>> Where SOURCE can have nested inline elements.
> 
> errrr... xhtml 2.0. Why do you want to create another element which 
> already exists and can you put an href into it.
> 
> http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_cite

Since CITE would not have the same structural value as SOURCE. CITE is 
per definition an inline element, SOURCE would be a block level element, 
which would be more appropriate for use within BLOCKQUOTE. Maybe I 
should have called it BLOCKCITE instead, to make the point more clear.

(I liked the proposal from a while back, to have a certain attribute for 
each structural element to add semantics to it. Makes the whole BLOCK 
prefix thing obsolete and create more possibilities for extensions.)


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

Received on Sunday, 22 August 2004 23:08:00 UTC