Lenth of lines in html source?

[andrew]

Hi,

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Thanks,

Andrew
--
Do you think that's air you're breathing now?

[andrew]

On 2008-07-08, andrew <an****@ilium.invalidwrote:

http://www.slrn.sourceforge.org

Doh!!! Make that:

http://slrn.sourceforge.org

Andrew

--
Do you think that's air you're breathing now?

[andrew]

On 2008-07-08, andrew <an****@ilium.invalidwrote:

On 2008-07-08, andrew <an****@ilium.invalidwrote:

>http://www.slrn.sourceforge.org

Doh!!! Make that:

http://slrn.sourceforge.org

Or even:

http://slrn.sourceforge.net

Hmmm... somedays I think I should just stay in bed ...

Andrew

--
Do you think that's air you're breathing now?

[Jonathan N. Little]

andrew wrote:

Hi,

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

It's a personal preference thing, does not really matter in the end.
Multiple whitespace is supposed to collapse to a single space character
by the browser. So breaking a long line of copy with extra carriage
returns will not change the rendering of the page.

If you edit the content copy much, manually breaking each line at 72-80
characters may become tedious.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Sherman Pendley]

andrew <an****@ilium.invalidwrites:

Hmmm... somedays I think I should just stay in bed ...

Only *some* days? I'd say you're doing pretty well then.

Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Blinky the Shark]

Sherman Pendley wrote:

andrew <an****@ilium.invalidwrites:

>Hmmm... somedays I think I should just stay in bed ...

Only *some* days? I'd say you're doing pretty well then.

Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

I wonder if there's a logical/organizational style difference between
people with even a little programming experience and those who've never
written anything but email and a few college term papers.
--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Need a new news feed? http://blinkynet.net/comp/newfeed.html

[Ben C]

On 2008-07-08, andrew <an****@ilium.invalidwrote:

Hi,

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Yes, about 80 columns.

In many ways your system is more logical-- let the editor wrap it to
whatever the user wants. "Fluid text editing" you might call it.

But people have got used to line breaks about every 80 columns and lots
of programs work better with it. For example in the vim editor you
usually move up or down one (real) line at a time with the j and k keys.

[Ben Bacarisse]

andrew <an****@ilium.invalidwrites:

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

[corrected to slrn.sourceforge.net]

>
which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

I always do, but I do it is not primarily for viewing, but for other
tools that are line-based. For example, you get shorter listings from
diff if the lines are shorter and many editors are line oriented.

I note you only do it in paragraphs of running text, but even there
I'd would break the lines. Your editor may have an option to wrap
text by adding line endings rather than simply displaying the text as
if they were there. This is the best of both worlds -- effortless
while editing text, but neatly broken up when someone looks at the
source.

--
Ben.

[David Stone]

In article <pa****************************@thurston.blinkynet .net>,
Blinky the Shark <no*****@box.invalidwrote:

Sherman Pendley wrote:

andrew <an****@ilium.invalidwrites:

Hmmm... somedays I think I should just stay in bed ...

Only *some* days? I'd say you're doing pretty well then.

Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

I wonder if there's a logical/organizational style difference between
people with even a little programming experience and those who've never
written anything but email and a few college term papers.

No, just an experiential one.

[Darin McGrew]

andrew <an****@ilium.invalidwrites:

>Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Ben Bacarisse <be********@bsb.me.ukwrote:

I always do, but I do it is not primarily for viewing, but for other
tools that are line-based. For example, you get shorter listings from
diff if the lines are shorter and many editors are line oriented.

To help diff, version control systems, merge tools, etc., you should also
avoid arbitrarily rearranging the line breaks when you edit files.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"FAILURE IS NOT AN OPTION. It comes bundled with the software."

[Blinky the Shark]

David Stone wrote:

In article <pa****************************@thurston.blinkynet .net>,
Blinky the Shark <no*****@box.invalidwrote:

>Sherman Pendley wrote:

andrew <an****@ilium.invalidwrites:

Hmmm... somedays I think I should just stay in bed ...

Only *some* days? I'd say you're doing pretty well then.

Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

I wonder if there's a logical/organizational style difference between
people with even a little programming experience and those who've never
written anything but email and a few college term papers.

No, just an experiential one.

Coding would be an experience. As would the others.
--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Need a new news feed? http://blinkynet.net/comp/newfeed.html

[David E. Ross]

On 7/7/2008 6:37 PM, andrew wrote:

On 2008-07-08, andrew <an****@ilium.invalidwrote:

>On 2008-07-08, andrew <an****@ilium.invalidwrote:

>>http://www.slrn.sourceforge.org

Doh!!! Make that:

http://slrn.sourceforge.org

Or even:

http://slrn.sourceforge.net

Hmmm... somedays I think I should just stay in bed ...

