Re: XHTML 2.0 - dfn : Content model and usability

Karl Dubost wrote:

>> There are a number of other elements that also correspond to specific
>> traditional uses of italics.
>
> which is very tied to our western cultures and latin alphabet.
>
> In this discussion, I'm focussing on the use of dfn to make it as  
> useful as possible not about rendering :) The rendering of semantics  
> elements with a certain typography had a particular meaning in  
> certain cultures and publishers (different conventions depending on  
> the publishers) and CSS is here for that. :) It just gives a solution  
> for western people who are able to read a Web page. ;)

Just like western languages, Japanese may have emphasis as well, and can 
also contain definitions. Whether that is actually marked up visibly and 
how it is rendered is a matter of CSS.

Also, HTML contains the <bdo> element and the dir attribute for 
controlling text orientation with mixed scripts. I think you agree with 
me that the fact that they are not appliccable to western languages does 
not mean that they should not be in the specification.

What I was trying to point out is that typography styling *is* a 
justification for markup. However the markup being semantic, it captures 
the *reason* for the styling (e.g. emphasis), and not the styling itself 
(e.g. italics), which can vary between different scripts and applications.

HTML is a document markup language, and everything that is necessary for 
marking up a document deserves a tag (well...). Many documents cannot be 
marked up properly without <em>, <dfn> etc. For some things you will 
need to use a span with a class, currently, because there is no semantic 
equivalent, but the RDF extensions to XHTML 2.0 (role and property) 
should resolve that issue, if I understand correctly.

I’m not really familiar with RDF yet (even though I just had an exam on 
the Semantic Web :)), but isn’t that something you could use to express 
what definition belongs to the term?

--

Something else: with regard to the block vs. inline thing that was 
raised a few messages ago - even if there were no distinction between 
the two, there would still be problems marking up e.g. a definition 
which spans one and a half paragraph. So getting rid of such a 
distinction will not solve this particular problem.

Also, inline markup is typically rendered differently than block markup, 
e.g. <quote> typically inserts “quotes”, while a blockquote gets 
indented. Similarly, inline MathML is rendered more compact than 
block-level MathML (e.g. a sum displayed inline has the parameters 
rendered next to the ∑ instead of on top and below it in order to save 
vertical space). So there is a need for the distinction. And there are 
probably many other reasons.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

Received on Wednesday, 6 July 2005 11:47:59 UTC