Re: HEADS UP: Website Overhaul

[Gary Thorpe <gathorpe79@xxxxxxxxx>]

d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <404F8974.9060502@xxxxxxxxx> <404fd656$0$181$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 170
NNTP-Posting-Host: 149.99.115.140
X-Trace: 1078978115 crater_reader.dragonflybsd.org 184 149.99.115.140
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:4215

David Cuthbert wrote:

> Gary Thorpe wrote:
> 
>> How about paragraphs and subheadings? Unless it is tabular data, it 
>> should not be tabularized. The only reason people do it is to get a 
>> magazine-like side list os links: its too bad a web page isn't a 
>> magazine.
> 
> 
> Ugh.  Without an enclosing table, every web browser on my systems will
> render the page at 200-300 characters across each line.  Completely
> unreadable.


Change the font settings for your browsers then. What is certain is that 
you cannot predict (or even determine reliably and adjust) the client's 
screen-size/resolution. There is no arguing this.

> 
> Dave Cuthert wrote:
> 
>>> Easier to keep the document separate from HTML completely and 
>>> preprocess it, bypassing buggy CSS implementations completely.
>>
>>
>> You are ignoring the time spent developing the scripts in PERL or 
>> whatever that will have to do this preprocessing as well as increased 
>> time to serve the page, increased server load/memory/disk/cpu, 
>> increased network load due to larger documents, and increased 
>> rendering time for the client (things like lynx can just ignore 
>> stylsheets taht are not embedded in the document an not even fetch them).
> 
> 
> You're ignoring the time spent debugging buggy CSS implementations.  I
> can rat off a Tcl or Python script in minutes.  The last time I used
> CSS, I spent hours trying to "fix" it.


If it doesn't work just don't use it. It is after all just "style": the 
content will still be there right?


> 
> And preprocessing imposes no server load.  I preprocess the page once,
> store the html file on the server.  Keep the original content and the
> script in CVS.  Voila!


Of course there is server load: storage for scripts and original 
content, prcoessing to filter this original content each time it changes 
etc. The server load is not imposed _each_ time the page is accessed, 
but I never said it did, did I?

> 
>>> Yeah, but manually inserting tabs/spaces becomes almost WYSIWYG in 
>>> emacs. :-)
>>
>>
>> WYSIWIG sucks. Thats why latex is still used widely for 
>> articles/papers and not MS-Word.
> 
> 
> Only in CS journals.  LaTeX never caught on much in the IEEE community.


Whoopie! Guess which communities articles are rated as being more 
valuable in terms of citations? Regardless of the answer to the 
question, its not relevant. How can you tell if LaTex caught on in IEEE 
or not though?

And more to the point: which community has the better quality of 
articles? What do you think is the main factor in this?

> 
> For IEEE, we usually use FrameMaker.  Though I had to use Word for my
> latest paper (because my collaborators didn't have Frame).  Ouch.  I had
> a hard time believing it, but Word XP is *worse* than Word 2000 at
> handling figures.


Yes, when I can plunk down several thousand dollars for Framemaker, I am 
sure I will use it too! So much for free software.

> 
> WYSIWYG only "sucks" if you misuse it, i.e., apply explicit formatting
> instead of styles.


Isn't that what WYSIWYG is???

> 
>> How about...using paragraphs, lists, blockquotes, etc? They are 
>> directly defined in HTML for your convenience.
> 
> 
> Heh... so are tables and frames, to fix the rendering problems with
> plain old paragraphs, etc.


Tables are for...tables. Frames are deprecated and they really annoyed 
me anyway.

> 
> I suppose I could reduce my screen resolution to 640x480, but I'll pass,
> thanks.  (hugs his Xinerama setup at 2880x1024...)


Yes, but will your content look the same on my monitor?

> 
>> You got a readable layout yes, but what happens when you add to it?
> 
> 
> I'll let emacs' M-x auto-fill-mode fix the word wrap, and with the pre
> tags, I'll be done in under 2 minutes.


Emacs itslef is bloated: why does a text editor need 10+ MB of memory 
when running? I suppose it's the golden rule of computing: why use less 
when you can use more? Really, this is what the trend in web design is 
about I think.

> 
>> Oh, and trying to control how it renders is pointless as you have 
>> realized, so why bother trying to in the first place?
> 
> 
> I thought gopher lost out to HTML+HTTP?


Yes, it did. Why is that relevant? You cannot control the client's 
rendering of HTML. All that a proper client can say is that it will 
recognize the content and do _something_ wih it before presenting it to 
the user.

> 
>> And what is readable for you, may not be for everyone else, especially 
>> if they use some tool to automatically convert your page into another 
>> format (think text-to-speech). In these cases, a logical use of markup 
>> will probably be much better.
> 
> 
> What on that page could possibly be improved for text-to-speech?  Or a
> braille reader?


It has no logical structure! The program cannot infer anything from the 
page on its meaning or purpose. Would you write an essay or even an 
advertisement without any structure?

> 
>>> And it's viewable in lynx, too!  Heck, it almost looks the same in 
>>> lynx as Mozilla!
>>
>>
>> Do you think you can try the many different web browsers to check how 
>> it "looks"?
> 
> 
> If a browser can't render <pre> text, I neither care nor want to hear
> about it.


I was not talking about that specific page, but the practice of using 
client testing to make sure the "look" is preserved in general.

> 
> Dave