Is this placement of <a> and <ul> legal?

**StevenHu** · Jan 27, 2012 10:04

I was trying to get an entire <li> row to be clickable rather than just the text inside it. So I put the <a> tags on either side of the <ul> tags and it works. My question is: is this correct usage, or am I heading into trouble later? Here's the complete test HTML:

HTML Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
h2, p{
font-family:Arial, Helvetica, sans-serif;
}
.outer {
	margin:0;padding:0;
	position:relative;
	display:table;
	height: 100px;
	width: 200px;
	vertical-align: middle; 
	text-align: left;
	border: 1px solid #000;
	background:#bbb;
	clear: both;
}
.inner {
	margin:0;padding:0;
	display:table-cell;
	vertical-align:middle;
	position:relative;
	border: 1px solid #ff0000;
	padding-left: .6em;
}
.inner a {
	color:blue;
	text-decoration:none;
}

</style>
</head>
<body>
<h2>Vertical alignment of elements of different heights</h2>
<p>Putting the < a > tags around the < ul > tags allows the whole < li > row to be clickable instead of just the < p > text.</p>
<a href="#" alt=""><ul class="outer"> 
  <li class="inner">
    <p>This is some random text</p>
  </li></ul></a>
<a href="#" alt=""><ul class="outer">   
  <li class="inner">
    <p>This is some random text<br>This is some random text</p>
  </li></ul></a>
  <a href="#" alt=""><ul class="outer"> 
  <li class="inner">
    <p>This is some random text<br>This is some random text<br>This is some random text</p>
  </li></ul></a>
</body>
</html>

**Return True** · Jan 27, 2012 11:56

Hi.

I suggest using http://validator.w3.org/ to test the validity of your codes.

Good luck.

**StevenHu** · Jan 27, 2012 12:46

Thanks! No errors!

This issue is resolved.

**dresden_phoenix** · Jan 27, 2012 15:30

OK...

#1) Why do you have only one LI inside UL? , even if what you were doing were valid all list items would go to the same link? SO I assume you mean putting the A around the LI, that would be more sensible.

#2) That is only valid in HTML 5, so you would need to change your doctype and do a few other cross-browser preps

#3) For what you have, you could simply omit the P tags replace them with the A tags OR replace the P tags with SPANs and wrap an A around all the spans and set the SPANs and the A to to display:block;

**Stevie D** · Jan 27, 2012 17:05

A few thoughts ...

As dresden_phoenix says, that is only valid in (X)HTML5. In earlier versions, <a> can only contain text and inline elements, not block elements like <ul> and <li>.

And creating a separate list for each bullet point just so that you can wrap <a> tags around the list is a horrible, horrible way of doing it, and completely negates the point of having a list there in the first place.

What are you putting alt="" attributes on an <a> tag for? They can only be used on <img> – they designate alternative text to be used when the image can't be displayed. Having them here makes no sense.

There is a very easy way to achieve the goal of making the entire width of the line into a clickable area, that is valid in HTML4 and XHTML1.

HTML Code:

<ul class="outer">
<li><a href="#">Some text</a></li>
<li><a href="#">More text</a></li>
<li><a href="#">Lots and lots of text</a></li>
</ul>

Code CSS:

ul.outer a {display:block;}

You don't need to put a class on the <li>s either, much easier just to put their styles in ul.outer li {...}. And there's no need for <p> for such short text – if you want to increase the spacing between bullets then you can do that with margins and padding on the <li>.

**Stevie D** · Jan 28, 2012 16:11

Originally Posted by StevenHu

Thanks! No errors!

This issue is resolved.

Using the code you gave in #1, I get 7 errors and 5 warnings.
Because of: nesting <ul> inside <li>, using < instead of <, illegal use of alt attribute, using <br> instead of <br />.

**markbrown4** · Jan 28, 2012 21:12

It's worth noting that while anchors around block level elements wasn't valid before HTML5 it still works in every browser so the validity means nothing really.

There's also no reason to go around changing doctypes other than validation.

