Brion Vibber <brion(a)pobox.com> writes:
As I recall, the primary argument against anchors is
that they support
and encourage long pages.
Very long pages are bad, but pages up to 20 or 30 KB are perfectly okay
and there fragment links (#fragment) are very useful. Short articles
suffering from the fact that they are often nothing more than a list of
pointers to other articles (internal and external) ;)
Also they are to easy to edit. Thus poeple always add stupid lists
of terms and names to short articles ;-)
(And of course, very long pages can run afoul of
browser limitations,
making it impossible for some people to edit them.)
What's a very long article? We should encourage people to go for proper
editors. I'll evaluate Emacs solutions the next weeks. Any advice?
The preferred solution is to break up long articles
into smaller, more
self-contained blocks.
I simply disagree :) Short page maybe easy to edit (caveat, see above)
and they are a pain to read. Esp. when Internet connection isn't that
good. Even here in Germany at certain times it can happen that I must
more than 30-45 seconds for an article. Bandwidth here isn't the
problem.
Anchors, of course, would potentially simplify
internal navigation --
for readers only. When it comes time to change a small paragraph in the
middle of a 25kb article through a tiny textarea in a web page, you
gotta do a lot of scrolling. Short pages are much easier to work with,
and as a wiki project that's committed to being read-write, editing ease
is of great importance to us.
Yes, but 25kb articles are perfectly okay. I'd say the barrier should
be something like 30-50kb, depending on pictures includes etc. One
should judge form case to case.
--
ke(a)suse.de (work) / keichwa(a)gmx.net (home): |
http://www.gnu.franken.de/ke/ | ,__o
Free Translation Project: | _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)