length limits in lines of code?

[The Bicycling Guitarist]

I found some essays online recommending sixty to eighty characters line
length for content on the screen, but what about in the (X)HTML code itself?

One place said its parser would have trouble with more than 512 Latin
characters in a line (sounds like a long conga huh?). That same site said
that "<a " and "href" should be together, that is, nothing between them, and
that the entire <a></a> should be on the same line. That can get rather long
if the attributes have long contents.

I like to indent lists, etc. to make editing easier. A wise man told me to
use tabs instead of spaces to reduce the file size of the whitespace.

Any input on this subject is gratefully appreciated.
Thanks
Chris Watson a.k.a. "The Bicycling Guitarist"

 

[rf]

The Bicycling Guitarist wrote

I found some essays online recommending sixty to eighty characters line
length for content on the screen, but what about in the (X)HTML code

itself?

Irrelevant. It is what *you* are happy looking at in your editor.

Sometimes I use wordpad as an editor. It wraps lines on its display so I
never get a horizontal scroll bar but it does not wrap them physically. On
looking at the file with, say, notepad with wrap off the "lines" are
thousands of bytes long. I've never come across a browser that got cranky
with this.

All whitespace (read carriage returns) in the code will be removed before it
is formatted on the browser canvas anyway so the browser doesn't care and
that is the only thing you have to worry about.

One place said its parser would have trouble with more than 512 Latin
characters in a line (sounds like a long conga huh?).

Which place was that? Sounds like whoever programmed that parser is getting
the source in chunks of "line" with a rediculously small bufffer, whereas it
should be obtained in chunks of "token", or at least that is how I write
parsers.

That same site said
that "<a " and "href" should be together,
that is, nothing between them, and

Never heard of that before. I wonder why?

that the entire <a></a> should be on the same line.

There is some little truth in this. If the only thing you have inside that
<a> element is an image then if you do this:
<a>
<img>
</a>
then a certain browser will mistakenly parse the newline as whitespace,
causing the image to have, well, whitespace after it. This may be
undesirable. <aside> that Tidy thing "cleans up" the source so it looks like
the above. After once labouriously putting all my </a>'s back on the same
line as the <img>'s (so this bug didn't stuff up the layout) I immediately
deleted Tidy. </aside>

Every recommendation I have ever seen suggests putting the newlines *inside*
the tags, not within the content of the element, as above. This would result
in
<a href=... ... ...
....><img></a>

I don't see why your information source would suggest putting the entire a
element on one line, expecially as that might make the line too long for
their parser See some inconsistance in your information source?

I like to indent lists, etc. to make editing easier. A wise man told me to
use tabs instead of spaces to reduce the file size of the whitespace.

Use whatever you like. If tabs work for you and, more importantly, if they
work for you in all your editors then fine. If tabs don't works for you then
use spaces.

As to the file size: how many li's do you have? 10?. Lets put 4 spaces in
front of each. 30 bytes of wasted space (over and above using a tab).

Now, how big is that image of you precariously perched on a bicycle playing
a guitar? A *lot* more that 30 bytes. The extra whitespace is so small,
relative to the entire page, as to be insignificant.

 

[Neal]

I found some essays online recommending sixty to eighty characters line
length for content on the screen, but what about in the (X)HTML code
itself?

For practicality, I keep block elements with a lot of content on their own
line. I don't keep a character count.

Generally, if it's cumbersome for you as a human, it's close to cumbersome
for any technology which has to deal with the code.

 

[Big Bill]

The Bicycling Guitarist wrote

itself?

Irrelevant. It is what *you* are happy looking at in your editor.

Sometimes I use wordpad as an editor. It wraps lines on its display so I
never get a horizontal scroll bar but it does not wrap them physically. On
looking at the file with, say, notepad with wrap off the "lines" are
thousands of bytes long. I've never come across a browser that got cranky
with this.

No, but eyeballs do. Hence wrapping at 60/80 characters. I think
thwt's what Chris unknowingly is referring to.

There is some little truth in this. If the only thing you have inside that
<a> element is an image then if you do this:
<a>
<img>
</a>
then a certain browser will mistakenly parse the newline as whitespace,
causing the image to have, well, whitespace after it. This may be
undesirable. <aside> that Tidy thing "cleans up" the source so it looks like
the above. After once labouriously putting all my </a>'s back on the same
line as the <img>'s (so this bug didn't stuff up the layout) I immediately
deleted Tidy. </aside>

It's very useful, Tidy. Don't forget it's Dave Raggett.

Every recommendation I have ever seen suggests putting the newlines *inside*
the tags, not within the content of the element, as above. This would result
in
<a href=... ... ...
...><img></a>

