RE: CSS 4?

<paste>
>
> Golden hammer anti-pattern... you even manage to suggest using 
> non-standard approaches...

Uh, you specifically _asked_ how you would do those two things using CSS.
I was merely answering your questions to the best of my ability, first
explaining why the question was a poor one, and then giving you increasingly
practical answers. You can't accuse me of not knowing what other
technologies are available to do a task if you specifically ask me to
disregard those other technologies...
</paste>

OK, it just seemed silly. Let me respond inline below.

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Ian Hickson
> Sent: Thursday, October 23, 2003 8:46 AM
> To: Robert Koberg
> Cc: 'Tantek Çelik'; www-style@w3.org
> 
> 
> On Thu, 23 Oct 2003, Robert Koberg wrote:
> >
> > With CSS, how would you take this XML element:
> >    <link idref="a1234"/>
> > And style it into:
> >    <a style="internalLink" href="../folder/page.html">page</a>
> 
> That question is meaningless. You are adding semantics, not styling.

I would say it is absurd, not meaningless (if it had no meaning, how can you
answer it?). I put in to point out that CSS cannot handle the situation.
What actually happens (in our case, which I did not feel was necessary to
show the absurdity) is that the @idref is used in an XSL transformation to
lookup a node in a hierarchical site representation and determines the
document relative path. This way all internal links can be guaranteed to be
valid. Also, the page name and link inner text can be retrieved from a name
attribute or generated from a child label element. Since, the XSL matches on
the link, and it is known that this element means internal link then it can
provide the class (I miswrote style...) attribute with the correct class
name. This is all done on the server.

> 
> If the <link> element above is in a proprietary language, then it
> shouldn't be sent over the wire anyway, it should be transformed on the
> server side.

Why shouldn't you send proprietary XML and transform it client-side into
(X)HTML? I don't do this, but I was wondering if there is some reason.

> 
> If the <link> element is in a fictional but well-known standard namespace,
> then it would already have the linking semantics, and so it would already
> match the :link and :visited pseudo-classes as appropriate.

I don't understand this.

> 
> In the extreme case, however, it would be possible to do something like:
> 
>    link { binding: url(internalLinks.xml#link); }
> 
> ...where internalLinks.xml is a BECSS binding that defines how elements
> should be turned into links. (BECSS is still in development, though. At
> the moment, you would use -moz-binding or behavior depending on whether
> you were targetting Mozilla or WinIE.)

This seems to be going back to the bad-old-days.

> 
> 
> > Or this element:
> >    <submit servlet="login"/>
> > Into:
> >    <form id="loginForm" action="login" method="post">
> >    ...
> >    </form>
> 
> The same arguments and solutions apply here.

yes

> 
> 
> > Or, using CSS, turn the things above (or anything) into a PDF?
> 
> There are several CSS-to-PDF systems available.

In a very limited way.

-Rob

> 
> --
> Ian Hickson                                      )\._.,--....,'``.    fL
> U+1047E                                         /,   _.. \   _\  ;`._ ,.
> http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 23 October 2003 13:00:01 UTC