Block and inline structure

HTML & CSS
1

Thread originally split from here.

[QUOTE=Stomme poes;4829481]Of course it doesn’t. Flow doesn’t mean “must all be inline OR must all be block”. It’s not technically illegal to mix the two in a block container, so the validator shouldn’t say anything about it (just as it doesn’t complain about bad class names or divitis).

It’s just considered a general bad practice by some AND can cause the duplicate content bug (and some other bugs) in IE < 8.[/QUOTE]

Hi poes. Nice of you to join. Long time no see :slight_smile:

Regarding flow:

On SGML and HTML

A | B
Either A or B must occur, but not both.

HTML 4 Document Type Definition

<!ENTITY % flow “%block; | %inline;”>

I read this as:

block | inline
Either block or inline must occur, but not both.

As far as I know, this is true for div, li, for example, in HTML 4.01 and also kept true in HTML5: either block level content, either inline level content for them, but NOT both.

Which makes the following type of mark up, that she presented as being for facebook what the hexagon is for the beehive, inept, to say the least:


<div>
[COLOR=Red]  <a href=""></a>
  <div></div>[/COLOR]
</div>

… and INVALID. The validator needs improvements, as it’s only trained to spot block level elements inside inline level elements. And even this one can be covered, if you nest deep enough, and you can fool the validator, this way, in giving you the badge, for an obvious invalid mark up. I believe there are topics on SPF outlining this fact.

If we disagree on this, give me some solid documented arguments to see what I’m missing, if I am indeed missing something. As far as I can tell, you’re looking more at HTML5, which has some exceptions on when a block level element may be considered inline-level container, looking at element’s child nodes.

2

You’re COMPLETELY misreading that – it’s an or, not an xor. (of course with the over the top use of legalese and piss-poor explanations, it’s not that hard to misread the spec)

Check the definition for DL… which they even reference three or four lines later:

<!ELEMENT DL - - (DT|DD)+>

The DL element must contain one or more DT or DD elements in any order. If it worked how you are thinking you couldn’t put DT and DD inside a DL at the same time – which obviously is NOT how it works.

The difference between | and & is that with | it’s an either – you can use either. With & both must be present.

A | B
Either A or B must occur, but not both.
A & B
Both A and B must occur, in any order.

Notice the difference? A | B means you can use either… the “but not both” is not saying you must not use them at the same time, it means both are not REQUIRED to be present… & requires that both be present.

“but not both” as in both are not required; not that they are mutually exclusive to each-other. One of them is REQUIRED to occur, but if one is present you don’t have to include the other – that’s all they’re saying. You’re thinking XOR instead of OR.

1 or 1 == 1
1 or 0 == 1
0 or 0 == 0

1 xor 1 == 0
1 xor 0 == 1
0 xor 0 == 0

So there’s nothing wrong with having inlines and blocks being siblings inside a div… except for the rendering bug SP mentioned, which is usually BLAMED on this when in fact the problem is usually either comment placement, or a CSS bug relating to it’s default display state, NOT it’s HTML level. (though yes, the default display state for elements is typically it’s level, the two are not the same thing)

I can see how you could misread that – it’s VERY poorly worded.

3

I believe I’m reading it right.

There is a difference between:

[INDENT]
A | B
Either A or B must occur, but not both.[/INDENT]

and what you’re suggesting I should read:

[INDENT]A | B
A or B must occur, but not both.[/INDENT]

That “Either” is making all the difference.

4

^ what Crusty said.

And I think the dl example shows it well. I can haz (and must) dt’s and dd’s in a single dl.

I remember grilling Tommy on the whole “flow” thing because at the time it was immensely confuzling. That and I wanted the specs to tell me if something was an inline or a block in its element definition (instead of just what it could contain). Though some elements can change based on who they’re in (like INS and DEL).

The IE bug, though, I could hit fairly easily with
-having blocks inside a form (divs wrapping label-input pairs) and then an inline (or inline-block depending on the browser) submit button right next to the last div… then having some content in the divs that was offscreen and having it move onscreen on :hover.

or a CSS bug relating to it’s default display state, NOT it’s HTML level

