Re: Another approch to style hyperlinks

30.09.01 07:59:06, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

>* Jonny Axelsson wrote:

>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. 

For the record I don't believe that. CSS enables presentation "views" of 
data having a tree structure and doesn't change the data in any way. 
This is handy when you know the data structure and want a visualization 
of the current dat, but there are obviously other things you would want 
to do to data too. What I meant is the flip side of that: If you do know 
the data structure you can make a view of it, and this is a Good Thing.


>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.

I agree with that. Neither presentation (e.g. CSS) nor structure (e.g. 
XML + namespaces + DTD/Schemas) are able to tell that two things in two 
different vocabularies are "the same" or related under some meaning.


>CSS should not be used to fix bad document languages. 

This is a an interesting topic, going far beyond CSS: what to do with 
bad design. CSS is powerful enough to sweep problems under the carpet 
and What You Don't See You Can Forget. Bad design can remain for 
generations. E.g. current system *still* thirty years after must take in 
account that some systems are allowed to octimate the bitstream, so 
workarounds like Base64 are still in use. Some technologies have zero 
tolerance (e.g. checksums and XML well-formedness). That is nice, but 
also on a syntactical level, I fear zero friction globally interoperable 
systems are not likely in the near future. We will need the Perls and 
XSLTs and other methods for data massaging with the subsequent data 
loss. As a user I would use all the tools at my disposition to make what 
I am served more edible to me and others (in the case of CSS, "useless-
gunk {display: none}").


>I really see no good reason why CSS should provide any means to say 
>"make this activateable and do this and that on activation", 

Link activation is relevant for the user as well as the author. It can 
be left to the UA as is currently the case (e.g. for IMG in Opera, press 
"g" to cycle between embed, activate and none), but this is a poor 
method as there is no way to take into account author hints and user 
needs.

EXAMPLE: You are browsing the web on a small resolution screen (a tiny 
device or using a huge magnification because you forgot your glasses at 
home). Your favorite site is generally well written but uses big 
navigational panels at the top, left and bottom. Right now you only want 
the functionality not the pretty (and space wasting) looks, but you 
don't want to turn off the other images, because they are useful to 
squint at. So you use a style sheet that will display the images in the 
main section, but not the ones in the navigational ones.


>>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, 

>your argument 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 

Well, I meant it more as a historical note than an argument as well as 
to show an existing use of CSS linking. To my knowledge, I didn't work 
for Opera at the time, that was the original motivation. My first 
reaction was "what a strange thing to do", but then I realized that it 
made perfect sense both from a practical and from a theoretical point of 
view.

The links lie in the markup (or externally to them in the case of link 
bases), but the use of them depend on the context. The original author 
can't know what contexts it will be used in and it is highly likely he 
will guess wrong. The text won't change, but the consequences of 
"misjudging his audience" from a hypertextual point of view may be to 
make the document useless. It can be correct in context A, and wrong in 
context B. CSS may make the hypertext correct in both contexts (using 
two different style sheets).


>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.


There are three unresolved issues for hyperlinks,
(1) Nested links
(2) Multiple links on the same element
(3) Visually overlapping links

The first two aren't really CSS issues, but more general ones. CSS 
customizes link functionality but doesn't add them (assuming that the 
final spec hoobles/extends the final recommendation to only letting CSS 
do whatever is considered the appropriate behavior). HTML avoided the 
problem by saying that this can't happen, but it can.


(1) There are many ways to generate nested links (e.g. Javascript adds 
quite a few). Informally they seem to follow a "natural" pattern, a 
replaced element will lose all contained links as a part of the 
replacement, e.g. the A in <img src="pic.png"><a 
href="go_away.html"/></img> can't be activated if "pic.png" can be 
accessed. Otherwise the innermost link (only) seems to be activated. 
Clicking on <a href="#here">here or <a href="#there">there</a></a> goes 
to "there" if the innermost link is activated, "here" otherwise. 


(2) One element can have multiple links. The current CSS proposals are 
hobbled so as this can't happen, XLink is not. Should multiple links be 
allowed, is it desirable, what should be the resolution technique?


(3) The third (UI) problem is CSS's own. Generally the visual box model 
of CSS correspond to the document tree structure. CSS1 had one 
exception, float, given

<p>What to do with <a href="#there">a <b style="float: left">floated</b> 
link</a>?</p>

the presentation would be ("_" delimiting a link to "there", one link, 
two ranges):

   _floated_ What to do with _a link_?

CSS2 inherited CSS-P (positioning, "layers"), this allows blocks to be 
stacked on top of each other. As a consequence there are several 
hyperlinking issues that I think are unresolved. If there is a box on 
top of another, one or both which contains links that can be activated, 
which ones will? What if one or both boxes/links are transparent or has 
visibility: hidden? There is a usability issue if there are visible 
links that can't be activated or invisible links that can.



>Something I like CSS Level 3 enable me is to collapse and expand 
>fragments of documents. 

Yep. I think there may be a near consensus on this point. This actually 
already exist in CSS2 (for table columns).


Jonny Axelsson, 
Documentation,
Opera Software

Received on Sunday, 30 September 2001 08:02:50 UTC