Wrap between spans - cross-browser solution? 1

[OsakaWebbie]

I'm trying to use CSS spans to keep form field labels with their respective fields while allowing wrapping between the label-field sets as needed. In Firefox it works fine to have something like this (simplifying - the actual CSS is external):

  <span style="white-space:nowrap"><label for "somefield">Field: </label><input name="somefield" ... /></span>
  <span style="white-space:nowrap"><label for "someotherfield">Other Field: </label><input name="someotherfield" ... /></span>

But in IE and Chrome (I haven't tested Safari or Opera), simple whitespace between the spans is not enough to allow wrapping, and even a space at the end of the line, the CR, and then more spaces (which are normally there for indenting anyway) is not enough. The only combination I have found to work in IE and Chrome is:

  ...</span> &nbsp;
  <span ...

I don't really want to put that   in there, because it forces two spaces (the regular one and the non-breaking one) in all cases, rather than allowing CSS to dictate the size of the space between. Plus, it's just weird to have that. Any thoughts on a more elegant method that works in all modern browsers?

 

[audiopro]

A form field which has 78 checkboxes needs a page of it's own, then you can scatter the options all over the page like confetti if you wish.

I still think that a vertical list is better than a page of confusion.

If I was giving people 78 options and wanted to populate the page, I would have all the options laid out in a uniform grid to make it easier to read.

Keith

http://www.studiosoft.co.uk

 

[OsakaWebbie]

The users don't want a page for each section of stuff; they want to see all the info about a person together. And you said, "If I was giving people 78 options" - I'm not the one doing it; the users are doing it to themselves, in spite of my recommendation to limit the number of categories they create. Anyway, regarding how to lay them out, I would love to use a uniform grid for the category checkboxes, and have thought about it on and off for several years, but the problem is that I would have no idea how wide to make the space for each column of random-length labels, i.e. how many columns to have. Yeah, I could restrict the length of category names, but that makes unhappy users, too - sometimes they need descriptive category names in two languages, which will get long. I think the number of columns of such a layout would have to be one, whereas currently even the 78 items created by undisciplined users fit on just 18 lines.

I asked one of the main users of the installation that has 78 categories (who happens to be my husband, but not a techie) what he thought of the way it is now (hard to find the category you're looking for) vs. having them laid out vertically (either on the same page or a separate page). He frowned and shook his head when I suggested the idea of a separate page, and when I asked about a vertical clean layout versus the jumble he deals with now, he called the current jumble "a necessary evil" to see the important info without too much scrolling. But you guys pounding away on this point have given me a new idea for categories, which I might try to implement at some point: instead of checkboxes that are located in one of two subsections to show which categories a person is in or not in (you haven't even seen that aspect), I might ditch the checkboxes altogether and have two lists (left is in, right is out) that are "selectable" with jQuery, and have users move people in and out of categories by selecting (or even dragging, if I can figure out how to do that), and use AJAX to make the change to the database rather than having a "Save Category Changes" button to submit a form full of checkboxes. I could then limit the vertical height of the "not in" list container to something reasonable and just provide a scrollbar for users who have created too many categories (my husband admits that about 50 of those 78 categories should probably be removed in favor of smarter ways of organizing the data, but novice users tend to use categories a lot until they learn other aspects of the functionality that are better for certain tasks), and long names would force a horizontal scrollbar as well. Meanwhile, though, a jumble of checkboxes have been used successfully by many users for many years, so it doesn't seem like an emergency. And other types of fields also need to be flexible, because of multi-lingual labels and various other factors.

But all that is usability theory about forms, which is unrelated to my original question. Can we please get back to my question? Let's forget completely about forms and keep it very simple, because my question isn't really about forms at all. (If you guys won't answer it in this thread, I may have to start over, because I doubt anyone else is reading it now that it is this long.)

Simple question: If one has...

<span style="white-space:nowrap">Some stuff</span>
<span style="white-space:nowrap">and some more stuff</span>

...and the containing div is narrow enough that the whole thing won't fit on one line, shouldn't the existence of simple white space between the spans (like regular spaces and/or carriage returns) be enough to let the browser know that it can wrap there? Why doesn't IE and Chrome do such wrapping?

 

[Vragabond]

What I would to achieve your result would be this:

label {
float: left;
white-space: nowrap;
}

<label for="field1">Longish label for a shortish field: <input name="field1" type="text" style="width:2em" /></label>
<label for="field2">Short label: <input name="field2" type="text" style="width:10em" /></label>

To my understanding, this would achieve what you want without the extra markup.

Chris, semantically speaking, one should never use 'list to emulate a table'. That simply means that you're admitting you're using an element that is not semantically fitting there. If you need to emulate an element that exists in the markup, then you're doing something wrong.

[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]

 

[audiopro]

You still don't say what type of site it is so it makes it hard to suggest a strategy.
The mere fact that you allow users to add categories of their own would send alarm bells ringing for me. We manage a trade directory and you would be surprised what categories the users try to add.
The way we got round it was the categories are in a drop down list and there is an option to suggest a new one. The new ones have to be approved by the site admins and that is a simple one click process in an admin screen. Initially there were many categories being added but now it is just a few per month.

If the users say they prefer a jumbled page to a neat layout,it would suggest to me that they have not been shown a neat layout.

In my experience, suggesting a new way of working to any user is fraught with problems, better to give them a working example to play with. Many users get into a mindset of 'we have always done it this way' and they don't realise there are other, sometimes better ways to do the same job.

Keith

http://www.studiosoft.co.uk

 

[OsakaWebbie]

Vragabond, you are a breath of fresh air! Not only did you stay on topic instead of simply criticizing me, but you gave a constructive piece of information - a suggestion of semantically-pleasing simple markup. [See my updated wraptest.html file - sections labeled "(Labels)" include that type of markup instead of spans.] Chrome and Safari are now behaving nicely with no special care in the markup's whitespace. The only remaining problem child is... drumroll... IE! (Was anyone surprised?) I haven't tested IE9, but 7 and 8 fail to wrap properly unless I remove all spaces from between the elements inside the label tag, which should have nothing to do with the issue. Any additional thoughts are welcome.

I also just now noticed that in all cases (even Firefox), there is no newline after the closing tag of the <h3> - shouldn't that be a block element? That problem doesn't happen in my real code, probably because there are other elements between the </h3> and the first label/input, but I find it a bit of a mystery in my test file.

You still don't say what type of site it is so it makes it hard to suggest a strategy.

I tried to answer when you first asked, but it is too complex and flexible to be explained with a simple soundbite (in fact, this monstrosity needs a name other than "Karen's database", but so far it defies labeling in that way also). Plus, I never asked you to "suggest a strategy", although you and Chris have felt complelled to do so anyway. Although it's off-topic, I'll try again to describe it for you: I am a missionary in Japan, and this database was originally designed to keep track of the people we know through our ministry, including communications with them, events they attended, and other related information. Since then it has expanded to be used by two churches, a prayer movement group, a resource production ministry, a child sponsorship charity, the Franklin Graham Festival that happened here last year, and most recently, a disaster relief volunteer network. For each of those applications, different aspects of the data are more important than others, and the reporting needs are quite varied - hence the level of user customization that it is capable of. Plus, the interface language is switchable between Japanese and English, so all the titles, field labels, and other text can change length. The database has 23 tables, and the interface is made up of 71 PHP files that interact with the database and produce HTML/Javascript code. Since you feel the urge to critique it even though you have not seen it, I'll give you a glimpse of one page - I displayed the person page showing my husband's info in the disaster relief network's database (since that copy has the newest code, including even Vragabond's label syntax in one spot), saved the HTML, slightly sanitized the personal information, and uploaded it to

http://crashjapan.com/db/sample.html.

I don't want to leave it up forever, but for a few days you are welcome to take a look at it. The interface is in the midst of a major overhaul (as I said early in this thread), and I'm sure this code fails validation and breaks all kinds of conventions you hold dear, but I'm only doing this as a part-time, volunteer effort and have developed it piecemeal over the last ten years - I don't have time to make it perfect, so I just make it work.

The way we got round it was the categories are in a drop down list and there is an option to suggest a new one. The new ones have to be approved by the site admins and that is a simple one click process in an admin screen. Initially there were many categories being added but now it is just a few per month.

That's a nice idea - I would have to implement it for not just categories, but also contact types, events for attendance records, and donation types, and I would need to make allowances for temporary immediate category needs, because small volunteer groups don't always have people available to do admin (at the moment I'm the admin for all but one of the installations, but I don't want to do that kind of hand-holding) and categories are designed to be used for temporary holding places as well as long-term organization. But when I get a little more buffer time I'll look into implementing something like that.

 

[ChrisHirst]

Chris, semantically speaking, one should never use 'list to emulate a table'. That simply means that you're admitting you're using an element that is not semantically fitting there. If you need to emulate an element that exists in the markup, then you're doing something wrong.

I could not agree more.

It was another of the "I don't want to use a table but is has to act like a table" questions that I was solving for someone on another forum.

So many people have taken the "do not use tables for layout" to mean;

"Do NOT use tables at all, EVER, even where tables should be used" and seem to be under the impression that the "style police" will be making them "Public Enemy No1" for using tables.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[OsakaWebbie]

I too have run into those people - I know what you mean. The difference here is that you were the one convinced that I wanted a table-like layout but was simply allergic to the <table> tag, but that wasn't at all what I was trying to do. I am perfectly happy to use <table> for tabular stuff, <div> for block stuff, <ul> for lists, <span> for inline styling, etc. As you can see in my sample page, I use lots of <table> tags. In this case I wanted certain sets of form fields in a prose style, but because you are sure that that's a bad idea, you thought I was just trying to avoid using the <table> tag. Vragabond correctly pointed out that putting the input inside the label tag and then styling the label is even more semantic than what I was doing. He did not question my reasons for wanting to lay out my page that way.

Any ideas on how to improve on Vragabond's markup to work in IE without having to be allergic to spaces in seemingly unrelated places?

 

[audiopro]

I am sorry if you feel I am criticising but I was offering alternative solutions rather than suggesting code which may or may not work with all browsers. We have all beavered away at some layout or other, only to find that it refuses to work with one or two browsers.

All I was trying to point out regarding the form layout, was that users find a columned layout easier to read than unaligned content.

Keith

http://www.studiosoft.co.uk

 

[OsakaWebbie]

No hard feelings. Written communication is dangerous, with no facial expressions or tone of voice. I did have some frustration at feeling like I couldn't get anyone to address my original question, but I don't mind additionally discussing layout ideas. After all, I'm letting you see more of my application, which is unrelated to my wrapping problem, even though I know you'll probably have issues with my code in various places - I'm not happy with it myself yet, either.

But it's still a mystery why that markup doesn't wrap. I just did some more experimentation (see new tests at the top of wraptest.html), with just text - no relationship to forms at all. IE still messes up. But I learned that it's okay with just the white-space:nowrap - it fails when I combine that with the margin-right:2em that is in my real CSS. I can put one span inside another to separate the two CSS definitions and it works okay (I wouldn't want to use such messy markup long-term though!), but when the same span (or other inline element like label) contains both the nowrap and the margin definition, IE refuses to wrap between the spans. Weird!