css to prevent a line break

[Denis McMahon]

I'm trying to find a way to prevent line breaks occurring between form
elements (principally checkboxes and radio buttons) and associated text.

Most browsers seem to consider that it is always legitimate to break a
line either side of an input element, regardless of whether there's any
whitespace there or not.

I was hoping that wrapping the elements that I want to be kept together
with something like:

<label style="line-break:none"><input blah... />One-word-label</label>

would work, but neither line-break, word-break nor word-wrap appear to
help.

Any css suggestions?

Rgds

Denis McMahon

[Philip Herlihy]

In article <4f984f29$0$2833$a826...@newsreader.readnews.com>,
denismf...@gmail.com says...

My first reaction would be to wrap these elements in a DIV (or UL), with
display:block (or inline-block) and a width or min-width.

--

Phil, London

[dorayme]

In article <4f984f29$0$2833$a826...@newsreader.readnews.com>,

Try style="white-space: nowrap"

--
dorayme

[Denis McMahon]

On Thu, 26 Apr 2012 07:34:21 +1000, dorayme wrote:

> In article <4f984f29$0$2833$a826...@newsreader.readnews.com>,
> Denis McMahon <denismf...@gmail.com> wrote:

>> I'm trying to find a way to prevent line breaks occurring between form
>> elements (principally checkboxes and radio buttons) and associated
>> text.

> Try style="white-space: nowrap"

Thanks, that did the trick.

Rgds

Denis McMahon

[tlvp]

On Thu, 26 Apr 2012 07:34:21 +1000, dorayme wrote:

That seems to be the valid and universally effective (but long-winded)
replacement for the (not even deprecated but simply) invalid yet
universally honored inline tag-pair <NOBR>...</NOBR> :-) .

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

[dorayme]

In article <11iukxyqo3hra$.1rmagcej2f6ki$.d...@40tude.net>,

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

> > Try style="white-space: nowrap"
>
> That seems to be the valid and universally effective (but long-winded)
> replacement for the (not even deprecated but simply) invalid yet
> universally honored inline tag-pair <NOBR>...</NOBR> :-) .

Put this toy through a wind tunnel and measure relative lengths in a
commonplace and likely scene. Imagine a webpage, the author cares to
style it. So, he classes what needs to be classed, then he assigns
properties and values. He chooses nice colours, suitable margins and
paddings and fonts and sizes and ... hey, while he is at this
activity, he adds a little "white-space: no wrap;" in the style sheet.
It would be more long-winded, surely, count the actions, to not do
this and be shifting and key-pressing added HTML elements into the
HTML for some styling purposes. It would be particularly long-winded
because the ghost of William of Ockham would appear and you would have
to go through some demanding conversation with him. <g>

--
dorayme

[tlvp]

Please don't get me wrong, dorayme: I'd rather have
valid-and-a-bit-more-long-winded-than-brief than brief-but-invalid any day.

In point of fact, my unspoken wish was for comments -- stylistic,
historical, passing, snide, or other -- on the sad fate of the <NOBR> tag:
how has it come to be so abandoned by all who might otherwise gain from it?

[dorayme]

In article <ertylehaviyg$.59xsiprlfq32$.d...@40tude.net>,

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

> On Thu, 26 Apr 2012 17:34:30 +1000, dorayme wrote:
>
> > In article <11iukxyqo3hra$.1rmagcej2f6ki$.d...@40tude.net>,
> > tlvp <mPiOsUcB...@att.net> wrote:
> >
> >>> Try style="white-space: nowrap"
> >>
> >> That seems to be the valid and universally effective (but long-winded)
> >> replacement for the (not even deprecated but simply) invalid yet
> >> universally honored inline tag-pair <NOBR>...</NOBR> :-) .
> >
> > Put this toy through a wind tunnel and measure relative lengths in a
> > commonplace and likely scene. Imagine a webpage, the author cares to
> > style it. So, he classes what needs to be classed, then he assigns
> > properties and values. He chooses nice colours, suitable margins and
> > paddings and fonts and sizes and ... hey, while he is at this
> > activity, he adds a little "white-space: no wrap;" in the style sheet.
> > It would be more long-winded, surely, count the actions, to not do
> > this and be shifting and key-pressing added HTML elements into the
> > HTML for some styling purposes. It would be particularly long-winded
> > because the ghost of William of Ockham would appear and you would have
> > to go through some demanding conversation with him. <g>
>
> Please don't get me wrong, dorayme: I'd rather have
> valid-and-a-bit-more-long-winded-than-brief than brief-but-invalid any day.
>

