<li> inside of <a>?

[Robert Ferber]

Hi,

Stupid validator doesn't accept <li> inside of <a>.

Does anybody know a good way to make blocked links (= links that work in the
whole block and not just on the text) in a standard compliant way?

Thanks a lot

P.S. <div> doesn't work inside of <a> either. :-(

 

[Dylan Parry]

Spake Robert Ferber unto thee:

Stupid validator doesn't accept <li> inside of <a>.

That's because <li> is a block level element, but <a> is inline. You
cannot put a block level element inside an inline element.

What exactly are you trying to achieve? Could it be "solved" by using the
<a> as block level by setting "display: block;" in your stylesheet
(bearing in mind that it is still an inline element, so still cannot
contain block elements)?

 

[Robert Ferber]

Spake Robert Ferber unto thee:


That's because <li> is a block level element, but <a> is inline. You
cannot put a block level element inside an inline element.

Is there any reason for that rule?

Dumb meaningless rules are the main reason why it's so hard to code
compliant HTML pages.

<a> can contain a picture, which is a rectangle, I don't see any reason why
it shouldn't contain a <div> or <li> which is (or can be) just another
rectangle.

(Rant ends here)

What exactly are you trying to achieve?

A square with a opaque background and a border that can be clicked (as a
link) anywhere, not just on the text inside.
Even if I choose not to put any text in it, it should still be clickable in
the whole square.

Could it be "solved" by using the
<a> as block level by setting "display: block;" in your stylesheet
(bearing in mind that it is still an inline element, so still cannot
contain block elements)?

No, the display-attribute doesn't affect this.

This *almost* works and validates:

a.m1
{ position : absolute;
top: 5px;
width:150px;
height:20px;
border-width: 1px;
border-color: red;
border-style:solid;
background: #fff;
text-align: center;
display: block;
}
a:hover
{
background-color: yellow;
}

The problem is that now the background color is ignored and it's always
transparent!

The funny thing is that <a><div></div></a> works as intended, but does not
validate.

 

[Michael Winter]

Dylan Parry wrote:
[snip]

That's because <li> is a block level element, but <a> is inline. You
cannot put a block level element inside an inline element.

Is there any reason for that rule?

Structure, and plain common sense. HTML is a structural language.
Block-level elements can contain other block-level elements and inline
elements. Inline elements can only contain other inline elements. What's
objectionable about that?

Dumb meaningless rules are the main reason why it's so hard to code
compliant HTML pages.

Hard? Please.

<a> can contain a picture, which is a rectangle, I don't see any reason
why it shouldn't contain a <div> or <li> which is (or can be) just
another rectangle.

DIVs and list items are containers. An image is not. In fact, it's easy
enough to view an image as replacement for text, just in the same way that
text replaces an image if it can't be displayed. As text is inline, why
shouldn't an image be?

Moreover, you can't place an LI element within a link as only LI elements
can be the children of lists.

No, the display-attribute doesn't affect this.

What do you mean, no?

[snip]

border-width: 1px;
border-color: red;
border-style:solid;

[snip]

Use the shorthand border property if you're setting multiple values:

border: 1px solid red;

[snip]

The problem is that now the background color is ignored and it's always
transparent!

That's because IE is a crap browser. No problems in Opera or Mozilla.

[snip]

Mike

 

[Karl Core]

Is there any reason for that rule?

Dumb meaningless rules are the main reason why it's so hard to code
compliant HTML pages.

It is a poor mechanic who blames his tools...

-Karl

 

[Robert Ferber]

Dylan Parry wrote:
[snip]

That's because <li> is a block level element, but <a> is inline. You
cannot put a block level element inside an inline element.

Is there any reason for that rule?

Structure, and plain common sense. HTML is a structural language.
Block-level elements can contain other block-level elements and inline
elements. Inline elements can only contain other inline elements. What's
objectionable about that?

Do you realize that you just rehearsed what the validator put out? Yes, I
know that there are block-level elements and inline elements. I asked for
the *REASON*. Obviously there is no reason.

It's objectionable, because there is no reason for it and doesn't solve any
problems.

The split into block-level and inline is completely arbitrary.

