Image replacement - Can it be clickable?

[Kerberos]

I followed Dan Cederholm's image replacement tutorial, to replace a header
tag by a logo. The h1 is clickable if no CSS is applied but it I replace
it by the logo, the area isn't clickable anymore when I pass the mouse
over the logo. Is there a way to replace a link by an image that will
still be clickable?
Thanks,

--

Kerberos.

http://www.opera.com
http://www.freebsd.org
http://www.auriance.com
http://www.osresources.com
http://exodus.jabberstudio.org

[Spartanicus]

(was Re: Image replacement - Can it be clickable?)

Christoph Paeper <ch**************@nurfuerspam.de> wrote:

[1] I don't expect these upcoming methods to be able to replace current
practices, the people who draft css specs imo don't understand style and
design one bit.

Well, you are free to raise your concerns on <ww*******@w3.org>.

Pointless, it would be like walking into a kitchen and start proclaiming
"Your food may be healthy, but it doesn't look attractive, it smells bad
and it doesn't taste good, you guys can't cook."

The only way to get a good style and layout language would be to:

1) Leave css to die a natural death.
2) Start from scratch.
3) Adopt a development model that has impetus.
4) Adopt a single/central code base that all implementors must use with
version control that encourages users to keep updated.
5) Put designers in charge of setting the goals.
6) Put technicians in charge of implementation.
7) Ensure that the above two groups work constructively together.

For those not familiar with my position, the above must not be
interpreted as an argument against the usage of css, I always have and
will continue to advocate it's use. The above reflects my long held view
that css has failed to achieve what it should have achieved, and that
it's features are poor. Poor as it is, it's the best system that we
currently have to our disposal.

But I wouldn't be surprised if ultimately css fails and gets replaced by
a proprietary commercial product, that would be a sad day because the
technical quality of such a product would likely be poor, and we would
be tied to a single vendor.

--
Spartanicus

[Christoph Paeper]

*Spartanicus* <[e-mail]>:

Christoph Paeper <ch**************@nurfuerspam.de> wrote:

Well, you are free to raise your concerns on <ww*******@w3.org>.
Pointless, it would be like walking into a kitchen and start proclaiming
"Your food may be healthy, but it doesn't look attractive, it smells bad
and it doesn't taste good, you guys can't cook."

The only way to get a good style and layout language would be to:

I think CSS is a pretty good style language, I especially like the syntax,
selectors and inheritance/cascade despite some flaws. It's not that good
at layout, though, which is in some part due to the mark-up languages it
is intended to be used with and in another large part due to the idea of
unconditional incremental top to bottom rendering.
1) Leave css to die a natural death.
Won't happen anymore of course, just like HTML*3.2 or tagsoup in general
won't.
2) Start from scratch.
3) Adopt a development model that has impetus.
Such as? I agree that the development process of CSS and other recent W3C
specifications seems to be rather slow and never staying in publicized
timelines.
4) Adopt a single/central code base that all implementors must use with
version control that encourages users to keep updated.
Mandatory code is never good, reference implementations can be OTOH.
5) Put designers in charge of setting the goals.
Real designers are hard to find (not only in webdesign). The much
available "deezyners" OTOH would have gotten us pixel-perfect layout and
nothing else.
6) Put technicians in charge of implementation.
Good engineers are also rare. Let alone people who can write
specifications that are understandable *and* implementable while still
using correct wording and be consistent with other specs and logical in
itself and, finally, achieving the set goals.
7) Ensure that the above two groups work constructively together.
If you get good design and technology people together, that shouldn't be a
problem, because both groups would know enough about the other field to be
reasonable in theirs.
that css has failed to achieve what it should have achieved, and that
it's features are poor. Poor as it is, it's the best system that we
currently have to our disposal.
The worst thing about CSS (and many other standards that don't require
certification) is incomplete and incorrect support in implementations. The
best thing about CSS is, as you say, that there are implementations at all.
But I wouldn't be surprised if ultimately css fails and gets replaced by
a proprietary commercial product,
Images, PDF and Flash have their niches, but those are replacements for
the combination of CSS and HTML (or XML), not for CSS alone. The WWW will
be HTML-based for a long, long time to come, and with it CSS.
that would be a sad day because the technical quality of such a product
would likely be poor,
What if the developper followed your above guidelines?
and we would be tied to a single vendor.

That's one reason for why it won't happen. PDF and SWF are both (well?)
publically documented.

--
A magician pulls rabbits out of hats.
An experimental psychologist pulls habits out of rats.

[Spartanicus]

Christoph Paeper <ch**************@nurfuerspam.de> wrote:

3) Adopt a development model that has impetus.

Such as?

Therein lies a challenge, the current model seems to rely on some
personnel time being granted from commercial companies or from academic
institutions. There is little incentive within such a structure to drive
forward the development process with the required vigor. Adopting a
commercial model has the potential of solving that, but that poses other
challenges like "where does the revenue come from?".

4) Adopt a single/central code base that all implementors must use with
version control that encourages users to keep updated.