**Meldin** · Jan 28, 2012 21:31

Originally Posted by markbrown4

It's worth noting that while anchors around block level elements wasn't valid before HTML5 it still works in every browser so the validity means nothing really.

There's also no reason to go around changing doctypes other than validation.

I disagree. If it passes the validator then it is legal. If it doesn't then it isn't. If the html is valid then we can argue ad infinitum on whether it is proper semantics or not and that is a different issue alltogether.

So validation does mean something.

Sure, code might work in some browsers even if it fails the validator, but to me, publsihing pages with invalid code reflects poorly on the ability of the author of the page. Think of it this way. Just about anyone can build a house and all will probably provide shelter initially, but the poorly built houses will start leaking, falling apart etc much, much sooner than a well built house

I sometimes go around my competitors' websites and check the validity of the html in at least their home pages. If it is invalid I send them a message through their contact page to tell them their pages are invalid and that they have lost me as a potential customer. If their page is fixed after a few days I highlight their invalid website on my website and recommend people to avoid the site with invalid code.

**markbrown4** · Jan 29, 2012 00:28

Originally Posted by Meldin

I disagree. If it passes the validator then it is legal. If it doesn't then it isn't.

I'm not sure that would hold up in a court of law.

I sometimes go around my competitors' websites and check the validity of the html in at least their home pages. If it is invalid I send them a message through their contact page to tell them their pages are invalid and that they have lost me as a potential customer. If their page is fixed after a few days I highlight their invalid website on my website and recommend people to avoid the site with invalid code.

I'd suggest you quit doing that, it's a waste of time and effort and has no positive side to it at all.

I build websites for real people, not validators or browsers.
The "validation error" in this case worked in every browser, was very useful, so it became a standard in HTML5.
Having a doctype other than HTML5 has no impact what so ever on the output page, it simply doesn't matter.
I'm not promoting invalid code, only promoting looking at validation reasonably.

I could have suggested dropping the unnecessary closing </li> tags as well but your brain may have melted at the prospect

Code html5:

<ul class="outer">
  <li><a href="#">Some text</a>
  <li><a href="#">More text</a>
  <li><a href="#">Lots and lots of text</a>
</ul>

**Meldin** · Jan 29, 2012 02:11

Originally Posted by markbrown4

I'd suggest you quit doing that, it's a waste of time and effort and has no positive side to it at all.

You can suggest all you like but I'm not going to stop on the say-so of someone in a forum

.

The positive aspect of highlighting other peoples' invalid code can only increase the possibility of someone asking at least me to give them a quote for their website, especially as my website validates with a Strict doctype. It certainly can't do me any harm

.

**Paul O'B** · Jan 29, 2012 03:31

Originally Posted by markbrown4

It's worth noting that while anchors around block level elements wasn't valid before HTML5 it still works in every browser

I'm sorry to disagree with you Mark but browsers hate inline elements wrapped around block level elements and I'm seeing more and more errors in the forums now especially as everyone is doing this in html5. IE hates it and will misplace or even hide the element altogether in complicated situations and indeed Mozilla will occasionally hiccough on this. It has happened so often in html 5 layouts that I advise not to use this structure. If you do warp the anchor around the block level element then at least set the anchor to display:block and although this makes it more reliable it does not cure the bug completely.

What's worse is that the behaviour is erratic and sometimes it works and sometimes it doesn't making a bug that should just be avoided in the first place.

I don't know what they were thinking when they made this possible in html5 and obviously didn't test how browsers handle it.

You are right that validation for the sake of validation is a waste of time especially as vendor pre fixes are so widely used these days. Validation is a tool to find errors in the code and fix them and not a badge to be worn .

**Meldin** · Jan 29, 2012 03:49

Originally Posted by Paul O'B

Validation is a tool to find errors in the code and fix them and not a badge to be worn .

It depends on how you wear it. I use it and highlighting other peoples' invalid code as a marketing tool. For me there is only potential upside and no downside at all. It doesn't guarantee more work but it certainly does no harm either.

