In article <MPG.179ed89c4035df85989712@news.povray.org> , Lutz-Peter Hooge
<lpv### [at] gmxde>  wrote:

> With "a:hover { text-decoration: underline ; color: #ff0000 }"
> you say, that you want the content of the element "a" to be underlined if
> the mouse is hovering above it.
> Thats EXACTLY what Mozilla does.

No, it is still a bug in Mozilla.  They just follow the standard in a "take
every letter in the standard no matter how ambiguous and wrong it is" way.
obviously this is just asking for trouble.  But hey, they are the gods who
have to teach the world proper standard HTML, right.

This is like a spellchecker correcting every word it doesn't know.  After
all, it knows all words, and there cannot be new ones and it in unfailable.
What is being forgotten here is that blind enforcing of something by a
program is the worst of all implementations.

The consequence of this is that Mozilla's render engine is a badly broken
mess because of the developers' failure to understand something as simple as
"compatibility" (not that it ever was their strength when developing
Netscape 1-4).  I had really hoped after so many years they had learned
their lesson and would have come up with something that does a good job
rendering HTML :-(

> Hint: The pseudo-class :hover is NOT restricted to links.

This was only introduced in CSS2 which apparently the people who introduced
this nonsense even failed to notice that it will break every a-name tag
variant out there.  Or they failed to put this exception in a obvious
location.  But hey, with the bloat of their standards, that is a mistake
easy to make :-(

The specification in CSS1 is correct and makes it explicit:

>>All 'A' elements with an 'HREF' attribute will be put into one and only one of
these groups (i.e. target anchors are not affected). <<

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3d34c5e8@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   So this means that it's all the other browsers which are broken because
> they don't do what the CSS is telling them to do?-)

To the contrary, all other browsers behave like specified by CSS1.  As I
just pointed out in my other reply to him the bug might even be in the CSS2
spec and the Mozilla developers simply failed to notice that :-(  Of course,
that means it is still a bug in Mozilla.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Wed, 17 Jul 2002 12:01:23 +0200, Thorsten Froehlich wrote:
 
> This is like a spellchecker correcting every word it doesn't know.  After
> all, it knows all words, and there cannot be new ones and it in unfailable.
> What is being forgotten here is that blind enforcing of something by a
> program is the worst of all implementations.

You mean like enforcing that mail and web be on the same ISP connection?

-- 
#local i=.1;#local I=(i/i)/i;#local l=(i+i)/i;#local ll=(I/i)/l;box{<-ll,
-((I/I)+l),-ll><ll,-l,ll>pigment{checker scale l}finish{ambient((I/l)/I)+
(l/I)}}sphere{<i-i,l-l,(I/l)>l/l pigment{rgb((I/l)/I)}finish{reflection((
I/l)/I)-(l/I)specular(I/l)/I}}light_source{<I-l,I+I,(I-l)/l>l/l} // Steve

Post a reply to this message

In article <slr### [at] zeroppsorguk> , Steve 
<ste### [at] zeroppsuklinuxnet>  wrote:

> You mean like enforcing that mail and web be on the same ISP connection?

I am not aware of Mozilla enfocing that.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Wed, 17 Jul 2002 12:01:23 +0200, Thorsten Froehlich <tho### [at] trfde> wrote:
> In article <MPG.179ed89c4035df85989712@news.povray.org> , Lutz-Peter Hooge
><lpv### [at] gmxde>  wrote:
> 
>> With "a:hover { text-decoration: underline ; color: #ff0000 }"
>> you say, that you want the content of the element "a" to be underlined if
>> the mouse is hovering above it.
>> Thats EXACTLY what Mozilla does.
> 
> No, it is still a bug in Mozilla.

Does this mean my Mozilla[1] is doubly buggy because it doesn't
apply a:hover to <a name="..."> tags?

On a related note, the whole :hover thing is the single most
evil annoyance invented. About the only useful thing you can
get out of it is define :hover { display: none; } to everything.

Oh well, Mozilla *IS* a bloated piece of crap, but so are most
of the browsers available. Those that aren't, are slightly
more compact pieces of crap. I still wish someone would make
one that allowed you to disable the recognition of ANY html
tag or CSS attribute, selectively ignore colours and rendered
the page only when there would be absolutely no further changes
to the layout. The ability to drop the support for these ignored
items and such wholly unnecessary shite as Javascript and plugin
support from the executable at compile time would almost push
the whole package above "tolerable".

[F'ups set. Shouldn't someone take the whole thread to .off-topic
or something?]


[1] 0.9.9, because that's what's packaged in Debian Woody
and I don't know enough about computers to change it.

-- 
Antti Arola, edistyksenvastainen retropaskiainen

This message written by a complete asshole.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> To the contrary, all other browsers behave like specified by CSS1.  As I
> just pointed out in my other reply to him the bug might even be in the CSS2
> spec and the Mozilla developers simply failed to notice that :-(  Of course,
> that means it is still a bug in Mozilla.

  Sorry, but I still don't understand.
  If the CSS says "whenever the cursor is over a block delimited with a
tag named 'a', underline this block", and if the browser does exactly what
the CSS says, why is it broken?
  It sounds to me that what you want is that the browser makes an exception
like "ok, this is a tag called 'a', but hey, I know this is a link with
a 'name' specifier, so I should ignore what the CSS says about this and
do something else which the CSS does not say". That sounds more like a kludge
to me.

  After all, AFAIK you can specify a different behaviour for a tag with
a certain attribute, so it's possible to say in the CSS that the 'a' tag
with the 'name' attribute should have no special styles. IMHO this would
be the most logical way and will probably work in most browsers. It is not
a kludge.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3d354079@news.povray.org>, tho### [at] trfde says...

> No, it is still a bug in Mozilla.

LOL.
So what you want is, that the browser always does what you intended it to 
do instead of what you told it to?
When programming, do you also simply omit the parentheses and leave it to 
the compiler to figure out where they are supposed to be (be indentation 
or something)?

> this nonsense even failed to notice that it will break every a-name tag
> variant out there.  Or they failed to put this exception in a obvious
> location.  But hey, with the bloat of their standards, that is a mistake
> easy to make :-(
> 
> The specification in CSS1 is correct and makes it explicit:
> 
> >>All 'A' elements with an 'HREF' attribute will be put into one and 
> only one of these groups (i.e. target anchors are not affected). <<

There is no such thing like a ":hover" pseudo class in CSS1.
What you quoted applies only to the pseudo-classes ":link" ":visited" and 
":active".

What about really reading the specs before complaining about them?

Lutz-Peter

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3d35887f@news.povray.org...

>   After all, AFAIK you can specify a different behaviour for a tag with
> a certain attribute, so it's possible to say in the CSS that the 'a' tag
> with the 'name' attribute should have no special styles. IMHO this would
> be the most logical way and will probably work in most browsers. It is not
> a kludge.

Hmm, iirc you can't - you would have to specify a class for each <a
name=foobar> - e.g. <a name=foobar class="dont_ul">, which would be a major
pain.

A more logical solution would be: <a name=foobar></a> - after all, what the hell
is it going to underline? IIRC this is what I do on my pages.

Just out of curiosity, what happens with <a name=foobar /> in Mozilla (i.e. with
/> but no closing </a>)?

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> A more logical solution would be: <a name=foobar></a> - after all, what the hell
> is it going to underline? IIRC this is what I do on my pages.

  Or just remove the hover thingie (as someone pointed out, it seems to be
a non-standard extension anyways).

> Just out of curiosity, what happens with <a name=foobar /> in Mozilla (i.e. with
> /> but no closing </a>)?

  I would try, but I don't remember CSS from memory so well as to write
the case discussed here.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3d344827@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

>In article <jer### [at] netplexaussieorg> , Jerry 
><jer### [at] acusdedu>  wrote:
>
>> An anchor needs a closing tag in the same way as <em> and <strong> need
>> closing tags. There isn't any "implied ending" except perhaps at the end
>> of a paragraph-level tag.
>
>But then, why does Mozilla turn it into a *link*, inferring that it has a
>"href" attribute while it does not?  That is a bug!!!  The standard is very

That may or may not be a bug; I'd have to see the original code to know 
for sure; when leaving out required ending tags, behaviour can sometimes 
become undefined, for example. I was commenting only on the claim that 
anchors of the name variety do not have to have ending tags, that they 
have an implied ending tag that makes them empty, and that they have 
exhibited this behaviour from the start. They do need ending tags, and 
they have needed ending tags from the beginning, and in the beginning 
they couldn't be empty.

Jerry
-- 
http://www.hoboes.com/jerry/
"Give a man a fish and you feed him for a day. Teach him to fish, and you've
depleted the lake."--It Isn't Murder If They're Yankees
(http://www.hoboes.com/jerry/Murder/)

Post a reply to this message