Re: Another approch to style hyperlinks

* Jonny Axelsson wrote:
>On the contrary, the greatest argument *for* CSS hyperlinking is 
>accessibility. CSS doesn't add links. All links are a part of the markup and 
>can be acted upon as natural for the UA, whether it is a browser or a robot.

>This is reminiscent of the discussion of a fixed or flexible vocabulary. 
>Should you have a fixed markup for giving text a typeface (the FACE 
>attribute of the FONT element) or should that be an attachable property of 
>any element (CSS font-family). The UA at the time of writing may have 
>implemented a certain number of vocabularies, but will have no way of adding 
>new ones.

And they never will, since it would require additional information from
somewhere outside. This is pretty much the XML+CSS discussion I've heard
very often. People are somehow convinced, that it might be a good idea
to use their new markup language and put it on the web using CSS to give
it some presentational hints, e.g.

  <?xml-stylesheet href='#foo'
  <!DOCTYPE document [
  <!ATTLIST style
    id ID #REQUIRED
  >]>
  <document>
    <style id='foo'>
      style { display: none }
      heading, para { display: block }
      heading { font-size: xx-large }
    </style>    
    <heading>Weather is nice today</heading>
    <para>Go out for a walk.</para>
  </document>

This may work for some document languages, that are highly compatible
with XHTML, since CSS requires a certain document structure to work
well. I consider this a very bad idea, since user agents not capable of
applying CSS cannot present this document to users or even if they are
able to apply CSS, the given style sheet lacks of aural properties, thus
Voice browsers cannot present such documents. HTML says about itselves

  "To publish information for global distribution, one needs a
  universally understood language, a kind of publishing mother tongue
  that all computers may potentially understand. The publishing language
  used by the World Wide Web is HTML (from HyperText Markup Language)."

The key is that computers are able to understand the language,
understand, not just dump displaying it. The whole Semantic Web is all
about machines "understanding" our data.

To support "new" languages in terms of dump presenting it somehow to the
user, we would need some language or languages, that provide all
possible features. Do you want to turn CSS Level 4 in some monster
language that can be used to specify all SVG 2.0 features, so CSS4
implementations would be everything we need?

I've asked several times how people think this "XML in the browser"
thing should look like and Daniel Veillard gave one of the best
responses to that question on xml-dev

  Associate stylesheets to namespaces and properties to elements and
  render your document by propagation of styling rules and constaints
  between the multiple rules found in stylesheets (preregistered
  or linked).

This is certainly not possible with a single style sheet language, but
people think CSS is and/or should be this single style sheet language.

Vocubalaries are necessary, but CSS is certainly not the language to
cover the overall richness of human genius. The Web of the Future will
provide many languages to express your data. Think of modules. We will
have linking through XLink, we will have Forms through XForms. We will
have XHTML 2.0 to markup documents, we will have XHTML Events and the
XHTML DOM to provide interactivity, we will have JPEG 2000 and SVG for
graphics, SMIL for presentations. This is the way to go, various modules
provide various functionality, high level applications will be made of
low level modules. If you want to have base URIs, use XML Base, if you
don't, don't ask for interoperability and on the World Wide Web no
interoperability means no accessibility, no usability, no nothing.

If you want linking, use XLink, if you don't, the application has to
know about your language. Link presentation is fine for CSS, since CSS
is all about presentation. I am not happy with XLink providing means to
specify presentation, nor with providing behaivours and event handling.
These are out of XLinks domain. CSS should not be used to fix bad
document languages. I really see no good reason why CSS should provide
any means to say "make this activateable and do this and that on
activation", your argument

>This is how and why Opera came to implement CSS type linking. We had of 
>course HTML linking, but we needed to implement linking in WML, an XML 
>vocabulary that used a different syntax. Instead of implementing a second, 
>and certainly third and fourth and so on at a later stage, we used the Opera 
>proprietary CSS properties -set-link-source, -use-link-source and -replace 
>[2].

is a false argument. Setting up a database to make your application
"know" that this element is in that language a link and the URI may be
gathered from that attribute is the general concept, it just happend
that you used CSS syntax to set up this database. Users don't have to
attach style sheets using proprietary css properties and values to let
Opera know what elements should be links, do they? I agree implementing
linking this way is convenient, since CSS already provides means to
select elements and applications built upon CSS can easily be extended
to define all features of certain document elements, but that's no good
reason why CSS should be used that way. If CSS can be used to define
what a link is, why should authors use XLink? I really look forward to
some updated CSS UI Working Draft; the Feb 2000 draft has a lot of
issues I hope a new draft will already have solved. This draft defines
means to specify a lot of form features, but it does so in a clever way.
It does not define properties adding semantics, e.g. "this element is a
password field", it defines a 'user-modify' property. "Something is
something" is a semantic statement, CSS must not provide semantics, CSS
is for saying "something looks like", "something behaves like",
"something is presented like", and so on, semantics are out of scope for
CSS and saying "something is a link" has semantic value.

People like to use the blockquote element as example for why link
definitions are necessary. They want the blockquote element to link the
resource given in the cite attribute. That's fine. Why didn't user
agents implement means to retrieve the linked resource? Well, I consider
XHTML 2.0 to solve this by incorporating XLink and xml:base, e.g. we
might get

  <blockquote xlink:href='...'>
    <p xml:base='...'>...<a href='#...'>...</a>...</p>
  </blockquote>

This still requires conflict resolution. What to do about nested links?
We have a lot of nested links in HTML, consider

  <a href='...'><img alt='...' longdesc='...' /></a>

This is more inside CSS's domain, what to do here? How to provide means
to the user to get the long descripting of the image and let them still
be able to follow the link? The same might appear in blockquote
elements, what to do with three links? Nested blockquotes, four links,
oh my goodness.

CSS does not have to provide facitilites to describe what a link is, but
there is a serious issue, how to activate links? How to behave if a link
is activated? How to present the linked resource? CSS also has to deal
with conflict resolutions if CSS's link presentation properties clash
with XLink's presentation attributes if there will be such conflicts.
How to deal with nested links? Is CSS at all able to deal with these
issues? What issues are out of domain for CSS? Consider use cases, e.g.
W3C Recommendations link to references by links to the reference prose,
not to the resource itself. Should CSS provide means to let the user
decide, if he wants to go directly to the referenced resource or just
look at the references section? Is this a linking/markup issue, or is it
a presentational issue?

Something I like CSS Level 3 enable me is to collapse and expand
fragments of documents. Consider some article about something that
requires some knowledge of the reader. It would be good to provide
links to introductions to enable the reader to be properly informed
before reading further, but I as author don't want to bug experienced
readers with resources, they don't need. I like to have some possible
XHTML 2.0 document with

  <ul>
    <caption>Prior Reading</caption>
    <li xlink:href='...'>some article</li>
    <li xlink:href='...'>another article</li>
    ...
  </ul>

I want this list to be collapsed by default, but expanded on activating
"Prior Reading". This is no linking issue, I don't think I have to add
some ID magic, to treat the ul element as some link or linkable
resource, there should be some convenient way to enable some kind of
activation, but it is not necessary to define caption is some kind of
link in CSS. It isn't. A solution may end up with defining caption as
some kind of activator and people may think of this activator as a link,
but I think intentions matter, CSS has to address the right problems,
thus the right questions have to be asked.

regards,
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/

Received on Sunday, 30 September 2001 02:00:14 UTC