I don't see why your information source would suggest putting the entire a
element on one line, expecially as that might make the line too long for
their parser See some inconsistance in your information source?

I've found circumstances where links, although properly formatted
syntax-wise, simply don't work. Typically they'd be something like

<a href=
"blah.htm">text</a>

or busted up in a similar fashion. Rejig the surroundings so you have
all teh a stuff on the same line and presto! link works. You ever seen
my Amazon pages? Line after line of tables with links in cells. I used
to get that problem all the time when I did them.

God it's such a drag when I have to schlep over to this group and
explain to you guys how things is.......tee-hee....

BB
www.kruse.co.uk
The home of SEO that's shiny!

 

[The Bicycling Guitarist]

No, but eyeballs do. Hence wrapping at 60/80 characters. I think
thwt's what Chris unknowingly is referring to.

Unknowingly? If line is too long, eyes have trouble finding the next line.
If too short, eyes must go back and forth often.

It's very useful, Tidy. Don't forget it's Dave Raggett.

It is a bit tedious to redo all the links. I still use Tidy though.

I've found circumstances where links, although properly formatted
syntax-wise, simply don't work. Typically they'd be something like

<a href=
"blah.htm">text</a>

No links like that on my site, Bill. Tidy did put most of them the way
Richard showed. Tidy did wonders for me when I was converting my old pages
and learning what I know so far. Now I usually use an existing page as a
template for new pages.

God it's such a drag when I have to schlep over to this group and
explain to you guys how things is.......tee-hee....

BB
www.kruse.co.uk

Thank you.
TBG

 

[hyweljenkins]

For practicality, I keep block elements with a lot of content on their own
line. I don't keep a character count.

Generally, if it's cumbersome for you as a human, it's close to cumbersome
for any technology which has to deal with the code.

Eh? How d'you figure that? Technology does things we find difficult
quite easily. It's the things we find easy that technology struggles
with.

 

[Karl Core]

Unknowingly? If line is too long, eyes have trouble finding the next line.
If too short, eyes must go back and forth often.

This is a falsehood.
Usability studies show that a line-length of roughly 10 inches is OK for
reading performance.
The issue is human preference. People prefer shorter lines of text.

Its one of those things in usability where actual performance is different
from preference. It only "feels" difficult, when in fact, people can read &
understand moderately long lines of text just fine.

-Karl

 

[rf]

Karl Core

[line length]

Woowoo guys you have lost the plot.

The original post stated up front that *for the viewer* a certain line
length is appropriate. True. Nobody will argue.

The OP, Mr Watson, upon his velocipede, is querying "what is the accepted
line length *in the HTML source file*".

Nothing to do with viewers. All to do with the author. Or the browser. Or
the bot.

Right?

Now, get a grip.

 

[Michael Fesser]

.oO(Big Bill)

I've found circumstances where links, although properly formatted
syntax-wise, simply don't work. Typically they'd be something like

<a href=
"blah.htm">text</a>

What broken user agent ignores links like the above?

Micha

 

[Big Bill]

Eh? How d'you figure that? Technology does things we find difficult
quite easily. It's the things we find easy that technology struggles
with.

How does technology pronounce "Hywel"?

BB (pronounced bee-bee)
www.kruse.co.uk
The home of SEO that's shiny!

 

[Big Bill]

.oO(Big Bill)


What broken user agent ignores links like the above?

Micha

I forget what I used in those days, maybe Netscape 4 or a mite
earlier.

BB
www.kruse.co.uk
The home of SEO that's shiny!

 

[Neal]

Eh? How d'you figure that? Technology does things we find difficult
quite easily. It's the things we find easy that technology struggles
with.

Just that if any tech has a limitation, it's beyond what you as a human
can deal with. I worded that poorly.

Basically, if you can deal with the line lengths as a human, so can the
technology.

 

[rf]

I forget what I used in those days, maybe Netscape 4 or a mite
earlier.

Who bloody cares then?

 

[Joel Shepherd]

I found some essays online recommending sixty to eighty characters line
length for content on the screen, but what about in the (X)HTML code itself?

Recommendations like that are worth observing if you're writing code
that others may need to edit later, as they help prevent ugly wrapping
problems in most text-editing environments.

One place said its parser would have trouble with more than 512 Latin
characters in a line (sounds like a long conga huh?).

I'd look for another parser.

I like to indent lists, etc. to make editing easier. A wise man told me to
use tabs instead of spaces to reduce the file size of the whitespace.

Did the wise man consider how many tabs would be needed to reduce the
overall page size as much as intelligently optimizing images? Given the
various compression schemes around, I really would worry about using tab
characters instead of 2-4 spaces.

--
Joel.

http://www.cv6.org/
"May she also say with just pride:
I have done the State some service."