Welcome to WebHeadStart.org

Web Technologies

Sponsored By

WebHeadStart.org is currently in beta.
Please pardon our appearance as we work to provide you with the most comprehensive reference on today's web technologies.

Interested in advertising on WebHeadStart? Become an advertising partner today!

[WWW-HTML Mailing List Archive Home] [Messages By Thread] [Messages By Date]

Re: XHTML2: Proposal for total separation of semantics from structure

From: Orion Adrian <orion.adrian@gmail.com>
Date: Tue, 30 Aug 2005 15:23:56 -0400
Message-ID: <abd6c8010508301223e49dd2e@mail.gmail.com>
To: www-html@w3.org

On 8/30/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Orion Adrian schreef:
> >>> I disagree, for element names should carry the main semantics, and
> >>> prefer myself something like this:
> >>>
> >>>   <"some parent with only block children allowed">
> >>>     <code class="pre"/>
> >>>   </>
> >>>
> >> I disagree with that, class doesn't convey any semantic information, and
> >> if the code being preformatted is important to the clarity or even
> >> functioning of the code, it should use <pre> appropriately and not rely
> >> on the stylesheet.
> >>
> > Why doesn't class convey semantic information?
> Because it doesn't, per specification. Quoting:
> 
>    The class attribute has several roles in HTML:
>        * As a style sheet selector (when an author wishes to assign
> style information to a set of elements).
>        * For general purpose processing by user agents.
> 
> > Why aren't we styling
> > elements based on their semantic classification as opposed to string
> > that people just make up like "l76blue". I'd rather limit class to
> > semantic structures and just style those.
> >
> But that is not the case right now, in HTML 4, and existing content will
> contain nonsensical information in their class attributes, which makes
> them useless to process. A set of values for the class attribute could
> be standardised, but because there's so much 'noise', it can't be relied
> upon, which makes it quite unreliable and useless from a machine
> processing point of view (which is why they are added in the first place).
> 
> I'd say that is the reason new attributes such as @role and @property
> are needed. Those can make a fresh start, and because they are only
> specified when they actually have semantic meaning, a user agent
> (including search engines) can do something with it...

Except both @role and @property are being used for something else.
@class is a field that lists the objects that meet the following
statement.

This element is-a object.
OR
This element can-be-classified-as object.

@property is more open. Specifically it represents the relationship
with the contents providing the object value.

The fundamental problem with @property is that on elements that aren't
meta it doesn't allow for all the relationships that can exist for an
element. If you use it for an is-a relationship it doesn't cover the
whatever other relationships might pop up much less an additional
relationship other than is-a.

What we need is a way to represent triplets for an element (like meta,
but for any element). Class was useful, but what we need is a typed
version of class specifically for is-a relationships because they are
the most common for determining behavior and appearance.

-- 

Orion Adrian
Received on Tuesday, 30 August 2005 19:24:04 GMT
Valid XHTML 1.0! Valid CSS! Site Map | Privacy Policy | Terms of Use | WebHeadStart.org © 2005 All Rights Reserved.