Mandatory code is never good, reference implementations can be OTOH.

The current situation is that the implementation differences and
different bugs between the various browsers contributes significantly to
the frustration amongst authors, and the resulting disappointing
adaptation of the technology.

5) Put designers in charge of setting the goals.

Real designers are hard to find (not only in webdesign). The much
available "deezyners" OTOH would have gotten us pixel-perfect layout and
nothing else.

That's why half the development team should consist of technicians.

6) Put technicians in charge of implementation.

Good engineers are also rare. Let alone people who can write
specifications that are understandable *and* implementable

Designers should form the other half the development team, they will
complain when the technicians come up with the mumbo jumbo that can
currently be found in the css specs. Currently the specs require
significant technical skills to be understood properly, this is madness
since it is the designers who are supposed to use the language.

But a question that should precede the creation of a new style language
should be "is it realistic to expect designers to learn what may to some
extent be a technical language?".

If as I suspect the answer to that question is no, then it may be
necessary to incorporate the development of a shell application that
will write the code as an integral part of creating a good style and
layout language. How "good" a language is should be measured in no small
part by how it is adopted by the people who it is for. For a successful
adaptation to happen it needs attractive features and it must be easy to
use by the people that it is for.

That would suggest that a commercial company is best suited to develop
such a language, they can generate the required revenue from selling the
authoring software, and since designers are the customers there is
impetus to create the sort of features designers would like. Amateur
content creators could be catered for by a free "lite" version of such
software. To further facilitate adoption the language format should
continue to be plain text.

7) Ensure that the above two groups work constructively together.

If you get good design and technology people together, that shouldn't be a
problem, because both groups would know enough about the other field to be
reasonable in theirs.

Designers and technicians are two very distinct breads of animals, in my
experience they don't often understand or value one another.

that css has failed to achieve what it should have achieved, and that
it's features are poor. Poor as it is, it's the best system that we
currently have to our disposal.

The worst thing about CSS (and many other standards that don't require
certification) is incomplete and incorrect support in implementations.

Hence my argument for a single code base, this in itself has obvious
drawbacks, but the resulting uniform rendering and version control is
imo more important.

But I wouldn't be surprised if ultimately css fails and gets replaced by
a proprietary commercial product,

Images, PDF and Flash have their niches, but those are replacements for
the combination of CSS and HTML (or XML), not for CSS alone.

Therein lies a fundamental obstacle to the commercial development of a
style language. Commercial companies that don't have competition
typically don't give a monkey about open content formats, in fact most
would consider them as a threat to their revenue. Which is why
Macromedia is attempting to peddle Flash as the all in one replacement
for all those "difficult" web publishing languages.

--
Spartanicus

[Christoph Paeper]

*Spartanicus* <[e-mail]>:

Christoph Paeper <ch**************@nurfuerspam.de> wrote:

The current situation is that the implementation differences and
different bugs between the various browsers contributes significantly to
the frustration amongst authors, and the resulting disappointing
adaptation of the technology.
W3C's conclusion being a changed ratification process with implementation
requirement and test suites.
Currently the specs require
significant technical skills to be understood properly, this is madness
since it is the designers who are supposed to use the language.
Most of the advanced stuff is only interesting for implementators, though.
Sadly coders don't read the specs themselves either, letting that to QA.
But a question that should precede the creation of a new style language
should be "is it realistic to expect designers to learn what may to some
extent be a technical language?".
They've learned to use pen and paper, too---real and virtual ones. The
style language is just another tool. Of course, those who rather call
themselves "graphic artists" won't probably touch any software that is not
or not required to run Adobe Photoshop.
As a software architect I wouldn't want to have to know in and out each
programming language my coders used, just their basic concepts and
(dis)advantages.
necessary to incorporate the development of a shell application that
will write the code as an integral part of creating a good style and
layout language.
All automatic code generators I have seen so far only then didn't produce
garbage when properly used by trained people. Even then the output isn't
as good as hand-written and the software is only used, because people are
(thought to be) more expensive. You could of course counter-act that by
making the language non-human-readable (and neither -writable). What about
platform independence?
Designers and technicians are two very distinct breads of animals, in my
experience they don't often understand or value one another.

Exactly. Like I said, good ones of either kind are rare. Part of the
problem is the way of schooling, which is often way to specific. "Try to
learn everything about something and something about everything", is not
that bad a motto.

The worst thing about CSS (...) is incomplete and incorrect support in
implementations.

Hence my argument for a single code base, this in itself has obvious
drawbacks, but the resulting uniform rendering and version control is
imo more important.

I consider the drawbacks of such monopoly very undesirable.
Isn't Microsoft intending to introduce XAML as a new competitor into the
web application market (now predominated by "DHTML")? Some say the
competitor in that market, that IE was becoming against its host OS, was
the main reason for its stop of development, because it was given away for
free.

--
The Hitchhiker's Guide to the Galaxy:
"In the beginning the Universe was created.
This has made a lot of people very angry
and been widely regarded as a bad move."