**Victorinox** · Jan 29, 2012 07:35

Originally Posted by Meldin

The positive aspect of highlighting other peoples' invalid code can only increase the possibility of someone asking at least me to give them a quote for their website, especially as my website validates with a Strict doctype. It certainly can't do me any harm

.

On the contrary, it raises the risk of you being perceived as a priggish busybody. Clients warm to positivity.

**Stomme poes** · Jan 29, 2012 13:32

Clients warm to positivity.

Nah, clients warm to the idea that they can have annoying auto-playing videos and stupid stockfoto carousels and 9px-light-grey-on-white-text and drop-shadows-on-rounded-corners because today that makes everyone's MonsterTemplate site look "modern". Positivity to them means you say "yes" when they ask for this crap.

Since clients have no idea that invalid code on websites isn't anything like an error caught by the C compiler causing the space shuttle to crash in a fiery blaze with 15 gorgeous supermodel astro-nettes on board, caught on several wavering iWhatevers on a nearby tropical tourist-haven island as it splashes magnificently into the sea killing the last of the endagered purple sea walruses and displayed on the local Fox Snooze channel so everyone can cry and come together in a time of (inter)national crisis and shared sorrow blah blah... telling them "the other guy has illegal code" might well convince them that YOU will be the caped developer who can stop their company's downward spiral into bankruptcy and shame requiring face-saving seppuku and manage to convince the world that YES, they DO need Yet Another Social Twitter Picture Sharing Service (for only 5.99 plus tax)!

You're right tho, it's kind of an underhanded tactic, and it can very easily bite you in the butt when the client, a few months later, runs those validator tests themselves and discover either a) all the Big Names Who Are Successful Competitors But With More Drop Shadows And Useless Gradients are riddled with errors and still manage to make money (even if they are kicking the blind and mouseless in the face and going "nya nya why dontcha try a lawsuit blinko!" or b) their own site has "errors" (or were you going to spend more time edumacatin' the client about the difference between real errors like li's outside a ul and fake errors caused by -moz and -webkit CSS3 crap?). Or both.

Or c) ninjas.

**Victorinox** · Jan 29, 2012 14:04

Very amusing post, but "endagered" is invalid spelling so I'll be boycotting you forthwith.

**Meldin** · Jan 29, 2012 15:40

Originally Posted by Victorinox

On the contrary, it raises the risk of you being perceived as a priggish busybody. Clients warm to positivity.

I suppose that depends on how it's done. From the feedback I have got, I seem to be doing it in a positive way

It's just an advertising/marketing technique that I saw on someone else's website and so I decided to copy it.

**markbrown4** · Jan 29, 2012 22:16

Originally Posted by Paul O'B

I'm sorry to disagree with you Mark..

I wouldn't have it any other way

I assumed it was safe because of how HTML5 was designed(where possible) to be backwards-compatible.
I hadn't actually used links around block-level elements myself, or tested support in browsers, which showed in my response

I don't know what they were thinking when they made this possible in html5 and obviously didn't test how browsers handle it.

Being able to link any type of element makes sense to me, which is why this question comes up often. Not everything you want to be able to do will be able to be backward compatible.

**Stomme poes** · Jan 30, 2012 05:18

I assumed it was safe because of how HTML5 was designed(where possible) to be backwards-compatible.

Well, like <meta charset="blah">, many people have been incorrectly wrapping anchors around block elements forever, and browsers have been using error rendering to parse that and Do Something with it all this time... which is probably why the WHATWG thought the anchors-wrapping could work. When they want to be backwards compatible, that generally means "browsers' parsers have been dealing with this in some form already" and for a lot of things, that works. Just not this one, though I'm sure IE Team is working on it. Mozilla, I have no idea, I thought this was one of those decade-old bugs everyone's been calling "features" which means it'll never get fixed because after all, it's not a problem *whistles*

**deathshadow60** · Jan 31, 2012 14:34

Originally Posted by markbrown4

