Simple centering in block?

[Tuxedo]

Below are six text blocks styled like buttons and placed next to each other
using float:left. If the window (or containing block) isn't wide enough to
populate all buttons horizontally, some will appear on a new line.

Instead, how can all buttons be made to center in their containing block?

So far here is the basic markup:

#navigation{
margin-left: auto;
margin-right: auto;
display: table;
}

.button{
float: left;
display: block;
padding: 5px 10px;
background: green;
color: white;
margin-right: 2px;
margin-bottom: 2px;
}

<div id="navigation">
<span class="button">BUTTON #1</span>
<span class="button">BUTTON #2</span>
<span class="button">BUTTON #3</span>
<span class="button">BUTTON #4</span>
<span class="button">BUTTON #5</span>
<span class="button">BUTTON #6</span>
</div>

While the "navigation" block is centered by margin-left/right having been
set to 'auto', the buttons on additional lines (if any) will align to the
left margin of their containing block, naturally.

To display all items centered, the use of image buttons and a <center> tag
would perhaps still work in all browsers, but obviously that's not a
good solution, e.g.:
<center><img src=1.gif> <img src=2.gif> <img src=3.gif> <img src=4.gif>
<img src=5.gif> <img src=6.gif></center>

By which ways can this simple center all flow be done with CSS/HTML?

Many thanks,
Tuxedo

[Chris F.A. Johnson]

On 2013-04-11, Tuxedo wrote:
> Below are six text blocks styled like buttons and placed next to each other
> using float:left. If the window (or containing block) isn't wide enough to
> populate all buttons horizontally, some will appear on a new line.
>
> Instead, how can all buttons be made to center in their containing block?

See: <http://t.cfaj.ca/buttons.html>

--
Chris F.A. Johnson
<http://torontowebdesign.cfaj.ca/>

[Christoph Becker]

Chris F.A. Johnson wrote:
> See: <http://t.cfaj.ca/buttons.html>

Wouldn't it be preferable to display the span elements as inline-block?
Otherwise the padding is ignored.

Anyhow, one has to take care, that the "buttons" don't wrap in the
middle of their "label", e.g. by using &nbsp; instead of the space.

--
Christoph M. Becker

[dorayme]

In article <kk770t$9gr$1...@news.albasani.net>,

You could use your markup and adapt the CSS as in the following or use
or adapt the markup:

.navigation {
margin: auto;
text-align: center;
line-height: 2;
}

.navigation li {
display: inline;

padding: 5px 10px;
background: green;
color: white;
margin-right: 2px;
}

<ul class="navigation">
<li>BUTTON&nbsp;#1</li>
<li>BUTTON&nbsp;#2</li>
<li>BUTTON&nbsp;#3</li>
<li>BUTTON&nbsp;#4</li>
<li>BUTTON&nbsp;#5</li>
<li>BUTTON&nbsp;#6</li>
</ul>

--
dorayme

[Chris F.A. Johnson]

I prefer: white-space: nowrap;

[tlvp]

On Thu, 11 Apr 2013 17:26:55 -0400, Chris F.A. Johnson wrote:

> Instead, how can all buttons be made to center in their containing block?
>
> See: <http://t.cfaj.ca/buttons.html>

Hmm ... in Safari 5.* those six buttons remain in one row no matter how
narrow the viewport, rather than breaking into two (or more) centered rows.
Instead, they force the page edges to extend beyond the viewport, and hence
require lateral scrolling to see. Think that's what the OP was after?

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[dorayme]

In article <1tzoupy2cn8j3.1...@40tude.net>,

tlvp <mPiOsUcB...@att.net> wrote:

> On Thu, 11 Apr 2013 17:26:55 -0400, Chris F.A. Johnson wrote:
>
> > Instead, how can all buttons be made to center in their containing block?
> >
> > See: <http://t.cfaj.ca/buttons.html>
>
> Hmm ... in Safari 5.* those six buttons remain in one row no matter how
> narrow the viewport, rather than breaking into two (or more) centered rows.
> Instead, they force the page edges to extend beyond the viewport, and hence
> require lateral scrolling to see. Think that's what the OP was after?

I thought he wanted the buttons centred when wrapped, he already had
them centred when all fitted. If you need to see what I posted earlier
(rather than just look at the text in the post):

<http://dorayme.netweaver.com.au/buttonsCentred.html>

--
dorayme

[Tuxedo]

tlvp wrote:

> On Thu, 11 Apr 2013 17:26:55 -0400, Chris F.A. Johnson wrote:
>
> > Instead, how can all buttons be made to center in their containing
> > block?
> >
> > See: <http://t.cfaj.ca/buttons.html>
>
> Hmm ... in Safari 5.* those six buttons remain in one row no matter how
> narrow the viewport, rather than breaking into two (or more) centered
> rows. Instead, they force the page edges to extend beyond the viewport,
> and hence require lateral scrolling to see. Think that's what the OP was
> after?

Yes, that's exactly what I'm after. In fact, I find the example at
cfaj.ca/buttons.html works well in that the lines do break where the
viewport or containing block determines they should and that buttons on any
additional lines that follow are centered fine in just about every
imaginable browser except Konqueror 4.10 in Linux, and obviously the one
you mention, Safari 5.x. The rendering engines for these two particular
browsers may utilise a same codebase. At least something appears to prevent
the lines from breaking where they should in both cases.

Curiously, the lines do break correctly where they should while testing in
an old Safari 4.1.3 on OSX. They also break correctly in Safari version
5.1.7 on Windows. Other tests where all works include Firefox 14.0.1,
Firefox 15.0.1, SeaMonkey 2.12.1, Opera 11.6 and Chromium 25.x.

I even found testing with some ancient Explorers 5, 6, 7, 8 works. I guess
IE 9 and 10 works fine as well, but I don't have a Windows 7 to test on.

Anyone knows how to work around the CSS/HTML to make the lines break where
they should in Safari 5.x on OSX? If so, that would probably solve the same
problem in any current Konqueror for Linux as well.

Tuxedo

[Tuxedo]

tlvp wrote:

> On Thu, 11 Apr 2013 17:26:55 -0400, Chris F.A. Johnson wrote:
>
> > Instead, how can all buttons be made to center in their containing
> > block?
> >
> > See: <http://t.cfaj.ca/buttons.html>
>
> Hmm ... in Safari 5.* those six buttons remain in one row no matter how
> narrow the viewport, rather than breaking into two (or more) centered
> rows. Instead, they force the page edges to extend beyond the viewport,

How about Safari 6, does the same happen?

http://t.cfaj.ca/buttons.html

Do the lines wrap when narrowing the viewport, or do all buttons stay on a
single line with sideways scrolling?

Anyone having Safari 6 who can test it?

Thanks,
Tuxedo


[..]

[Christoph Becker]

Chris F.A. Johnson wrote:
> On 2013-04-11, Christoph Becker wrote:
>> Chris F.A. Johnson wrote:
>>> See: <http://t.cfaj.ca/buttons.html>
>>
>> Wouldn't it be preferable to display the span elements as inline-block?
>> Otherwise the padding is ignored.
>>
>> Anyhow, one has to take care, that the "buttons" don't wrap in the
>> middle of their "label", e.g. by using &nbsp; instead of the space.
>
> I prefer: white-space: nowrap;

ACK. A much cleaner solution. :)

--
Christoph M. Becker

[Thomas 'PointedEars' Lahn]

Christoph Becker wrote:

> Chris F.A. Johnson wrote:
>> On 2013-04-11, Christoph Becker wrote:
>>> Chris F.A. Johnson wrote:
>>>> See: <http://t.cfaj.ca/buttons.html>
>>>
>>> Wouldn't it be preferable to display the span elements as inline-block?
>>> Otherwise the padding is ignored.
>>>
>>> Anyhow, one has to take care, that the "buttons" don't wrap in the
>>> middle of their "label", e.g. by using &nbsp; instead of the space.
>>
>> I prefer: white-space: nowrap;
>
> ACK. A much cleaner solution. :)

Standalone “display: table” is an interesting idea. If only it was
interoperable as of yet.

However, a “div” element and “span” elements should not have been used here
in the first place, but an “nav” element (HTML5 only), an “ul” element as
child, with “li” elements as its children, with an “a” element (or similar)
each as its child.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

[Jukka K. Korpela]

2013-04-12 14:47, Thomas 'PointedEars' Lahn wrote:

> a “div” element and “span” elements should not have been used here
> in the first place, but an “nav” elemen

Readers probably recognize the troll who is visiting us, but just for
clarification: There is no demonstrable benefit to be gained from using
<nav>. Many people promote it for quasi-religious reasons, with
“semantic” as the mantra, failing to understand the semantics, i.e. the
meaning, of “semantic”. But they usually realize that they need to warn
that especially for the purposes of styling, <nav> really makes things
more difficult. Try styling it on old versions of IE (where styling of
<div> is smooth sailing), and you’ll see. Trolls, on the other hand,
don’t write warnings, except fake warnings.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Thomas 'PointedEars' Lahn]

