|
I reacted to Bob Thompson's
daynotes
where he complained...
FrontPage Editor line spacing is driving me nuts. I'd like to
be able to control the spacing before and after, similar to what you can
do in Paragraph Properties in Word. I know this must be possible, because
choosing different paragraph styles in FP Editor assigns different line spacings.
But, for example, if I choose Normal, I get extra space after each paragraph,
while if I choose Bulleted, I get simple single spacing. I've search all
over and can't find a way to change this.
Another example of how web-editor user interface simulating a wordprocessor
gives the illusion that web-authoring means detailed layout authoring. I
felt compelled to write...
Strictly speaking, there ain't no such creature as html line-spacing
adjustment. Each browser may define its own interpretation of how to render
any spacings between lines and, more to the point, between different paragraph
tags. And they do so, _differently_. Since e.g. Frontpage tricks the user
by applying a wordprocessor layout interface on top of the html editor, the
author is tempted to control the page layout in ways that the underlying
html simply doesn't support. In other words, even if you achieve a desired
layout effect, there is a risk it will only display in... Frontpage. Newer
html (and XML/XSL) may allow greater layout positional control, but this
will only work in some browsers, and not all that reliably.
There are various ways to "force" something other than browser default.
One minor (and generally workable and non-intrusive) one that I have employed
to achieve more spacing in say bulleted lists is to end each item with
"<BR>." -- the BR gives a minimum line space, the "." ensures that
the line will in fact render (empty lines will be ignored in some browsers).
" " could conceivably work too, but this is not guaranteed to always
force a rendered line.
Commonly, other web authors often go to invisible gifs (1x1, possibly
size-redefined to other pixel extents) to acheive general layout tweaking,
e.g. indents, interparagraph spacing, etc. This of course fails if for some
reason image rendering is turned off (or fails), resulting in large [image]
blocks that mess up the layout.
To this Bob repled:
I understand that HTML isn't Word, and that the formatting available
with it is much less powerful. And I also understand that rendering is browser
specific. I guess what I'd like to see is FrontPage doing the kind of things
you mention, but doing so behind the scene. The last thing I want is to hand-edit
HTML code. I don't particularly care exactly how my pages render, so long
as FrontPage and the browser do "reasonable" things. I guess what I was objecting
to was that FrontPage does offer the option for a user to do things that
FrontPage itself can do.
For example, for the following bulleted list, I entered the text "Bullet
item 1", set the style to "Bulleted list", and then presssed Enter. Front
Page inserted a new line with a bullet. It appears on screen as single spaced.
I typed the second bullet item, pressed Enter, and typed the third. On my
screen, at least, I end up with three bullet items with minimal line
space.
-
Bullet item 1
-
Bullet item 2
-
Bullet item 3
For the following bulleted list, I typed "Bullet item 1" and pressed
Enter twice, "Bullet item 2" followed by Enter twice, then "Bullet Item 3"
followed by Enter twice. I then applied the "Bulleted list" style individually
to each of the three lines. I then put the cursor on the "extra" line between
items and pressed Delete. On my screen, at least, I end up with three bullet
items with double-spaced lines.
Looking at the HTML source, the only difference is that each line of
the first group is formatted as <li>text</li> while each member
of the second is formatted
<ul><li>text</li></ul>. Now, I don't know what
<ul> or <li> is, but it'd be nice if I could choose the "effect"
and have FP98 insert the appropriate codes, instead of it forcing me to do
weird things or cut-and-paste from another document.
Still, the expectations implied by WYSIWYG-editing can be confusing.
Your bullet examples render as 1½-line and 2-line spacing in Opera.
Other browsers may do it differently. At bottom, you are trying to do visual
layout using logical content markup, with uncertain results.
In this case "ul" specifies unordered list, i.e. the browser would
add bullets to the items. For ordered lists, the block tag would be "ol",
which would cause the browser to start a numbered item list when rendering.
Anyway, in content markup terms, the first example has all the items
as being part of the same list, the second specifies 3 separate lists, each
with only one item. The extra spacing in the second example is the browser's
way to indicate this "increased logical distance", but it could equally well
be rendered in another (future?) browser with a short horisontal line, or
anything else that qualifies as a list separator.
Were the examples parsed by e.g. a blind person's browser, I imagine
that the first list would be read something like:
<unordered list>, <item>text1, <item>text2,
<item>text3, <end of list>
The second would be read as:
<unordered list>, <item>text1, <end of list>
<unordered list>, <item>text2, <end of list>
<unordered list>, <item>text3, <end of list>
This would also apply to any automated text indexing or content
mining applied to the page, which would see the second list as 3 (unrelated)
lists.
New reply from Bob:
Hmm. Your message showed up as plain text with an HTML file attached.
I double-click the attached file, which called it up in IE. I copied the
text from IE and pasted it into this message.
It was an attached html text, since I studied your earlier example
in the html-editor and wrote the reply there. Pegasus Mail then takes html
attachments and sends them as two-parters, text + html.
Thanks for explaining how the lists work. As I've said, I know nothing
about HTML. I just want to use it indirectly via FP to generate pages that
kind of look like what I want them to....
The current state of web authoring unfortunately does require some
html knowledge, otherwise you will find yourself assuming features and solutions
that are unsupported by the current html standards, but implied by the
"publishing" (dtp, wp) metaphor that the high end psuedo-WYSIWYG editors
use.
On another thread...
Incidentally, speaking of line spacing, on your site I noticed that
(on my browser at least) the final line of each paragraph has a greater line
separation than the other lines of the paragraph.
I suspect this may be only _some_ paragraphs, such as those with
altered (smaller) size. The browser will return to default size/style at
end of paragraph, and thus render the default (larger) line spacing for the
last line. When I'm unusually bothered by this in a one-off paragraph set
smaller, I will add another <BR> to force the change on a subsequent
(empty) line.
Hmm, this can probably also happen for paragraphs that specify a
non-default font (with different line spacing implied). Again, end of paragraph
means back to default. May even occur with fonts specified for paragraph
tags via CSS, but I've not really checked that out. -- Looking at some chosen
paragraphs in Opera just now, the effect is there, albeit small -- 150%
enlargement shows it. But as I mentioned above, I readily see it on paragraphs
that are set "small" and usually won't care enough to do anything about
it.
Bob then sent me an IE screenshot illustrating what
he saw.
You're right. It's only some paragraphs, typically those in your mailnotes.
I've attached a screen capture from IE to show you what I mean. The separation
is quite noticeable for me.
Thanks for the screenshot.
Yes, I see what you mean. Your size difference between default and
monospaced is a full step larger than mine, so the extra spacing affects
more paragraphs in your view. The final lines clearly have the same line
spacing as the default font size would require.
WYGIWYG. Such is the nonsense of careful layout design in current
html.
Alluding to a comment I made to Tom Syroid that Tom mentioned on
his page, Daniel C. Bowman sent me this comment:
Might not the cure be worse than the disease?? On the other hand, if
it cures a funk (also in evidence); I'll truck snow to Chaos Manor as
needed.
Keep at it; the daybook gang works quite well for my needs.
Thank you. This kind of writing is a very addictive hobby -- severe
withdrawal symptoms evident in any break of the normal flow of writing and
reading. Thus, no cure can possibly be worse... :) Anyway, try it some time;
a head stuffed into the nearest snowdrift can be wonderfully refreshing,
no matter whose it is.
|
Mail
your comments to:
bo@leuf.com
