This message summarizes the responses I received to my
query about hardcoding line breaks and spaces in page text.
I have listed the general reasons pro and con, followed
by quotes from the responses.
The general consensus is to not do this. The handful of
responses that could be construed as supportive of hard-coding
suggested scripts to remove the codes for translation. We
could certainly (and easily) do this, but do we then insert
the codes for each language or not? That is, do we do much
manual work to make each language as aesthically appealing
as English? If not, then why do it for English?
For the record, we do have requirements to provide accessible
content and to support multiple platforms/browsers. So those
points are very well taken.
Overall, my favorite quote from the responses is: "Clean, flexible
code will serve you best in the long run and are worth the
minor compromises in aesthetic control."
Thanks very much,
Mary
Original question:
------------------
I am having a, er, spirited discussion with our page layout
designer who has a tendency to force breaks (or non-breaks)
on the text on our web app UI. For example:
"word&nbsp;word&nbsp;word<br>&nbsp;word&nbsp;word"
This gives the page a nice look in English, but breaks down
rather badly when the product is translated to German, French,
and Spanish.
I claim that this is a mixture of code and text that I18N/L10N
guidelines advise against. It also, I think, makes it harder
for the translators to do their translations (a very expensive
proposition) and makes it harder to QA the translations. Many
of these cases have to be tweaked for the new language. I think
we should lay out the pages such that the text floats and looks
at least OK in all languages.
Opinions? Experiences? Pointers to guidelines I may have missed?
Suggestion?
Responses
---------
1. Don't do it
"I can see no reason for using <br> tags if you have a business
requirement not to use them, which it seems you do. Any designer worth
their salt will work around this constraint using tables to restrict
width, or perhaps css."
2. Get over it: the web is not a print medium
"To me, this falls under the "letting go" approach to Web design. You
misunderstand the nature of the Web if you try to force a certain
presentation on users. These people feel a need to control the Web.
Oftentimes (though not always), they come from a print background.
IMHO, they need to let go of their perfectionist tendencies and see the
beauty in a flexible design that works in multiple environments."
----
"You seem to have a designer from a print background, where we
enjoyed much more control. I sympathize. But it's time for her
or him to get over it :)"
3. Bad things happen if users resize their browser fonts
"Sometimes, simply using the "enlarge text" browser feature and
demonstrating how the effect the control-freak is trying to achieve is
ruined is enough to sway the guilty party. Unfortunately, sometimes
this leads them to want to lock-down the look by specifying fixed font
sizes or--God forbid--a GIF of the text."
----
"Among other issues, allowing user-sizable text and fluid page width
are best practices he or she should at least know about, if not
wholeheartedly adopt."
----
"Another issue related to forced line breaks comes into play when users have
adjusted the default text size (up or down) for their browser. The neat and
tidy display is gone when someone views pages at a text size of "larger".
Unless your layout designer is also using absolute (fixed size) instead of
relative (resizable) font sizes - which is another interesting discussion
between the graphically oriented and more functionally directed groups."
----
"I think forced line breaks for aesthetics are always a bad idea in the Web
world. For one thing, to meet accessibility requirements users need to be
able to increase and decrease the font size of the web page within their
browser. Forced line breaks of this kind often look hideous when the type
size is changed dramatically, even in English."
----
"The best way to stop your page-layout
designer from hard-coding spaces is to
open the page in a web browser and keep
increasing the user-specified font size until
the page looks utterly awful. This will remind
him that on the web you *don't know the
properties of the output medium*, and all
you can do is work within the limitations of
CSS for the time being."
4. On the web, the user is in charge, not the designer
"And you're stuck trying to explain the new world order of user being
in charge of such things."
----
"Speaking as a proponent of user control as the primary advantage of web
over traditional applications, the issue this raises is the assumption
that the website will always be viewed in the same way by all users.
"This assumption fails rather quickly with something as simple as a new
browser version, even for English-only. Add in the ability of the user
to change font size, default font, resize windows, etc. and you end up
with a site that must be flexible enough to accommodate these
scenarios. Translation: hard-coding is bad.
---
"This is a paradigm that a lot of designers moving from print to web
struggle with: the web, by definition, is a user environment and should
be coded as such. One of your tasks is to generate a fundamental
understanding by your page designer vis-a-vis the *advantages* of this
flexbility to the end-user, providing them with a different way of
looking at design."
5. Not Accessible
"Best practices for user-centered design don't include these kinds of
manipulations, since they greatly impede accessibility, among other
problems."
"You might look into accessibility related discussions for solid arguments
on
the use of resizable fonts."
6. On the other hand...
"Is the page layout designer just prettying things up, or does he or she
have
utilitarian reasons?
"Frankly, there is a stronger-than-normal tendency among UI practitioners to
regard our priorities as paramount. While it is very satisfying to produce
a
product that serves all needs well, it is far from unusual that priorities
will
conflict. Sometimes we have to acknowledge the importance of others."
----
"Instead of controlling where *each* line breaks, you can encourage the
designer
to use <nobr> where a widow or other break would be especially egregious."
7. Use a script to remove the offending chars for translation
"Besides, how hard can it be to run a search-and-replace on non-breaking
spaces
and BR tags before turning the text over to translation?"
8. Cross-browser problems
"However, I do find that forcing breaks to make the layout "just right" can
be
very frustrating when checking for cross-browser and cross-platform
compatibility. It may work on many, but look horrible on a few. And if those
few happen to be Mac, or worse, Mac OSX, welll ... hardly anyone uses that
junk, right? :)"
----
"I don't know if you have absolute control over which browser folks view the
web app in, but you can bet that even in English it looks horrible in some
browsers. This will be especially true if you are letting them re-size the
text. And with the translation issue it seems a no-brainer to leave it
afloat."
----
"And what about pages that need to display on mobile devices? Line breaks of
this sort would be a huge no-no."
9. Untagged content is better for translation
"1) have the content be untagged for breaks
2) use this raw content for translations
3) allow the designer to do her thing to the raw content such that it
doesn't
impact anyone downstream, e.g. the recipients of translated content
"...content will vary from language to language too, e.g. in Spanish the
exclamation marks and question marks have an inverted 'partner' at the
beginning
of the sentence, something not done in English. So it only seems sensible to
me
to keep content as such w/ potentially no mark up whatever, unless there is
some
subset of markup that makes sense for all recipients to have such as title
and
alt tagging."
[this writer also suggested programmatically removing the markup for the
translation.]
10. Download time
"Plus, the extra tags add additional text for downloads. Not a huge issue,
but one more tiny thing to consider."
11. Achieve control via style sheets, XLST
"1 - Increased use of style sheets
2: - Increased use of XSLT ( what if the page needs to be rendered on a
phone or other
mobile device, eg.) The trend is to add the formatting as late as possible
in the delivery
of the content, when it might be possible to know te device (and locale) of
the destination
display."
----
"Using CSS style sheets is a nice, standards-compliant way to keep
your text lines to a readable length. Just set width to a typographic
width, as opposed to pixels or percentages. Try 20-30 em and see how
that looks. Of course, it scales with different font sizes. I'm
assuming that line length is the reason for hard-coding the spaces
and breaks."
12. General comments
"The standards-supporting, accessibility-enabling, write once - publish
anywhere side of me supports you."
"The communications is enhanced with good layout side of me supports your
page layout designer."
----
A couple of responders lamented the overall poor support in browsers for
real typography: "The root of the problem is the lack of support for any
intelligent text rendering in most browsers, not even hyphenation."
Very true.
--------------------------------------------------------------
Tip of the Day: Quote only what you need from earlier postings
CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
--------------------------------------------------------------