Jukka K. Korpela wrote:

> 2013-04-12 14:47, Thomas 'PointedEars' Lahn wrote:
>> a “div” element and “span” elements should not have been used here
>> in the first place, but an “nav” elemen

There was a lot more. You have deliberately distorted the meaning of my
statement by omitting relevant parts, in order to support your fallacious
argument. Not the first time, if I recall correctly.

> […] There is no demonstrable benefit to be gained from using <nav>.

None that *you* are *aware of*.

> Many people promote it for quasi-religious reasons, with
> “semantic” as the mantra, failing to understand the semantics, i.e. the
> meaning, of “semantic”.

Of course, it has always been easier to dismiss ideas as nonsense – by
calling them (quasi-)religion, by calling their creators and followers
names; by crucifying them, burning them, forcing them to recant, hanging
them, chopping their heads off, locking them up for life, or deliberately
misquoting them (more or less in that order) – than to provide a single
*sound* argument against the idea or to provide viable alternatives.
However, this is not how progress is achieved, and it is obviously
contradicting core human nature; for if bullying naysayers would have
prevailed, humans would still be quadrupeds living in trees. But I digress.

I have done research on Semantic Web Technologies while studying computer
science, so I would like to think that I know what I am talking about when I
say “semantic”, and that I can be fairly rational about it.

Semantics is the study of meaning(s). [1] Particularly with regard to
computer science, it is not (quasi-)religion at all, of course; it is a
cornerstone of an informed approach to achieve a primary goal of computer
science, or “informatics” as it is also called: to *organize information* so
that it becomes *useful* even in *previously unforeseen* ways.

A primary goal of the W3C, led by its Director Tim Berners-Lee (who invented
HTML for that reason [2]), is to achieve a “Semantic Web”; a Web consisting
of *meaningful* information. [3] While this approach relates mostly to
languages other than HTML (ibid.), it needs not to exclude HTML. In fact,
RDFa [4], and the addition of semantic elements (that is, elements *only*
conveying semantics) in HTML5 (to those that already existed in previous
versions) [5a, 5b] shows that it works well with HTML, too.

> But they usually realize that they need to warn that especially for the
> purposes of styling, <nav> really makes things more difficult. Try styling
> it on old versions of IE

Your logic is flawed because its premise is based on a fundamental
misconception. The “nav” element, and other such HTML5 elements, ought not
to be styled *at all*. They are not intended to be used as a layout
container, but as a *content* container. They are there *solely* to convey
semantics, that is, *meaning(s)*. In the case of the “nav” element, the
meaning is “this content here *is* *for* navigation.” [6, 7]

It is left to the user agent how to interpret that. [6] Current user agents
*might* not interpret it at all – which would beg the question why it was
added to HTML5/WHATWG HTML in the first place, with HTML5/WHATWG HTML being
primarily *vendor*-driven, so there should be practical applications
already –, but future ones certainly could. Certainly, if the “nav” element
was used today *properly* (and there are people who do that), it is already
possible *today* to tell sections for navigation and sections not for
navigation apart *without* rendering the document. This possibility to
attach *meaning* to *textual content* is the benefit of semantic markup.

> (where styling of> <div> is smooth sailing), and you’ll see. Trolls, on
> the other hand, don’t write warnings, except fake warnings.

Ex falso quodlibet. The interesting thing about your postings, though, is
that you are quick to call names and slow to provide any references to
support your statements. As if you considered yourself infallible – by
which, curiously, but not surprisingly, we have come full circle.


X-Post & F'up2 comp.infosystems.www.authoring.html (where it belongs)

PointedEars
___________
[1] <http://www.merriam-webster.com/dictionary/semantics>
[2] <http://www.w3.org/History/1989/proposal.html>
[3] <http://www.w3.org/standards/semanticweb/>
[4] <http://www.w3.org/TR/xhtml-rdfa-primer/>
[5a] <http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#semantics-0>
[5b] <http://www.w3.org/html/logo/#the-technology>
[6] <http://www.w3.org/TR/2012/CR-html5-20121217/sections.html#the-nav-
element>
[7] <http://html5doctor.com/downloads/h5d-sectioning-flowchart.png>
--
When all you know is jQuery, every problem looks $(olvable).

[Tuxedo]

dorayme wrote:

[...]