I assumed it was safe because of how HTML5 was designed(where possible) ~~to be backwards-compatible.~~ to throw coding practices back a decade

There, fixed! This is another stellar example of loosening the structural rules to the point that validating HTML 5 is effectively MEANINGLESS -- and just another of the reasons I can't believe ANYONE is DUMB ENOUGH to embrace the user of HTML 5 for ANYTHING!!!

My question would be... what makes those LI... if they're LI why do they need P inside them? What makes the text P? If it's all one anchor, what makes it go inside a list?

But again without meaningful content to dictate the markup, it's difficult to weigh in on the proper code for what's being attempted - treads into the flawed site-building methodology of doing the layout before you have meaningful content with semantic markup.

**lyndah** · Feb 1, 2012 15:02

Originally Posted by deathshadow60

- treads into the flawed site-building methodology of doing the layout before you have meaningful content with semantic markup.

If by layout you mean having a mockup of the page then I disagree. You normally wouldn't start building a house without a set of architect's plans and so I would never start building a web page without knowing what the desired result (layout) is. But I agree the markup should be semantic and pass the W3C Validator with a Strict doctype. Like you, I also don't see the point of using HTML5 atm since it is a long way off being finished and so currently has numerous pitfalls.

**deathshadow60** · Feb 1, 2012 15:38

Originally Posted by lyndah

If by layout you mean having a mockup of the page then I disagree. You normally wouldn't start building a house without a set of architect's plans and so I would never start building a web page without knowing what the desired result (layout) is.

Problem with that thinking is that most of the time you aren't getting architects plans -- you're getting a oil painting of a house by someone who's never learned architecture. It looks like a house, doesn't meant it will actually stand upright.

Even if working from a PSD when writing the HTML you should pretend it doesn't even exist, and if you hit up against limitations of the medium you need to be ready to pitch that pretty painting in the trash. To be brutally frank I consider the entire current approach being taught/advocated in the industry of sleazing out a picture in photoshop, working up a template and then shoe-horning the content into it to be the leading cause of broken layouts... and as a large font/120dpi user and a netbook users, all these fancy fixed width often with fixed height element garbage sites you see vomited up for small businesses and cruddy little personal websites are exactly that -- BROKEN, inaccessible rubbish. It's putting the cart before the horse.

Semantic markup of the content (or a reasonable facsimile of your content) first, bend that markup to your will to make the layout with CSS... then and only then do you start up the goofy paint program to hang graphics on it. The result may not be as artistically pleasing, but its' a HELL of a lot more useful.

Because at the end of the day, people do NOT visit websites for the goofy graphics you hang on the content, they visit FOR the content... so putting the content as the first priority usually means a more successful site instead of the megabyte-plus sized monstrosities people are vomiting up and calling websites of late. Having worked in art/print before doing websites that was a hard pill to swallow -- but my code and practicality of design benefited from taking all the artsy preconceptions and throwing them out the window.

Which is why the majority of successful websites aren't exactly a graphical tour-de-force. eBay, Amazon, Google, Slashdot, the majority of forum skins... Just enough graphics to be pretty, not so much it gets in the way and certainly not wasting time vomiting up a PSD.

It's also why I often refer to some things people try to do in HTML/CSS as "But I can do it in photoshop" idiocy. The web is not a static width delivery system, a desktop resolution screen is not/should not be your only target device, the web is not print... With the entire purpose/point of HTML being to deliver content to an endless combination of widths, heights, fonts, and device capabilities -- ranging from teletype to print, from braile to screen reader -- drawing a pretty picture for just one target (or even multiple targets) before you have semantic markup is just idiotic at best, completely crippling one's ability to use HTML for what it's actually FOR.

NOT that the majority of people sleazing out HTML 3.2 and slapping a 4 tranny or 5 lip service on it have any clue what the point/purpose of HTML is, and just keep their heads firmly wedged up 1998's backside. Concepts like multiple media targets, separation of presentation from content, caching models going Pow-zoom-phwee right over their heads.

