Which is more semantic/less horrible?

HTML & CSS
1

Theoretical question, but it driving me nuts. lets say you found yourself in a spot where you cant avoid the need a couple of extra tags to hook css to… and that you figure you can do the effect with either of two markup patterns:

<div class="wrapper_out">
     <div class="wrapper_inner">
              <div class='content> the content, obviously.. bay contain more block elements or nested divs</div>
     </div>
</div>

OR

 <div class='content>
                  <div class="empty_tag_top"></div>
 the content, obviously.. bay contain more block elements or nested divs
                  <div class="empty_tag_bottom"></div>
              </div>

Which one of the two is the best practice? I would love to get the forum expert’s opinion on this…

2

I’d go with this:

<div class="content">
  <span class="empty_tag_top"></span>
  content here
  <span class="empty_tag_bottom"></span>
</div>

to avoid too many nested items

3

Hi Ray,

Interesting question :slight_smile:

I would guess that the purists would say that the empty elements were the least semantic choice and indeed some older browsers used to ignore empty elements (and I still believe that empty p elements are supposed to be ignored).

However, in practice it is often easier to manage when you have less nestings and I would prefer the non nested method.

Also assuming that the extra elements are only for decoration I would argue that an empty element is more semantic than a nested element because it adds no structure to the page unlike a nested element which is implying that it’s part of a structure.

Interesting question though :slight_smile:

4

I prefer to nest elements than to have empty elements. One, I think it’s neater - two, you don’t need to name everything.

<div class="wrapper_out">
     <div>
              <div> the content, obviously.. bay contain more block elements or nested divs</div>
     </div>
</div>

should be perfectly sufficient.

5

You don’t need to name everything with the other pattern either.

6

…but I’d use ::before and ::after instead of divs. :slight_smile:

7

first one looks more fine for me

8

Yes I was assuming old browsers needed to be supported :slight_smile: (Otherwise we could have used multiple backgrounds also :wink: )

9

That’s not really semantically correct unless you are going to have no more block elements inside that structure -which seems unlikely.

If you do for example have a content div inside then you end up with an inline element butting up to a block level element such as the div and while its valid code it’s not very nice and indeed in some cases will throw IE into a fit as it tries to construct the anonymous block box around it and then gets tripped up by the whitespace on the inline element.

Change the span to a div and then you are ok :slight_smile:

As an aside we must get about a question a month in the forums where this bug crops up and indeed in html5 (take note Simon ;)) this happens frequently now that authors are wrapping anchors around divs. I’ve seen half a dozen occasions recently where this has tripped IE up even when using css to set the a element to a block display.

10

Although it’s probably more efficient to use a shim that simulates ::before and ::after than which replaces multiple backgrounds.

11

It’s weird how things turn around. I skipped the whole tables-for-layout age of the web; when I finally got into online design, about 3 years ago, I would opt for adding empty div/spans for ornamental elements ( unless the content had to go above, and even sometimes I’d chose just to use a negative margin to sop some of that space…) . it just made sense, if your design changed, you could always go back and remove empty elements , knowing they were there for presentation only.

The last week, I came across an “old” post where a couple of SP regulars, were denouncing the use of wraps with classes in favour of semantically neutral empty elements. I have been wanting to return to that practice… but wasn’t sure if it wouldnt be considered “best practice”

Oh, and sure :bef and :aft is the clean way to go … but I still try to support IE. :confused:

PAUL, you said:

If you do for example have a content div inside then you end up with an inline element butting up to a block level element such as the div and while its valid code it’s not very nice and indeed in some cases will throw IE into a fit as it tries to construct the anonymous block box around it and then gets tripped up by the whitespace on the inline element.

this raises another tangent question.

I have seen the following structure commonly used for drop down menus whose headers also link to pages…


<ul>
    <li>...</li>
    <li>...</li>
      <li><a href="#">link</a>
             <ul>
                        <li><a href="#">link</a>
                        <li><a href="#">link</a>
                        <li><a href="#">link</a>
               </ul>
       </li>
                        <li>....</a>
</ul>

is that the exception to the rule or does the link need to be wrapped in a block element too ?

12

I don’t like that either but fortunately it doesn’t trigger the IE bug because the ul that follows the anchor is absolutely placed and therefore not part of the flow and IE seems to handle that ok (because as far as its concerned there is just an anchor inside that structure).

However, as that lonely anchor is actually a heading that leads to a further menu then perhaps it should be wrapped in the appropriate heading tag or at least something that identifies it more structurally as it is not just a link like all the others.

13

That would have been my guess too, except that in most cases the navigation comes before the content in the source code… so it would be having an Hx before the H1… h2…h3? Alternatively, I would have chosen <strong> but… that’s still an inline… so it would not address the original issue, I think.

14

I’m with Paul and others. I as well like to just use the empty tags. I prefer to have one rightly named wrap.

15

Would it help if the validator warned about blocks in <a>? What should the warning say? What’s the issue in IE?

16

It seems similar (and may be related) to the usual erroneous IE haslayout errors (which still exist to some extent in ie8) and you get missing or misplaced content or at the least a white space gap after the inline element. It’s one of those things that only seems to happen in complicated layouts and therefore not easily reproducible in cut down form.

I do remember that the last time I saw the bug that neither haslayout nor display:block seemed to cure it but I do need to research this a bit more as I tend to say fix it by changing the html rather than looking for a css fix.

The next time I see the bug crop up I’ll make a note of it and save it for more testing:) It may indeed only be a problem in IE6 and 7 so its going to be less of a problem as time goes by.