Andrew

My browser is SeaMonkey 1.1.10. When I view the source of
<http://slrn.sourceforge.net>, SeaMonkey's display is wrapped.

My feeling is that the displayed page in a browser window should have no
horizontal (right-left) scroll bar. The rendered HTML is targeted to
others. Thus, appropriate formatting (including fitting within the
width of the window) is important. However, that does not extend to the
displayed source HTML, which is targeted only to me.

I manually compose HTML using Wordpad, which wraps the display without
inserting actual line breaks. I don't use indentation or other
formatting of my source. Instead, I use blank lines to separate
sections (paragraphs, bulleted lists, etc).

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

[David E. Ross]

On 7/7/2008 10:59 PM, Blinky the Shark wrote:

Sherman Pendley wrote:

>andrew <an****@ilium.invalidwrites:

>>Hmmm... somedays I think I should just stay in bed ...

Only *some* days? I'd say you're doing pretty well then.

Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

I wonder if there's a logical/organizational style difference between
people with even a little programming experience and those who've never
written anything but email and a few college term papers.

I was a software programmer and engineer for 40+ years. Software that I
wrote was formatted (within the constraints imposed by the compilers) to
improve readability and logical analysis. This included indentations,
etc. As I indicated in a slightly earlier reply, I do not do this with
my manually composed source HTML; instead, I only use blank lines to set
off sections.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

[David E. Ross]

On 7/8/2008 5:30 AM, Ben Bacarisse wrote:

andrew <an****@ilium.invalidwrites:

>I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

[corrected to slrn.sourceforge.net]

>which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

I always do, but I do it is not primarily for viewing, but for other
tools that are line-based. For example, you get shorter listings from
diff if the lines are shorter and many editors are line oriented.

I note you only do it in paragraphs of running text, but even there
I'd would break the lines. Your editor may have an option to wrap
text by adding line endings rather than simply displaying the text as
if they were there. This is the best of both worlds -- effortless
while editing text, but neatly broken up when someone looks at the
source.

Actual line breaks (not display wrapping) can be a real pain when
editing the content of a paragraph. The result can be lines of strange
lengths.

I used to insert line breaks until I saw this effect while revising Web
pages. When I still find this while editing some of my older pages, I
always remove the line breaks.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

[Dr J R Stockton]

In comp.infosystems.www.authoring.html message <m1abgthuqc.fsf@dot-
app.org>, Tue, 8 Jul 2008 00:20:59, Sherman Pendley <spamtrap@dot-
app.orgposted:

>
Anyway, to answer your question, it's common practice to wrap and
indent HTML source in my experience. The bandwidth that's saved by
deleting the whitespace is trivial.

Bandwidth is not the only consideration; some of us have limited storage
space. After some years of manual editing on my site, largely with an
editor that preserved trailing white-space, I ran a tool to remove such
and reduced the total size by, IIRC, a few percent - well worth the
modest effort involved.

I use, predominantly, a programmers' editor in which Alt-E X P will pack
a paragraph to a margin of 72 characters, and use that routinely. And
whenever I've edited a page or pages I run a batch file which quickly
checks the work with TIDY, trims trailing whitespace, reports long lines
(except if starting with a space character), offers to change any word
8061 to 8601 and a few other "words" likewise, checks all local relative
links for destination page and anchor, etc.

I don't remove leading whitespace from the server copy, since (a) I use
that as an off-site backup, (b) some of it is intended to be readable
as source by others.

If using plain-text tools to edit or view the source, it's clearly
worthwhile to have readily-readable text.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[andrew]

On 2008-07-08, David E. Ross <no****@nowhere.notwrote:

I was a software programmer and engineer for 40+ years. Software that I
wrote was formatted (within the constraints imposed by the compilers) to
improve readability and logical analysis. This included indentations,
etc. As I indicated in a slightly earlier reply, I do not do this with
my manually composed source HTML; instead, I only use blank lines to set
off sections.

Thanks for your reply, and others. My own html is written with Bluefish,
a Linux program which shows only a code view but has tag completion,
allows automatic indentation, has a little 'preview in browser, button
etc. I can see however that I will have to develop my own source html
arrangement and I suspect that selfishly it will be simply so that I can
come back at some etage to the html and easily understand what I have
done :-).

BTW I have enjoyed trawling through your site, in particular your page
on retirement where the quote:

"Free at last, free at last. God Almighty, I'm free at last."

caught my attention, I hope to be retired in 10 years or so and I look
forward to this feeling.

Andrew
--
http://www.andrews-corner.org

[andrew]

On 2008-07-08, David E. Ross <no****@nowhere.notwrote:

I was a software programmer and engineer for 40+ years. Software that I
wrote was formatted (within the constraints imposed by the compilers) to
improve readability and logical analysis. This included indentations,
etc. As I indicated in a slightly earlier reply, I do not do this with
my manually composed source HTML; instead, I only use blank lines to set
off sections.