But it wouldn't be so frustrating if they would offer a block-level <a>
replacement. (It would still be braindead, but at least you could put it
around blocks)

Hard? Please.

Yes, I coded a couple of websites for standards, they validated, but now the
validator no longer accepts "&" in links and wants "&amp;" instead.

DIVs and list items are containers. An image is not. In fact, it's easy
enough to view an image as replacement for text, just in the same way that
text replaces an image if it can't be displayed. As text is inline, why
shouldn't an image be?

Moreover, you can't place an LI element within a link as only LI elements
can be the children of lists.

I know these rules very well. By repeating them, they don't make any more
sense than before.

A principle of elegant design is that you can replace *ANY* entity with a
container of entities.

Unfortunatly, this is impossible in HTML. :-(

That's because IE is a crap browser. No problems in Opera or Mozilla.

I don't even have IE on this machine.

Both Mozilla and Konqueror show the links as transparent.

Look at:
http://immo-netz.at/suchen/3

 

[Robert Ferber]

It is a poor mechanic who blames his tools...

Unless you post a way to solve the problem at hand in a standard-compliant
way, your ad-hom attack is really coming back to yourself.

 

[C A Upsdell]

Is there any reason for that rule?

Dumb meaningless rules are the main reason why it's so hard to code
compliant HTML pages.

You are completely free to become a W3C member and become involved in
establishing new and updated standards. The fee is $57,500 for a full
member, and $5,750 for an associate member. See
http://www.w3.org/Consortium/Prospectus/Joining for more information.

Until then you have to live in the real world: stop bitching, and get to
work.

 

[C A Upsdell]

Unless you post a way to solve the problem at hand in a standard-compliant
way, your ad-hom attack is really coming back to yourself.

I presume you mean "ad hominem". Do you also consider the English language
to also be "dumb meaningless rules"? If so, don't be surprised when your
attempts to use the language result in consequences you don't expect.

And, by the way, do you know what "ad hominem" means? For his statement "It
is a poor mechanic who blames his tools" is NOT an attack on you as a
person, suggesting that you DON'T know what it means.

 

[Michael Winter]

[snip]

Do you realize that you just rehearsed what the validator put out?

No. I didn't.

Yes, I know that there are block-level elements and inline elements. I
asked for the *REASON*. Obviously there is no reason.

And I gave you a link to the reason. The content model - containers and
contained elements - seems simple enough to me. Even so, what's the point
in complaining? You aren't going to change anything.

Live with it.

It's objectionable, because there is no reason for it and doesn't solve
any problems.

Yes, there is. It's the very point of HTML.

The split into block-level and inline is completely arbitrary.

In your view.

[snip]

Yes, I coded a couple of websites for standards, they validated, but now
the validator no longer accepts "&" in links and wants "&amp;" instead.

Because it's possible to confuse that for a character entity. Hardly
difficult to overcome, and a very bad example.

[snip]

I don't even have IE on this machine.

I assumed that browser as it's the only one I had a problem with.

Both Mozilla and Konqueror show the links as transparent.

I can't test with Konqueror at the moment, but Opera 7.54, Mozilla 1.0 ->
1.7.3 and Firefox 0.9.3, Netscape 7.2, and IE 6 all render this:

<URL:http://www.mlwinter.pwp.blueyonder.co.uk/ah/ferber/a-block.html>

as intended. Far more simplistic, I know, but it's probably the best way
to start. Take that and move it incrementally towards what you currently
have. You should find your problem much easier.

[snip]

Mike

 

[Neal]

Hi,

Stupid validator doesn't accept <li> inside of <a>.

Does anybody know a good way to make blocked links (= links that work in
the
whole block and not just on the text) in a standard compliant way?

Thanks a lot

P.S. <div> doesn't work inside of <a> either. :-(

You need to learn the difference between inline and block elements.

Block elements include div, ul, p, h1, and any other element which has a
"line-feed" before and after when rendered. (For the sake of argument, li
can be considered similar to block. But it's a little more complicated,
and never mind for now.)

Inline elements are like <em>, <code> and <img> - and indeed, <a>. These
do not break the line, they flow along with the content.

Now a cardinal rule of markup is that inline elements cannot contain
anything but other inline elements. Clearly, inline elements are meant to
be in the flow, and adding a <div> or a <li> within will break the flow,
so it's obviously illogical.

The proper way to make a list of links is to put <a> inside <li>. Ruke of
thumb - inline always inside block, never outside.

 

[Karl Core]

Unless you post a way to solve the problem at hand in a standard-compliant
way, your ad-hom attack is really coming back to yourself.

Lookin to make a lot of friends around here, are ya?

-Krl

 

[Andy Dingley]

Dumb meaningless rules are the main reason why it's so hard to code
compliant HTML pages.

Dumb meaningless student receives crack around ears from white-bearded
master.


So, Grasshopper, learn the ancient art of the DTD and the secrets of
the web will be open unto you. Read the sacred texts of the W3C, for
in there is much knowledge to be found.

Never use the phrase "stupid validator" again, lest it be that the
validator is both more valid and less stupid than you. There are six
great masters I know who I would listen to when they told me that the
validator is wrong - you are not among them.

 

[Toby Inkster]

Is there any reason for that rule?

Because you can't just let people put elements wherever the hell they
want. Otherwise you'd end up with things like:

<a href="foo"><div><a href="bar">Where do you want to go
today?</a></div></a>

There have to be well defined rules about what nesting is allowed and what
isn't.

<a> can contain a picture, which is a rectangle, I don't see any reason why
it shouldn't contain a <div> or <li> which is (or can be) just another
rectangle.

It's not the shape that's the problem. It's the fact that a <div> in its
normal presentation causes a line break before and after it. This disturbs
the normal flow of text.

A square with a opaque background and a border that can be clicked (as a
link) anywhere, not just on the text inside.

Like the squares here?
http://examples.tobyinkster.co.uk/css-rollovers

This *almost* works and validates:

a.m1
{
background: #fff;
}
a:hover
{
background-color: yellow;
}

The problem is that now the background color is ignored and it's always
transparent!

That's because a.m1 is more specific than a:hover. Try replacing a:hover
with a.m1:hover (more specific).

 

[Toby Inkster]

I presume you mean "ad hominem". Do you also consider the English language
to also be "dumb meaningless rules"?

<nitpick>Ad hominem isn't English -- it's Latin.</nitpick>

 

[C A Upsdell]

<nitpick>Ad hominem isn't English -- it's Latin.</nitpick>

Certe, sed hoc intelligatne?

 

[Toby Inkster]

Certe, sed hoc intelligatne?

Lingua Britannorum dic ne populus crederet hostes essêmus.

 

[Robert Ferber]

I can't test with Konqueror at the moment, but Opera 7.54, Mozilla 1.0 ->
1.7.3 and Firefox 0.9.3, Netscape 7.2, and IE 6 all render this:

<URL:http://www.mlwinter.pwp.blueyonder.co.uk/ah/ferber/a-block.html>

as intended. Far more simplistic, I know, but it's probably the best way
to start. Take that and move it incrementally towards what you currently
have. You should find your problem much easier.

Thanks a lot, as it turns out, the problem was a "a" directive in my css
that had background:transparent in it.

BTW, it also works without an enclosing "div".

 

[Robert Ferber]

Because you can't just let people put elements wherever the hell they
want. Otherwise you'd end up with things like:

<a href="foo"><div><a href="bar">Where do you want to go
today?</a></div></a>

That would make perfect sense: If you click the box (the div), you go to
"foo", if you click the text, you go to "bar".

There have to be well defined rules about what nesting is allowed and what
isn't.
Sure.


It's not the shape that's the problem. It's the fact that a <div> in its
normal presentation causes a line break before and after it. This disturbs
the normal flow of text.

OK, a div disturbs the flow of text - but IMO that's no reason to forbid an

Like the squares here?
http://examples.tobyinkster.co.uk/css-rollovers

Yes, thank you.

 

[Michael Winter]

Michael Winter wrote:
[snip]

[snip]

BTW, it also works without an enclosing "div".

If you're referring to the DIV in my mark-up, I know but the mark-up would
be invalid without some kind of block element containing the A. A DIV
sufficed.

Mike