Yes, I did find setting the submit button to “block” removed the duplicate content. Which I think I had end up doing instead of changing the HTML at the time.

Hi poes. Nice of you to join. Long time no see

vacation : )

As far as I can tell, you’re looking more at HTML5, which has some exceptions on when a block level element may be considered inline-level container, looking at element’s child nodes.

Bah. HTML5 lets you mix beer bottles with milk jugs at the recycling bins. With basic tags like hgroup still being battled over, I definitely won’t be bringing up HTML5 rules without explicitly mentioning it (another excellent reason not to drop the “5” from the name).

5

What Jason said, makes sense to me… as a programmer used to read definitions that include [, |, &, ]. But…

(DT|DD)+ means that you can have a
(GROUP of DT OR DD) at least one, but many can also go

as in

  • multiple titles for a single definition
  • a single title for multiple definitions
  • multiple titles for multiple definitions
    AND you can’t have empty DL elements.

Which is SO MUCH DIFFERENT from (%flow)* which says the element must have (%block | %inline) : one of the two BUT NOT BOTH, or may be an empty element.

A*
A may occur zero or more times.

I still say my interpretation is accurate. What Jason did was taking out of the context, but the definition doesn’t resume to | or *, it includes them in a bigger logical construct. That WHOLE construct is the key to interpreting.

Ending + means the element can repeat in the content model for DL, and must occur at least once. ()+ means a group can repeat, and that group (one or more elements) must occur at least once. (|)+ means a group of either one, either the other type of element can repeat, both type of elements are allowed, and they must occur at least once.

(%flow)* means there is ONLY ONE %flow, or nothing, as in either %block, either %inline, or nothing.

Ending + = possible repeating. But absolutely one occurrence.
| + = possible repeating of either one or the other. But absolutely one occurrence of one of the two.
Ending * = the one or nothing. No repeating. Absolutely no repeating. At all.
block | inline = either block or inline. Not both. Absolutely not both. At all.
block | inline * = either block either inline, or just nothing. Not both. Absolutely not both. At all.

And yes, an element, even being a block level, may be considered an inline level container depending on its child elements content model. But that’s not the case with the code I outlined.

6

Once again, | is or, not XOR.

A | B is true in any of the following:
A is true
B is true
A and B are true

A XOR B is true in any of the following:
A is true
B is true

You’re thinking more of an XOR than an OR.

Also, if you read to an actual element, you get something like this:
<!ELEMENT DIV - - (%flow; )* – generic language/style container –>

Notice the * (zero or more) of flow, with each flow being block or inline.

7

This is not about binary logic. But I may be wrong on the whole (%flow)* thing.

The thing is, HTML5 specs are a bit more explicit on it, and they clearly state this: either block either inline for div. And HTML5 is based largely on HTML 4.01. But HTML5 also provides a mechanism accepting both block and inline and declaring the element block container or inline container, depending, or declaring block level elements as inline-level content.

8

No, it’s (%flow)*, zero or more flows… with each flow being either block or inline. Where do you get that it’s just one flow?

It’s opposed to something like:
<!ELEMENT ADDRESS - - (%inline; )* – information on author –>

which would be only inline. If they wanted to force a choice, they’d show it.

9

The error was the lack of the mandatory alt attribute whereas the nested DIV was the amateurish markup.

The %flow can be either depending upon circumstance; e.g. DIV can contain one or more paragraphs P and can contain SPAN.

So even though a nested standalone DIV with content inside is pretty awful markup it’s valid.

Though the example given in the video (remember I haven’t seen this video) was INVALID because it lacked alt not the poor use of DIV.

10

^ agreed.

11

Maybe my above logic wasn’t that bright, I admit that :slight_smile: But I still believe I’m getting the right explanation about |: one of the two, not both. The game changer is when you use repeating tokens, like + and *. And further game changer for flow is the fact that flow didn’t have to be “invented”, (block|inline) should have been enough. So, there is a reason for flow.

A good question. How did I interpret as being just one flow? The fact that, like in the case for (DT|DD), they could have easily put (block|inline). flow didn’t need to be “invented”.

Because they did “invented” flow, as being block|inline, which is still accurate: either block, either inline, and because:

<!ELEMENT DIV - - (%flow; )* – generic language/style container –>

and not

<!ELEMENT DIV - - (%block; | %inline; )* – generic language/style container –>

this leads me to believe you have to choose either block either inline and repeat that inside.

A correction I have to make though, and I’m sorry to mislead you on this one. In the video she presented a code having alt for image:

976×515 108 KB

Sorry for not looking at the code more closely, it seems my eyes slipped on the @Stubburnella in the div below img. But the rest of the OOCSS and HTML “objects” is still crap. :slight_smile:

12

They probably created %flow just in case.

Have you never created a variable for two things (or even one), thinking that you may add more later? It’s probably the same thing.

However, just because flow is %block | %inline, that doesn’t mean that an element which contains flow must choose one or the other (XOR). Each flow is completely independent of one another.

I think you’re reading in something which simply is not there. If you look at just the specs, it doesn’t disallow it, so it does allow it. If they wanted you to choose, they would have done (block*|inline*). They didn’t though, they did (block|inline)* (just like (dt|dd)+, you can have as many as you want of either).

13

Well, here you are wrong.

%flow, w/o repeating tokens like + or *, does mean ONE flow, either block or inline, for the element.

What makes my logic weak is exactly the presence of this token: , making the interpretation for (%flow) possible to go either way.

What makes my logic better are two facts:

  • they didn’t use (block|inline)* like in (DT|DD)+
  • flow didn’t needed to be invented

As for your (block*|inline*), it’s just wrong. It goes up my alley, if you can see that, as it reads exactly like I’m saying: either repeating block, either repeating inline, bot not both. The group part () is just not fitting in there.

See why they didn’t write (DT+|DD+) :wink:

Bottom line: for me (%flow)* means first evaluating “block|inline”, getting just one of the two at the other end (that’s what | stands for), and then stick with that one choice for the rest of the iteration dictated by the *. () means you can have a group of that one element you chose on the initial “block|inline” evaluation.

But it can possible go the other way: at each iteration dictated by the * token, you can get a different value evaluating “block|inline”, thus making it possible to have mixed block and inline content. The question is why flow? Why not directly “block|inline”? Since flow is not having other purpose in DTD, and the name flow does suggest something, and it’s not mixed.

Further more, HTML5 does make this distinction for div: it can have either block either level, but not both. However bad HTML5 is, I start from the premise HTML5 is backward compatible. Going from “all is good in div, block and/or inline” in HTML 4.01 to “in your div you can have either block or inline, but not both” in HTML5, that doesn’t seem so backward compatible to me, it’s seems quite the opposite to me, it seems like breaking the compatibility.

14

… and that this is still even going back and forth over something so simple just shows how poorly written the specification is.

Somebody at some point needs to go back through it and translate it into ENGLISH.

Though don’t get me STARTED on HTML5 spec’s wording compared to 4… like everything else 5 it’s like the people making it didn’t even grasp the POINT of 4 Strict, much less how the specification preceeding it said things should work.

The “more explicit on it” being exactly that – they didn’t understand it either.

15

noonnope, I don’t know how to convince you that you are just wrong…

If I am writing a program and I have “types”, I’d make an array:
type = array(‘block’,‘inline’)

That doesn’t mean that types has any special meaning beyond simply holding both block and inline.

It’s the same with flow. There is always the possibility that they may create some third type. If they do, with the current implementation, they would just have to add it to flow and that would propagate to the elements that use flow.

If they didn’t, they’d have to add it to every single one of them.

Why bother writing (block|inline) 10000000 times, when you could just do flow = (block|inline) then use flow every where else. Remember, these were written by humans, and humans are lazy. =p

There is no special meaning to flow other than it means block|inline, not that you have to choose one for any given element. They are 110% completely unrelated to one another when placed into the same parent element.

16

Well, samanime, I’m not going to bomb you if you will not convince me. :slight_smile: It’s not about being right or wrong, or taking sides, it’s about splitting the hair, understanding better. This is why I’m here, to be taught lessons. I’m not here because I feel larger than world.