Thanks for your reply, and others. My own html is written with Bluefish,
a Linux program which shows only a code view but has tag completion,
allows automatic indentation, has a little 'preview in browser, button
etc. I can see however that I will have to develop my own source html
arrangement and I suspect that selfishly it will be simply so that I can
come back at some etage to the html and easily understand what I have
done :-).

BTW I have enjoyed trawling through your site, in particular your page
on retirement where the quote:

"Free at last, free at last. God Almighty, I'm free at last."

caught my attention, I hope to be retired in 10 years or so and I look
forward to this feeling.

Andrew
--
http://www.andrews-corner.org

[Ben C]

On 2008-07-08, David E. Ross <no****@nowhere.notwrote:

On 7/8/2008 12:25 AM, Ben C wrote:

>On 2008-07-08, andrew <an****@ilium.invalidwrote:

>>Hi,

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Yes, about 80 columns.

In many ways your system is more logical-- let the editor wrap it to
whatever the user wants. "Fluid text editing" you might call it.

But people have got used to line breaks about every 80 columns and lots
of programs work better with it. For example in the vim editor you
usually move up or down one (real) line at a time with the j and k keys.

80-character lines (and 72-character lines cited by Little) are
anachronisms.

Although this is true (and you give a good account of the history), 80
columns is still a fairly nice readable width for most things.

On today's wide monitors you can fit two or three columns side by side
if everything is 80 columns. This is perfect for using graphical diff
and three-way merge tools.

[Blinky the Shark]

Ben C wrote:

On 2008-07-08, David E. Ross <no****@nowhere.notwrote:

>On 7/8/2008 12:25 AM, Ben C wrote:

>>On 2008-07-08, andrew <an****@ilium.invalidwrote:
Hi,

I have been taken to task about the length of lines in the source html
of:

http://www.slrn.sourceforge.org

which, as I commonly do, has no line breaks at all in the source html.
My editor wraps the code for me when I view it or work with it.

Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Yes, about 80 columns.

In many ways your system is more logical-- let the editor wrap it to
whatever the user wants. "Fluid text editing" you might call it.

But people have got used to line breaks about every 80 columns and lots
of programs work better with it. For example in the vim editor you
usually move up or down one (real) line at a time with the j and k keys.

80-character lines (and 72-character lines cited by Little) are
anachronisms.

Although this is true (and you give a good account of the history), 80
columns is still a fairly nice readable width for most things.

I don't have any links to hand, but there have been studies that show that
long lines aren't as easily scanned by human readers. I don't remember
the figures in the tests, but I'm sure the optimal width was not "as much
as you can get at full-screen on your new 24-inch monitor". :)
--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Need a new news feed? http://blinkynet.net/comp/newfeed.html

[Ben Bacarisse]

"David E. Ross" <no****@nowhere.notwrites:

80-character lines (and 72-character lines cited by Little) are
anachronisms.

The IBM punched card was 80 characters wide. Since programs were
keypunched into such cards, any statement that was longer had to be
broken onto two or more cards.

Early IBM computers (40-50 years ago) used fixed-length words (not
bytes) of 36-bits each. With 6-bit BCD coding (not the 8-bit (single
byte) or 16-bit (double byte) coding used today), a word could contain 6
characters.

I think your history is a bit off. IBM introduced the 80-column card
format in the 20s -- long before computers. The IBM machines of 40
years ago used 8-bit characters and 32 bit words (the 360 series).
Those of 50 years ago (the 1400 series) did not have a fixed word
length -- a word could be anything from 1 to 8 characters. These
characters were stored using 8 bits, although the encoding needed only
six.

There were computers with 36-bit words and 6-bit bytes (CDCs for
example) but they did not influence the design of the 80-column card
(as far as I know) which was fixed by tabulating machines many decades
earlier.

(Yes, I know don't say that the 80-column card is contemporaneous with
early computers but you do seem to suggest a connection to early
machine word and character sizes.)

--
Ben.

[Ben Bacarisse]

Darin McGrew <mc****@stanfordalumni.orgwrites:

andrew <an****@ilium.invalidwrites:

>>Is it common practice to break the code into screen wide chunks so that
those who wish to view the source html can do it conveniently?

Ben Bacarisse <be********@bsb.me.ukwrote:

>I always do, but I do it is not primarily for viewing, but for other
tools that are line-based. For example, you get shorter listings from
diff if the lines are shorter and many editors are line oriented.

To help diff, version control systems, merge tools, etc., you should also
avoid arbitrarily rearranging the line breaks when you edit files.

