# Thread: Inline vs External Best Practices

1. ## Inline vs External Best Practices

Hello!

I've got a large site with lots of mathematical formulas. Each formula is going to have the same type of box around it as below, which I define in an external sheet:

Code CSS:
```p.highlight {
border: 1px solid #000000;
background: #99CCFF;
text-align: center;
margin-left: auto;
margin-right:auto;
width: 300px;
}```

I quickly discovered that this won't work so well since the width of each formula is different. Keeping in-line with "best practices", would the best solution be to define p.highlight without the "width: 300px" and then for each formula define a specific width?

If there's a better solution, please let me know what you think.

Thanks,

Eric

2. How wide are some of the widest formulae? It strikes me that to present your users with highlighted boxes of varying widths (taking the idea of the "ragged edge" a bit farther) would be a bit jarring to the eye. If feasible, I'd size the box to fit the longest of the formulae to ensure that all boxes are the same width.

If some of the formulae are so long that they wrap, that's another issue, more to do with breaking the particular formula with a line break so that it remains accurately portrayed than an HTML or CSS issue.

3. None of them actually wrap; but as you can see from the two examples below, the widths are very different:

$f(x)=mx+b$
$f(x)=ax^2+bx+c$

Do you still think that it would be better to have the same box size around each? I'd definitely like to know your opinion on this!

But, regardless, just so I have options, and I do have different sizes, would my original posted approach be the best way to go about it?

Thanks for giving this some more thought,

Eric

4. I would have tried setting the p.highlight to display: inline-block, with its parent set to text-align: center...

you'd need
* html p.highlight{display: inline;} /*ie6*/
*+html p.highlihgt{display: inline;}/*ie7*/

and if FF-2 (like K-Meleon)
display: -moz-inline-block; before the display: inline-block statement. Though if there are block children it'll be a disaster in those browsers. However, most devs don't support them.

5. Stomme poes,

Thanks so much for the solution. I was able to implement it with ease. As a newcomer to CSS, however, this would be my first (and probably not last!) dealings with the whole "different Browser, different behavior" issue as you indicated I would need:

* html p.highlight{display: inline;} /*ie6*/
*+html p.highlight{display: inline;}/*ie7*/

2 questions that I'm hoping you might be able to answer:

1) If I just put in the CSS as written above, how does my site know which code to use?

2) Are the asterisk and plus just "for show"? Should it be:
html p.highlight{display: inline;} /*ie6*/
html p.highlight{display: inline;}/*ie7*/

Eric

6. Originally Posted by kreut
Stomme poes,

Thanks so much for the solution. I was able to implement it with ease. As a newcomer to CSS, however, this would be my first (and probably not last!) dealings with the whole "different Browser, different behavior" issue as you indicated I would need:

* html p.highlight{display: inline;} /*ie6*/
*+html p.highlight{display: inline;}/*ie7*/

2 questions that I'm hoping you might be able to answer:

1) If I just put in the CSS as written above, how does my site know which code to use?

2) Are the asterisk and plus just "for show"? Should it be:
html p.highlight{display: inline;} /*ie6*/
html p.highlight{display: inline;}/*ie7*/

Eric
Those are hacks - IE6/7 don't properly understand 'inline-block', so you have to tell them to display 'inline' instead.

The 'star hack' targets IE6 with a declaration starting '* html ...'
IE6 is the only browser that reads that line, because other browsers know that html can't have a parent element, so nothing matches the string.

It's a similar technique for IE7 with '*+html ...'.

The /*ie6*/ at the end is just a comment to remind you why you've put some nonsense like that in your stylesheet

7. Thanks so much! I feel like I've been initiated into the wild, wacky world of CSS.

-Eric

8. ha ha ha... nothing is wacky in the world of CSS my friend. Just try to understand them, they are the sweetest creatures in the web .

Why you need to specify widths. Let the formulae get their own widths as they require, by not specifying any width.

9. My answer is a lot simpler... inline-block... and those AREN'T paragraphs so why are you putting them inside P?

Put them in spans, set the span to display:inline-block so you can apply top/bottom padding if desired, apply your styling to that. The spans will auto-shrink their width to fit.

...that's the problem with the display:inline suggested, that 6px will only get applied to the sides. You want inline-block, which legacy IE can only apply to elements that are inline-level (like span).

Which works well with the "and why are these paragraphs?" semantics. Semantic markup is NOT just slapping P around anything that happens to be text.

Actually... hah, I'd be half tempted to use a VAR tag around them... since they are sets of variables... or wrap the whole expression in CODE and put VAR around the variables.

Both CODE and VAR also being inline-level like SPAN.

Though you seem to also want them centered, so it will need a parent wrapping element like a DIV.

Code:
```<div class="codeBox">
<code><var>f</var>(<var>x</var>)=<var>m</var><var>x</var>+<var>b></var></code>
</div>```
with this for CSS:

Code:
```.codeBox {
text-align:center;
}

code {
display:inline-block;
background: #99CCFF;
border: 1px solid #000000;
}```
Should 'git er done'... and be semantically correct. Would also provide hooks for syntax highlighting (part of why VAR exists)

10. My answer is a lot simpler... inline-block...
But... but... *whine*!!! : )

and those AREN'T paragraphs so why are you putting them inside P?
I dunno, couldn't a block of fomulae be a paragraph? They're statements, aren't they? (literally too)

11. I feel like I'm stuck in the middle of Clash of the CSS Titans.
I like both of your responses equally!

-Eric

12. Originally Posted by Stomme poes
I dunno, couldn't a block of fomulae be a paragraph? They're statements, aren't they? (literally too)
Paragraphs are built from SENTENCES. If you don't have a complete sentence, it's probably NOT a paragraph.

A "statement" would be more like a "detail" -- a detail being PART of a sentence. I really don't consider these large enough to qualify as sentences much less paragraphs -- again, semantic markup is NOT about slapping P around every bit of text (or worse, non-text elements like inputs/images or elements that already have a meaning like label)

Also, being that those are variables and not text (they might be text characters, but they are being used as variables -- aka symbols) that pretty much invalidates them as paragraphs to me.

Oh, and sorry if I keep missing your posts in threads.... I think it's my nasty case of TSDR kicking in again. (too short, didn't read)

13. Paragraphs are built from SENTENCES. If you don't have a complete sentence, it's probably NOT a paragraph.
I'll stick to "paragraphs are built from statements", myself. Esp since descriptive (not proscriptive) dictionaries (talking about, like, books n stuff) can't even keep it to sentences. That and the British ones are snobby by default.

Oh, and sorry if I keep missing your posts in threads.... I think it's my nasty case of TSDR kicking in again. (too short, didn't read)
Lawlz, I just figure people keep putting me on Ignore for being obnoxious

14. Off Topic:

Originally Posted by Stomme poes
Lawlz, I just figure people keep putting me on Ignore for being obnoxious
If that were the case my posts would NEVER get read

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•