But reasons “for no reason” will not change my mind. You don’t seem to fully see my side. I’m not saying flow means more then block|inline, I’m saying (flow)* means more than (block|inline)*.

Simple:

  1. flow = block|inline = either block either inline, but not both
    I think we can all agree on this. One flow = One block or One inline. Just one of the two.

  2. The problem

You say: (flow)* = (block|inline)* meaning “repeated flow content is repeated block or inline content” as in “repeated flow content is repeated mixed content”. As in more flows are more blocks and inlines mixed together.

I say (flow)* != (block|inline). In fact, I say (flow) = (block)|(inline), meaning “repeated flow content is repeated ‘either block either inline, but not both’ content”. As in more flows are either more blocks, either more inlines, but not mixed. Especially not mixed.

It’s not such a stupid logic, is it? :wink: Actually, my interpretation makes more sense looking at #1, upon which we all agreed.

That, and the backward compatibility HTML5 needs to provide, and the mode detailed spec HTML5 has. Which makes my interpretation: (flow)* = (block)|(inline) more believable.

17

I will admit I am seriously under qualified to opine here, but I have made the fas trasition from print-web designer ( 21… mo!!) and know I have begun tampering in development (PHP and followed by WP, Joomla! and Drupal). I agree with Stommey about OOCSS. I doesn’t seem to make sense … but from my observations of CMS like WP and J! for which is easier to add classes to generated content than ask the user for an ID or ID base( something I don’t understand the lack of) OOCSS may seem like logical step. so when you get code like this:


<UL class="newsflash newsflash-1  userprefix codes">
<LI class="newsflash-item1 item current-item userprefix-item"> 
    <div class="newsflash-item-wrap">
                   <h3> something>
                    <p> something</p>
                     <p> something<//p>
     </div>

    <div class="newsflash-item-wrap">
                   <h3> something>
                    <p> something</p>
                     <p> something<//p>
     </div>
</li>
<LI class="newsflash-item2 item current-item userprefix-item"> 
    <div class="newsflash-item-wrap">
                   <h3> something>
                    <p> something</p>
                     <p> something<//p>
     </div>
    <div class="newsflash-item-wrap">
                   <h3> something>
                    <p> something</p>
                     <p> something<//p>
     </div>
</li>
</ul>

of course since it’s the CMS core functions that output code like this… you can either learn to rewrite the core components of WP or Drupal… or attempt OOCSS ( or settle with CSS code that is longer than it should be)

Anyway, those are 40 mins of my life I will never get back… NEVER!!! :frowning:

18

Thanks for making me feel like punching myself in the face. GREAT example of the output from software practicing this nonsense – People are dumber, for having read that code. :goof:

19

Again, you’re reading more into it than is actually said in the spec, and completely misinterpreting the definition of “|”.

Though your reading of it would probably be accurate if that was a period, not a comma. Look to the VERB …

Either A or B must occur, but not both.

Sentence structure is such that the expanded intent of the sentence ends up.

Either A or B must occur, but not both have to occur.

the verb is occur, so that is the same thing as saying:

Either A or B must occur, but if you have one you don’t need the other.

You are reading it as:

Either A or B must occur, but if you use one you can’t use the other…

Which is NOT what’s being said there… not even CLOSE to what is being said there. The use of not is making you think exclusive, but that makes no sense given the verb.

Reminded of the one of the old 80’s pen and paper RPG’s where two people from the same villiage speaking the same language had a 1 in 3 chance of completely misunderstanding each-other :D… Or the old joke about Britain and America, two people separated by a common language… W3C and the rest of the world much?

20

I think you’re reading more into (flow)* than is there.

If flow = block|inline

then (flow)* has to be (block|inline)*.

If x = 5, then 3x = 3(5).

If myVar = “abc” then myVar + “def” = “abcdef”.

It’s simple substitution. It says nowhere, explicity or implied, that (flow)* = (block)|(inline)… You just replace the word “flow” with what it equals. flow = (block|inline), so (flow)* = (block|inline)*.

Each individual flow is completely independent of each other, and doesn’t care what the other flows are.

The reason I care so much about getting you to understand this is because I don’t want misinformation to be spread from this topic by others reading only a few posts of this topic.