That's a good point. It invalidates my suggestion of turning on one's
editor's paragraph re-flow option. That would keep those that want to
see line breaks happy, but it goes against my purported goal. Needless
to say, I don't actually do that (since I like minimal diffs).

--
Ben.

[David E. Ross]

On 7/9/2008 4:46 PM, Ben Bacarisse wrote:

"David E. Ross" <no****@nowhere.notwrites:

>80-character lines (and 72-character lines cited by Little) are
anachronisms.

The IBM punched card was 80 characters wide. Since programs were
keypunched into such cards, any statement that was longer had to be
broken onto two or more cards.

Early IBM computers (40-50 years ago) used fixed-length words (not
bytes) of 36-bits each. With 6-bit BCD coding (not the 8-bit (single
byte) or 16-bit (double byte) coding used today), a word could contain 6
characters.

I think your history is a bit off. IBM introduced the 80-column card
format in the 20s -- long before computers. The IBM machines of 40
years ago used 8-bit characters and 32 bit words (the 360 series).
Those of 50 years ago (the 1400 series) did not have a fixed word
length -- a word could be anything from 1 to 8 characters. These
characters were stored using 8 bits, although the encoding needed only
six.

There were computers with 36-bit words and 6-bit bytes (CDCs for
example) but they did not influence the design of the 80-column card
(as far as I know) which was fixed by tabulating machines many decades
earlier.

(Yes, I know don't say that the 80-column card is contemporaneous with
early computers but you do seem to suggest a connection to early
machine word and character sizes.)

The IBM 700 series (709, 7040, 7090, 7094, etc) were all based on 36-bit
words with 6-bit characters. These preceded the IBM 360.

I was already an experienced programmer when IBM announced Series 360.
Indeed, I was at the Los Angeles announcement of that "full circle of
computing" (the origin of 360 as the series number). I remember
remarking that the "photos" of the components appeared to be nothing
more than cardboard boxes.

The IBM 360 was presented at a morning meeting where IBM served coffee
and Danish coffe cakes. That was the same year that Olivetti presented
its programmable calculator, which looked like a very large adding
machine. Olivetti's presentation was in the late afternoon; hot and
cold appetizers, wine, and liquor were served. At that time, IBM still
had a strict rule against corporate funds being spent on alcohol. (That
rule was changed some time after U.S. Ambassador Watson -- a brother of
the IBM CEO and a son of IBM's previous CEO Thomas Watson -- was
falling-down drunk on a trans-Atlantic flight from France.)

I never said that the 80-column card influenced the design of electronic
computers. However, the use of 80-column cards did influence the design
of higher level programming languages used on those computers since the
programs and data were entered into the computers from punched cards.
The compiled binary programs were then punched out onto cards.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

[Ben Bacarisse]

"David E. Ross" <no****@nowhere.notwrites:

On 7/9/2008 4:46 PM, Ben Bacarisse wrote:

>"David E. Ross" <no****@nowhere.notwrites:

<snip>

>>Early IBM computers (40-50 years ago) used fixed-length words (not
bytes) of 36-bits each. With 6-bit BCD coding (not the 8-bit (single
byte) or 16-bit (double byte) coding used today), a word could contain 6
characters.

I think your history is a bit off. IBM introduced the 80-column card
format in the 20s -- long before computers. The IBM machines of 40
years ago used 8-bit characters and 32 bit words (the 360 series).
Those of 50 years ago (the 1400 series) did not have a fixed word
length -- a word could be anything from 1 to 8 characters. These
characters were stored using 8 bits, although the encoding needed only
six.

<snip>

The IBM 700 series (709, 7040, 7090, 7094, etc) were all based on 36-bit
words with 6-bit characters. These preceded the IBM 360.

Ah, right. I did not know IBM's 18/36 bit period extended into your
given time frame. It does.

<snip>

I never said that the 80-column card influenced the design of electronic
computers. However, the use of 80-column cards did influence the design
of higher level programming languages used on those computers since the
programs and data were entered into the computers from punched
cards.

I think the influence was weak except for FORTRAN. Other languages
from the time (that I can think of) show no sign of 80-column-itis.

--
Ben.

[David Stone]

In article <pa****************************@thurston.blinkynet .net>,
Blinky the Shark <no*****@box.invalidwrote:

Ben C wrote:

On 2008-07-08, David E. Ross <no****@nowhere.notwrote:

[snip]

>
80-character lines (and 72-character lines cited by Little) are
anachronisms.

Although this is true (and you give a good account of the history), 80
columns is still a fairly nice readable width for most things.

I don't have any links to hand, but there have been studies that show that
long lines aren't as easily scanned by human readers. I don't remember
the figures in the tests, but I'm sure the optimal width was not "as much
as you can get at full-screen on your new 24-inch monitor". :)

.... in a 12px font

(into the wind, uphill, both ways? ;)