DIVs as "building blocks"

[Rayzur]

You're wrong. Let's look at h2:
The global structure of an HTML document

which translates to "headings have mandatory opening and closing tags, with possibly repeating %inline content".

That makes it more than OK to use the image and span inside it.

Yes, let's look on down a little further too...

A heading element briefly describes the topic of the section it introduces.

So with this h2 that we have been using in the examples,

Apple's Lala purchase appears to have been "insurance"

we have a brief description of the topic.

Now let's look at how the <small> element (a font property used to render text in a "small" font) should actually play a roll when being used in a heading.

First let's look back at Jason's reasoning in post#62 where he says this:

It's really no different than doing "h1 small" which is fairly common practice. It's part of the heading, so put it in the heading tag. It does not have the same emphasis as the title itself, so de-emphasize it with small.

I agree, it is fairly common and I have done it several times myself. Every time I have ever used it though my main heading text is able to flow through with the small element and still make sense while maintaining a brief description of the topic. The heading text should be able to maintain it's meaning with or without the <small> element in place. I use it a lot of times to drop down to another line and de-emphasize.

Actually I just did that on the example I gave in post#64

<h1>
    Article Summaries: Version II <br><small>Fluid Width &amp; Single Paragraph</small>
</h1>

You can read through that without the small tag in place and it still represents topic text.

The problem I have is when you start trying to call the byline part of the heading by wrapping it in the small tags which gives us this:

<h2>
    Apple's Lala purchase appears to have been "insurance" <small><b>1 day ago - by Lisa Smith</b> | Posted in: Mac Central</small>
</h2>

That should be able to make sense reading it as one line without the small tag or an image separating it. It doesn't, that byline is not part of the heading. It is information that is subsequent to the heading and it has no business in the h2.

All wrong. Except the part of losing the wrapping divs for each h2 subpart, which is the thing I suggested in post #12

Glad you brought that back up, it just so happens that the h2 link you gave goes into details on that too.

The following example shows how to use the DIV element to associate a heading with the document section that follows it. Doing so allows you to define a style for the section (color the background, set the font, etc.) with style sheets.

They give examples showing how the headers are the first elements in each section and subsection. Ironically that's exactly how I had been setting up all of my examples.

[noonnope]

There are two different issues here.



********************************************************************

1.a) What can go inside a heading.
---------------------------------------

Well, anything %inline. Which makes your argument, "A heading element briefly describes the topic of the section it introduces." the same as the eternal question: does size matter? Yes, it matters, but we all look differently at it!

"briefly" doesn't say: "one word", "three words", "no more than two phrases". "briefly" as in "whatever it takes to make a succinct presentation".

The def for h2: (%inline)* content, mandates the use of ANY and ALL repeated %inline: a, img, span, small etcetera . You're more like Steve Jobs, limiting, and I'm more like an unhappy restricted user, jailbreaking the device.


1.b) How is a heading relating to the section that follows.
----------------------------------------------------------------

If the heading it introduces the section that follows, that means, in my book, I don't need to use a div to make it a section, h2 is doing that for the content that follows after it, until another heading occurs, or an element that starts it's own section occurs, or the end of the document occurs.




********************************************************************

2. Are those constructs really sections or list items?
---------------------------------------------------------

I say list items.

They are only links, short descriptions of the actual sections. Saying that brief descriptions for the actual sections are also sections is a bit of a stretch.

You can argue that they are sections, and I can argue against, in the same way you're saying: "not all repetitive constructs are lists".

But I say "yes, this here is not a section of sections, it's a list of sophisticated links to sections across the web page or web site."

Being a list, <li> could probably accommodate any construct, but since these are descriptions, having two separate parts: a title, and a description of it, I say definition lists are appropriate.

And for that, you also need to think: you're Steve Jobs limiting, I'm the unhappy user jailbreaking.

Because, as <ul>/<ol> aren't restricted in meaning for you, and you can use them for menus, but also for more complicated constructs like recipes, where each <li> element, describing phases and/or ingredients, can consist from text, image etcetera, so should <dl>.

"Broadening" the meaning for <dl> in this case, is merely accepting the definitions for <dt> and <dd>, and the semantic of <dl>: a term, which can be a complex construct, as I've pointed out, and its explanation.

Arguing about "term" it seems to be the problem, and I've give clear and logic examples that anything can be a term, making dl fit in more cases than you are willing to accept:

dl

dt: "Call the dogs and piss on the fire."
dd: "Time to go."

dt: "Limp wristed dirty hippy buys a powder blue Prius."
dd: "A way for Americans to show their strong dislike for some Toyota models."

Every time you have a concept that need further explanation, that needs a description, you can use dl: dt for the concept, dd for its description.




********************************************************************

So, "summary", is it too small for a section, or is it too big for a list item? This seems to be the problem we're facing: size, and the way we perceive it. ; )

[deathshadow60]

See, we all agree on some points, but not all agree on the same things.

Or as a favorite quote of mine goes:

If everyone is thinking the same, somebody isn't thinking. -- Gen George S. Patton Jr.

[Rayzur]

The def for h2: (%inline)* content, mandates the use of ANY and ALL repeated %inline: a, img, span, small etcetera . You're more like Steve Jobs, limiting, and I'm more like an unhappy restricted user, jailbreaking the device.

I think you missed my point. I don't have any problem wrapping portions of the heading text in <span> or <small> for styling purposes. My point is that the topic text still needs to read as a continuous phrase and make sense if those tags are removed.

Anything other than and you are just using the h2 as a wrapper where you are crossing over into heading abuse. It is no different than your view of using a <p> tag as a wrapper.

You're more like Steve Jobs...

Actually I would describe myself as being more like "Briggs & Stratton" putting a governor on your lawnmower engine. They do that to keep you from throwing a rod and blowing the engine. However it is YOUR lawnmower and if you insist on removing the governor and running alcohol racing fuel in it your than welcome to do so but that's not what it was designed for.

Addressing these concerns/issues of ALL the arguments and points of view in this thread:

1. keeping inline elements separated from blocks
2. p-tag abuse (nesting only an img, or a p tag without generic text)
3. over-stuffing the h2 with unrelated content
4. avoiding the use of List Elements (DL,Ul) for markup does not qualify as such.

Working from the simple markup I showed in post#71 I have come up with this version that accommodates all of the issues above.

Article Summaries: Version III

Seriously, I want to see the markup that will make us ALL say "There she blows!" that's the one we've been looking for.

I know it's not going to be possible for everyone to completely agree. I was curious if it was possible to find a solution that all could compromise on as acceptable markup that satisfies all points of debate. The example I just linked to would be my attempt at that.