When a User posts a Comment, in the left margin will be the following information…
<username>
<picture>
<join date>
<location>
<# of posts>
What would be the best way to markup each of the fields above?
These seem like options…
1.) Wrap each field in a <p>
2.) Wrap each field in a <div>
3.) Wrap all fields in a <p> and use <br /> for spacing
4.) Wrap all fields in a <div> and use <br /> for spacing
5.) Wrap each field in a <span>
**The list of fields above could change, but this is pretty close to my final design.
Also, remember when using strict doctype you must get the alt attribute in your <img>
Since you brought it up - and I have forgotten the correct answer - what is the proper way to do my ALT and TITLE tags?
Because I usually use images from WikiMedia Commons, I need to attribute the image to the Author, but I’m not crazy about having to put text next to Images/Icons because it just isn’t practical - especially in this example.
That said, I think using the ALT and TITLE is fair enough.
Any suggestions you could make would be appreciated, however.
I suppose the “Oniline Status Indicator” could go in a <span> ?
It could probably just be an <img> with a class applied to it for online status. That way it would run inline with the username anchor.
Can an Image stand on its own?
Yes it can in that context, since it’s siblings are all inline elements. There was good explanations about how to handle inline elements that in your recent Wrap Anchor thread.
Since you brought it up - and I have forgotten the correct answer - what is the proper way to do my ALT and TITLE tags?
It’s perfectly valid and semantic to put photos ( and links) just as any other data inside DTs OR DDs
The real semantic issue here is what constitutes a TERM in a DL, and not confusing it with a “label” (and no I don’t mean LABEL tag , I mean the semantic function… LABEL).
I would argue that “total posts” , “date joined”, “names” are labels, semantically and that a the definition list is actually defining the user ( as opposed to LOCATION, POSTS, ETC) and furthermore giving DT to each actually dilutes the semantic and bloats your code.
I suggest this:
<h3>User info</h3>
<dl class="userInfo">
<dt class="name"><a href="#" >DoubleDee</a></dt>
<dd class="photo"><img src="/images/Light_Green_10.png" width="10" alt="Green Light." title="Credit: 1RadicalOne, Wikimedia Commons." /></dd>
<dd class="photo"><img src="/images/Light_Green_10.png" width="10" alt="Green Light." title="Credit: 1RadicalOne, Wikimedia Commons." /></dd>
<dd>Joined:<em>10/10/10</em></dd><!-- OR perfect oportnutiy for date (instead of em) tag in HTML5-->
<dd>Location:<em>Benzon, AZ</em></dd>
<dd>Post:<em>114</em></dd>
</dl>
Far cleaner, both in code and semantics. Which segways perfectly into your question about alt and title.
WHAT ARE THE IMAGES? that’s what goes in the ALT tag. TITLE is completely up to you… think of it as a “tool tip”
So if the image is a pic of you an ALT could be “DD at the Grand Canyon”… but if its just an “online indicator” the ALT should be “Currently online” ( as “green light” means NOTHTING in the context of a user being online)
Not only that, but when a screen-reader gets a hold of the <em> it says “Post: 114”, giving unnecessary emphasis on the post count.
it was just a suggestion. And it itself was based on the fact that in order to have good semantics in HTML you must have a defined direction as to what you are trying to say. ( that’s what I meant about “labels” and DATA.
In a sense what we have here is a ONE column(one user) tabular data set. so I made the assumption that “post” is more meta and the actually data ( where I would want the emphasis to be) would be on “114”
in response to the latest post.
DT is an IN-LINE ELEMENT by default. Also when you float an element it SHRINK WRAPS to the SIZE OF ITS CONTENTS. So when you applied text-align it was aligning to the right, you just couldn’t see it because the box was the same size as the text. I you commit to a width for the DT , you will see what I mean.
#boxComments dt{
float: left;
text-align: right;
width:4.5em; /* leaving a .5em 'gutter' from the 5em left-margin in the DD rule*/
}
#boxComments dd{
margin: 0 0 0 5em;
text-align: left;
}
I think it’s time for me to mention one of my sayings… It’s better to use no markup, than the wrong markup. Honestly, at MOST I’d probably use spans IF I actually needed some sort of styling hook… there is NO reason to be throwing extra block level containers around each of those to do BR’s job.
P? What makes it a paragraph? DIV? Why does it need a block level container? DL? That’s a pretty BROAD definition of a term and … definition.
Though I ASSUME you mean a left column, NOT a left ‘margin’… since unless your scribbling editorial comments on paper generally content doesn’t go into margins.
It becomes TOO easy when dealing with semantics to go overboard and start thinking you HAVE to wrap EVERY little bit of data in it’s own container; frankly on most flow content that’s nothing more than a waste of bandwidth, time and effort coding. This is particularly true of the STUPID things people WASTE TIME wrapping DL around these days.
Especially when the real laugh most of the time of people using DL’s is that a table would be more semantically correct. (though I’d not do that in this case).
Well lets’ see, we put aside the pointlessly redundant comments (since you’ve got div with perfectly good descriptive classes), the use of string addition instead of delimits on the echo, multiple echo for no reason, extra variable for nothing, procedural mysqli just to make it slower, img tag for what I’d probably have in the CSS with the ‘online’ status, putting tags into attributes where tags are invalid, wasting bandwidth using htmlentities instead of htmlspecialchars, paragraph around a non-paragraph element, strong on an element that probably doesn’t/shouldn’t need emphasis, title attribute on a IMG tag (which is most always pointless)…
Is probably how I’d approach that… Well, I’d probably have some code in there to try and detect <br><br> and turn them into </p><p> (regex most likely) – though that’s the type of conversion I’d probably do before storing it in mysql, that way you only need it once (twice if you allow edits) instead of wasting time doing it every time the page is displayed.