You are missing my real point. I was *disputing* your claim. It might,
on some occasions, be that using HTML elements and good old attributes
is less in key presses, but taking a larger view of things - this is a
CSS group - it is not. The point about a CSS sheet is write once/apply
to a billion pages, compare that with writing your HTML alternative on
every single page where you need the same style to similar elements.

Have you ever actually met William? I might be able to arrange it, he
owes me one for giving him so many plugs over the years.

--
dorayme

[Jukka K. Korpela]

2012-04-26 10:34, dorayme wrote:

>> <NOBR>...</NOBR> :-) .
>
> Put this toy through a wind tunnel and measure relative lengths in a
> commonplace and likely scene.

A nice little story you told us, but in fact it is much faster to slap
the tags around things that are to be kept on one line. There is a lot
of time that people spend in explaining how time could be saved.

> hey, while he is at this
> activity, he adds a little "white-space: no wrap;" in the style sheet.

You forgot the need to have an element to attach it to. Surely, when the
markup is <label ...>... <input ...></label>, you have the element,
though you need to be careful to write a selector that only affects
those <label> elements that it needs to. But what if the markup is the
more natural one:

<label ...>...</label> <input ...>

Well, you can slap <span class=...> and </span> around that. What class
name you would use there? You can't write what you really mean,
class=nobr, since your Semantic Purist's License would be revoked
immediately. In a fortnight or so, you might eventually decide on using
class="combination-of-input-control-and-associated-label">.

> It would be more long-winded, surely, count the actions, to not do
> this and be shifting and key-pressing added HTML elements into the
> HTML for some styling purposes.

Well, I only need to use the Shift key thrice to type <nobr> and
</nobr>. Your mileage will vary. I don't see it as a big issue, since
when writing web pages, I employ the Shift key all the time. I even have
a permanently employed Shift key! Wait... two of them, though I don't
think I ever used the right one.

> It would be particularly long-winded
> because the ghost of William of Ockham would appear and you would have
> to go through some demanding conversation with him.<g>

Old Bill told me he has been thoroughly misunderstood and that the
hypothesis of his own existence has been proved to be completely
unnecessary, when Ockham's razor is allowed as a weapon.

Any use of CSS for preventing a line break postulates the existence of
an entity (an element that CSS declarations can be assigned to). So at
most, you would save have a duel of two Ockhams. That would be rather
brutal, a duel with razors.

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

[dorayme]

In article <jnb8ha$8f6$1...@dont-email.me>,

"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:

> 2012-04-26 10:34, dorayme wrote:
>
> >> <NOBR>...</NOBR> :-) .
> >
> > Put this toy through a wind tunnel and measure relative lengths in a
> > commonplace and likely scene.
>
> A nice little story you told us, but in fact it is much faster to slap
> the tags around things that are to be kept on one line.

In some common scenes it is not a fact. There is a general point worth
making: we should not be too sure that using elements and attributes,
or even inline css styles, is quicker or shorter or more efficient.
Sometimes it is and sometimes it is not, it depends on how one-off it
really is going to be in a website.

Some of us often (perhaps too often) blaze away with 'style' elements
including the style one and later remove them and make do with a more
central and logical stylesheet for easier maintenance and for the
styles to apply more generally.

Isolated tactical interventions are not all that interesting, who
cares what we all do here and there? The main interesting thing about
the practice of keeping the styles separate is longer term and
strategic.

This is a CSS group, why should I not needle the suggestion that
sticking in elements is quicker, why shouldn't I say: don't be so
sure, look at a few deeper issues? Why should I not fly a few
patriotic CSS flags? I hum a CSS tune and get lumps in my throat just
like humans do for their countries.

> There is a lot
> of time that people spend in explaining how time could be saved.
>

Like that it is a waste of time to wonder for too long about how to
save time by putting a couple of html tags on a line instead of an
inline style.

