- From: Laurens Holst <lholst@students.cs.uu.nl>
- Date: Wed, 13 Jul 2005 12:12:45 +0200
- To: Orion Adrian <orion.adrian@gmail.com>
- Cc: www-style@w3.org
Orion Adrian wrote: >But this only happens when we move the primary layout mechanism to the >device, make it semantic in nature and not content-based in nature and >finally make it content. > >Each region of the layout would specify which types of content it >allows (e.g. class), not which content it contains (i.e. src). This is >where XFrames fails. > >Then we can see about moving formatting too. > > I have replied multiple times to this already, with the response that XHTML 2.0 *does this* by means of its role attribute [1]. Semantics are not the domain of CSS, but of the underlying language such as XHTML 2.0. In a previous message you said: >2) No new property should be used to hide or modify content in such a >way that it's non-existence should fundamentally change the meaning of >the styled document. > Here, too, things that change the meaning of the styled document should be expressed in the markup for the document, and not in CSS. So your ‘guideline’ doesn’t really makse sense, because the situation that you sketch (new -or old, why make a distinction?- properties fundamentally changing the meaning) shouldn’t arise in the first place. If HTML adds an <invisible> element (assuming for a moment that it actually expresses something semantic), it is the task of the user agent, if it does not support CSS, to still render it appropriately. That is why Lynx works, even though it doesn’t understand CSS. Anyways, now you’re really starting to repeat yourself. I’ve heard this already. XFrames may be insufficient, but if it is, XFrames should be changed. This is outside the domain of CSS. So you’re writing this to the wrong list. ~Grauw [1] http://www.w3.org/TR/xhtml2/mod-role.html#col_Role -- 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, 13 July 2005 10:12:46 UTC