> I thought he wanted the buttons centred when wrapped, he already had
> them centred when all fitted. If you need to see what I posted earlier
> (rather than just look at the text in the post):
>
> <http://dorayme.netweaver.com.au/buttonsCentred.html>
>

Thanks for posting the above, it works well with linebreaks and centering
on a current Konqueror browser, so I don't think it's suffering the issue
with multilines not working on Safari 5.x as the
http://t.cfaj.ca/buttons.html example does.

Tuxedo

[Felix Miata]

On 2013-04-12 10:09 (GMT+0200) Tuxedo composed:

> additional lines that follow are centered fine in just about every
> imaginable browser except Konqueror 4.10 in Linux, and obviously the one
> you mention, Safari 5.x. The rendering engines for these two particular
> browsers may utilise a same codebase.

Safari's WebKit rendering engine was originally forked from Konqueror's KHTML
engine:
http://en.wikipedia.org/wiki/KHTML
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[tlvp]

On Fri, 12 Apr 2013 17:11:47 +1000, dorayme wrote:

> I thought he wanted the buttons centred when wrapped ...

Exactly what I thought, too. But not what I saw when I shrank the viewport.

> ... If you need to see what I posted earlier

> (rather than just look at the text in the post):
>
> <http://dorayme.netweaver.com.au/buttonsCentred.html>

Yes, exactly, your page does what I had thought was intended; the page I
commented on was Chris Johnson's *original* <http://t.cfaj.ca/buttons.html>
(by this evening, of course, that page too lets the buttons wrap when the
viewport shrinks -- but then, it was "modified: 2013-04-12T01:03:20" -- it
wasn't yet quite that sophisticated when I had first viewed it :-) ).

[dorayme]

In article <1cldel3u6q7t3$.10ggyfai5tfyt$.d...@40tude.net>,

Yes, well, I am extremely sophisticated from the start but I go
downhill from there. Chris just improves like a normal intelligent
human. I will come back as a human in my next life.

--
dorayme

[BootNic]

In article <kk8fg9$7oh$1...@news.albasani.net>, Tuxedo
<tux...@mailinator.com> wrote:

> tlvp wrote:

[snip]

>>> See: <http://t.cfaj.ca/buttons.html>

>> Hmm ... in Safari 5.* those six buttons remain in one row no matter
>> how narrow the viewport, rather than breaking into two (or more)
>> centered rows. Instead, they force the page edges to extend beyond the
>> viewport, and hence require lateral scrolling to see. Think that's
>> what the OP was after?

[snip]

> Anyone knows how to work around the CSS/HTML to make the lines break
> where they should in Safari 5.x on OSX? If so, that would probably
> solve the same problem in any current Konqueror for Linux as well.

#navigation
{
margin: 0 auto;
line-height: 2.5;
display: table;
text-align: center;
}

margin auto and display table can be removed, serves no purpose with the example.

I suggest removing the line-height, use padding or margin.

I don't see any reason to use class buttons, #navigation span should would just
fine with the give example.

IF display table is to be used, another div would be required for some browsers
to hold the spans with display table-cell.


--
BootNic Fri Apr 12, 2013 11:02 pm
"I've noticed that the press tends to be quite accurate, except when they're
writing on a subject I know something about."
*Keith F. Lynch*

[Martin Leese]

Chris F.A. Johnson wrote:

> I prefer: white-space: nowrap;

Thank you for this; most useful. It seems
to have been around since CSS 1 but, for
some reason, I missed it.

--
Regards,
Martin Leese
E-mail: ple...@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[Jukka K. Korpela]

2013-04-13 20:36, Martin Leese wrote:

> Chris F.A. Johnson wrote:
>
>> I prefer: white-space: nowrap;
>
> Thank you for this; most useful. It seems
> to have been around since CSS 1 but, for
> some reason, I missed it.

It's easy to miss the usefulness of the white-space property, due to its
grossly misleading name. In fact, the CSS 1 specification said: "This
property declares how whitespace inside the element is handled", and it
was somewhat unclear whether it was a bug in browsers that they treated
the property differently.

Later, specifications were retrofitted according to realities, but the
name of the property was not changed, and even the start of the
description of the property has the same misleading statement. But then
it says that white-space: nowrap "suppresses line breaks within text".
So it prevents like breaks e.g. in "zipzap-foobar", "f(0)", and
"xyz/abc" (which contain no whitespace characters), where a line break
might otherwise be introduced by some browsers.

Moreover, white-space: nowrap also affects rendering of elements that do
not contain any characters but e.g. just img elements.

--
Yucca, http://www.cs.tut.fi/~jkorpela/