> > hey, while he is at this
> > activity, he adds a little "white-space: no wrap;" in the style sheet.
>
> You forgot the need to have an element to attach it to.

If the style applies to lots and lots of things in a webpage, the
style could be well worth it, no matter how long it was. How long can
a style be anyway? We know there are not many limits on how many
elements and pages one style can apply to. So in consideration of this
larger point, I did not really forget to mention the need for an
element. I was making a larger point.

...

> Well, you can slap <span class=...> and </span> around that. What class
> name you would use there? You can't write what you really mean,
> class=nobr, since your Semantic Purist's License would be revoked
> immediately.

Let it be revoked! You *can* write what you mean. Semantic purism is
something I have always thought to be directed at the meanings of HTML
elements. Some people extend this idea to some sort of
"literal-cum-general" naming of classes. Without the generality, it is
often thought not purely semantic. Well, I disagree. It
overcomplicates and confuses two concepts, I say you *can* forget
generality and still sleep at night.

Take class="left", it can be quite literal for an *actual* use. It is
often condemned as not being general enough. The generality must
encompass all the possible worlds where the content that one author at
one time puts on the left, the same or different author, later puts on
the right or several miles out elsewhere. Yes, yes... But you still
said what you meant, the client still pays and you still have it do
what you want and mostly it actually helps a stranger to see what is
going on. He or she can change the word to suit his or her actual and
practical intention. I call this sensible naming. In fact, given our
national day yesterday, allow me to call it Anzac Naming (AN).

> In a fortnight or so, you might eventually decide on using
> class="combination-of-input-control-and-associated-label">.

So change it already!

--
dorayme

[Ben C]

On 2012-04-26, Jukka K. Korpela <jkor...@cs.tut.fi> wrote:
[...]

> Any use of CSS for preventing a line break postulates the existence of
> an entity (an element that CSS declarations can be assigned to). So at
> most, you would save have a duel of two Ockhams. That would be rather
> brutal, a duel with razors.

Quite often you already have the element though. Suppose you have ten
lists with a dozen elements in each that you don't want wrapped. Well
that's one CSS rule or 240 nobr tags. Even if you can put nobr around
the outside of the list (can you? who knows?) that's 20 tags.

You're right there are times where nobr is more convenient and
straightforward than having to invent spans but there are plenty of
times it's not.

Since white-space values like pre that are typically applied to whole
blocks are surely more logical existing in CSS then the others might as
well belong there too.

Ockham's razor doesn't really apply to an individual's actual web page,
but to the language one is talking about defining. Otherwise why not
have a <korpela> element that means everything inside should be
formatted and styled the way Korpela likes it? That way he only uses one
element and this is simplicity itself. But there is a cost: the language
would need several billion such elements, and finding the one you wanted
in the manual would be more trouble than constructing what you needed
out of a smaller set.

Not increasing the number of elements in HTML and properties in CSS
beyond practical necessity is the true application of the razor here.
Since we need a white-space property we don't really need a nobr element
as well.

[dorayme]

In article <slrnjpjg9d....@bowser.marioworld>,

Ben C <spam...@spam.eggs> wrote:

> On 2012-04-26, Jukka K. Korpela <jkor...@cs.tut.fi> wrote:
> [...]
> > Any use of CSS for preventing a line break postulates the existence of
> > an entity (an element that CSS declarations can be assigned to). So at
> > most, you would save have a duel of two Ockhams. That would be rather
> > brutal, a duel with razors.
>

...

> You're right there are times where nobr is more convenient and
> straightforward than having to invent spans but there are plenty of
> times it's not.
>

Even so, if you have an assistant to do this work, it is just as
*convenient* to use a style. Convenience, to explain, is relative to
the tools you have. On some machines, you can press a key or key combo
and have <span style=""> appear where the cursor appears. You can have
it more detailed still. You can place the cursor after the words you
want styled and press Control Option C and if a closing tag is needed
or wanted, it will appear. The editor is an assistant.

> Ockham's razor doesn't really apply to an individual's actual web page,

> but to the language one is talking about defining. ...

No disagreement with the deeper point you make but it *can* apply to a
single web page. It is so versatile. I would never leave the house
without one.

