W3C home > Mailing lists > Public > www-style@w3.org > April 1998

Functional notations (was: How to tell the browser that <A> is a link.)

From: Daniel Glazman <Daniel.Glazman@der.edf.fr>
Date: Thu, 16 Apr 1998 09:23:08 +0100
Message-ID: <3535BFEC.9C2D4C87@der.edf.fr>
To: Ian Hickson <exxieh@bath.ac.uk>
CC: Rasmus Kaj <kaj@interbizz.se>, www-style@w3.org, ij@w3.org, Daniel.Glazman@der.edfgdf.fr
Ian Hickson wrote:

> >
> >This sounds really interesting to me. Would it be possible to use the
> >content of the tag in the url? Then we could have automatic dictionary
> >lookup, something like this:
> >
> >ABBR
> 
> >  personality: hyperlink;
> >  href: url(my/dictionary.html#attr(content));
> >}
> >
> >And in the <abbr>html</abbr> document, the word html would be a link
> >to the right place in the dictionary.
> 
> LOL!
> 
> Now that really is cool. Add on top of that the fragment identifier idea,
> and the dictionary page which appears could be set to only show the
> paragraph in question! I like this. I like it a lot :-)
> 
> I'm not sure how the url( 'function' would be defined to allow this though.
> Maybe it would have to be
> url(my/dictionary.html#)+attr(content)
> or some such thing.

Hello Ian, Hej Rasmus (hur mår sverige idag ?-),

This idea is VERY interesting and I am clearly supporting the concept
even if I'm not supporting the way it is done.
The href property adds to CSS knowdledge of the DTD of the document,
in this case HTML. Href should not be a grammar identifier.
And attr() can not be used in order to retrieve element's textual
content.

I proposed some time ago a quite similar processus for
the source of an image SRC so one can address it through a class or
ID and not through a URL. This could greatly help companies like mine
building and promoting a corporate CSS sheet : writers don't have
to care about URLs (which are long descriptors where very small but
strong bugs can be easily inserted) but only about classes (which
are not addresses but *words* and can be meaningful).
This has been rejected because it implements in CSS ability to modify
the structure of the document (at least attributes).
*BUT* I still strongly support this extension to CSS and your example
IMHO shows very clearly the interest of such a proposal.

I then propose to extend the attr() functional notation to be
used as a functional property on the left side of a declaration :

        IMG.logo1 {
                attr(src) : url(http://somewhere.com/wherever/logo1.gif)
                }

        <IMG CLASS=logo>

This solves the problem of the identifier.
Functional properties could be a new class of properties based on a
functional notation 'ā la' something().

Now, how can you get the textual content of an element ? This element
is rarely a #PCDATA standalone and is often composed of other elements.
In your example, ABBR is defined in HTML4 as(%inline;)* ...

[ BTW : is this really normal ? I mean, why should an abbreviation be able
  to contain EM, STRONG, INPUT, SELECT, TEXTAREA ?!? Same question for ACRONYM ?
  Ian Jacobs, if you read this, is it possible to verify that this definition
  is ok and reduction to #PCDATA should not be added to HTML issues list ?
  Just wondering ;-]

Let's suppose that we have a content() functional notation retrieving all
the #PCDATA contents of an element. Let's also imagine that we can get
rid for this example of all the character sets' problems between the contents
and a URL (english and us-ascii are not the only language and charset used
around the world, and URLs are not unicoded...).
Your example could then be described as :

        ABBR {
                attr(href) : url("/somewhere.htm#"content())
                }

Quoting the first part of the URL is IMO necessary to parse the
second part...

Conclusion : I see immediate difficulties to access to element's contents
for URL definition.

	- character sets
	- structure of the element
	- spaces included in element's contents and other URL special chars
	- "We do not expect CSS to evolve into: a programming language",
          excerpt from CSS1

</Daniel>
Received on Thursday, 16 April 1998 03:35:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:54 GMT