Part of my increasing disgust with the industry as a whole, part of why I'm visiting less and less websites as they are increasingly USELESS to me as a user, and part of why I can't believe ANYONE is DUMB ENOUGH to be drinking the HTML 5 kool aid.

Don't care how pretty the picture is, if the end result is bloated, slow and inaccessible, what in blazes good is it? Unless of course you're "polishing a turd" by hanging pretty graphics on something without actual content of value -- in which case it's just a drain on everyone's resources.

**lyndah** · Feb 1, 2012 15:54

Originally Posted by deathshadow60

Problem with that thinking is that most of the time you aren't getting architects plans -- you're getting a oil painting of a house by someone who's never learned architecture. It looks like a house, doesn't meant it will actually stand upright.

Sure, but the person giving me the mockup will not be doing the markup just like the architect will not necessarily be building the house. The builder will build the house and I will build the markup. If the person who made the mockup attempts to do the markup as well, then yes, it will probably be a mess just like if the architect builds the house then the house will probably fall over at the first hint of a breeze. But I can still create semantically correct and valid markup from a mockup (psd, hand drawn sketch etc etc). I just find it easier to create the markup if I know what the end product needs to look like.

**dresden_phoenix** · Feb 1, 2012 16:02

Really the pretty painting is usually the request of a the client. Even people who don't know how to work PS (at all) are not learning to do flexible shells for web designs.. they want as a recent forum post to be "able to to fix the text given as per client request". In order words, you do this o r you don't eat. Ignorance is trickling UPHILL.

My question would be... what makes those LI... if they're LI why do they need P inside them? What makes the text P? If it's all one anchor, what makes it go inside a list?

Exactly, This was my original response.

Semantic markup of the content (or a reasonable facsimile of your content) first, bend that markup to your will to make the layout with CSS... then and only then do you start up the goofy paint program to hang graphics on it. The result may not be as artistically pleasing, but its' a HELL of a lot more useful.

If given the semantic INTENT, a good Art director can cast a flexible and appealing template/interface, even before the actual content is placed. We forget what CSS is for STYLING. If this is considered during the creation of the graphics to support the CSS this is actually quite easy to accomplish and with only minor compromises at most. Again the problem starts with the facts that many clients only understand linking/not liking an oil painting.

As we concurred before, we don't know the actual semantic intent of the OP. Is he trying to save tags ( as code economy is also twisted into a buzzword by some) because he sees that all links lead to the same URL? Is this beacuse of a poor background graphic/interface design? Is it bad copy and information architecture? Maybe each line is being pulled from a DB... as a LIST of data.. but marketing has decided they all point to the same point of purchase. PSDs are not the only thing that ruin semantics.

**Stomme poes** · Feb 1, 2012 16:33

Originally Posted by lyndah

You normally wouldn't start building a house without a set of architect's plans and so I would never start building a web page without knowing what the desired result (layout) is.

So I hope you're at least asking for multiple layouts for all those resolutions people have, right? A 320px version, a 480px version, a 600-780px version, a widescreen version and maybe even a TV version?

If I have the content and know what's considered important by the client for the users, I can mark that shizzle up regardless if the user is viewing on a crappy sleaze1000 connection with Opera as a proxzy browser to save bandwidth, or sitting at a conference using a netbook, or relaxing at home behind a desktop, or being silly and using the Nintendo Wii-mote to move the silly onscreen cursor with great care and little precision to that link or button (yeah a friend of ours watches YouTube videos on his Wii cause the TV's obscenely big).

I may not CSS it without seeing a layout, and I may end up adding some sandbags or whatever to the markup when I know which UAs I'm expected to support... but the importance of the content and what users MUST be able to do, versus what would be nice for them to do... Lorum Ipsum and a PSD at 1200 pixels wide can't tell us that. That's why I say it's secondary.

But as Dresden said, clients are the ones who usually require that (a pretty layout), and yes it seems more web developers start with a PSD. But that's them. They're working harder now that "responsive" has become the trendy new buzzword. Or, the graphic designers they're working with are.