>
> Not increasing the number of elements in HTML and properties in CSS
> beyond practical necessity is the true application of the razor here.
> Since we need a white-space property we don't really need a nobr element
> as well.

Yes. I am reminded of scientific applications. It is sometimes pointed
out - well, at least I point it out now and then with a nod to William
- that it is better to have a theory that accepts lots of entities
than one that postulates lots of *types* of entities. For example, if
you can make do with a small number of atomic particles, (protons,
neutrons, electrons...), it does not matter so much that there are
lots of instances. It is mostly less manageable to have lots of types.
We can control our theories and our language, not so much the world at
large.

--
dorayme

[tlvp]

On Thu, 26 Apr 2012 20:21:48 +1000, dorayme wrote:

> Have you ever actually met William?

Mmm ... for the sake of my beard, I try to avoid encountering him, at least
when he's in that vile and unpredictable razor-wielding mood of his.

Not something you could have known, of course. Cheers, -- tlvp

[Ben C]

On 2012-04-26, dorayme <dor...@optusnet.com.au> wrote:
> In article <slrnjpjg9d....@bowser.marioworld>,
> Ben C <spam...@spam.eggs> wrote:
>
>> On 2012-04-26, Jukka K. Korpela <jkor...@cs.tut.fi> wrote:
>> [...]
>> > Any use of CSS for preventing a line break postulates the existence of
>> > an entity (an element that CSS declarations can be assigned to). So at
>> > most, you would save have a duel of two Ockhams. That would be rather
>> > brutal, a duel with razors.
>>
> ...
>
>> You're right there are times where nobr is more convenient and
>> straightforward than having to invent spans but there are plenty of
>> times it's not.
>>
>
> Even so, if you have an assistant to do this work, it is just as
> *convenient* to use a style. Convenience, to explain, is relative to
> the tools you have. On some machines, you can press a key or key combo
> and have <span style=""> appear where the cursor appears.
>
> You can have it more detailed still. You can place the cursor after
> the words you want styled and press Control Option C and if a closing
> tag is needed or wanted, it will appear. The editor is an assistant.

Easily, but there are lots of good reasons for not making source code
too cluttered. Copy and pasting is easier in the very short term but
quickly becomes annoying.

If you had to do too much of it you'd design a better language, use
that, and generate the verbose version from it. People already do this
with things like "markdown"; and in any case most of the HTML that ends
up in your browser is cobbled together from templates and things by
programs, not completely written by hand.

But in spite of all that there are still good reasons for not treating
it like a binary format-- often you have to debug the output that the
browser actually sees, and we're told search engines might prefer things
that are more human-readable.

So "convenience" here (I used the wrong word) is more about how the
final result looks and whether everything seems to fit in place
reasonably well.

I've often rewritten a program to make it shorter and thus "save all
that typing" (which has already been done). In many cases I've
programmed the editor to remove code not add it.

>> Ockham's razor doesn't really apply to an individual's actual web page,
>> but to the language one is talking about defining. ...
>
> No disagreement with the deeper point you make but it *can* apply to a
> single web page. It is so versatile. I would never leave the house
> without one.

Yes that's true. What you want to achieve with your single webpage is
usually the simplest and most flexible using the rules that are
available. More rules and maybe you can make it simpler, but it becomes
too difficult for people who haven't spent ages on it to understand all
the rules.

>> Not increasing the number of elements in HTML and properties in CSS
>> beyond practical necessity is the true application of the razor here.
>> Since we need a white-space property we don't really need a nobr element
>> as well.
>
> Yes. I am reminded of scientific applications. It is sometimes pointed
> out - well, at least I point it out now and then with a nod to William
> - that it is better to have a theory that accepts lots of entities
> than one that postulates lots of *types* of entities. For example, if
> you can make do with a small number of atomic particles, (protons,
> neutrons, electrons...), it does not matter so much that there are
> lots of instances. It is mostly less manageable to have lots of types.

Exactly right. We see the same tradeoff a lot in computing, for example
in the design of machine instruction sets. For programming languages and
markup systems it's a practical matter of finding the balance and
adapting to human nature. Lisp is too simple for most people (or
requires too much creativity if you write your own macros), C++ a bit
too complicated, and Python about right.