Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
k5 needs a diet?

By nuntius in Meta
Sun Jan 21, 2001 at 11:13:56 PM EST
Tags: Kuro5hin.org (all tags)
Kuro5hin.org

Has anyone else looked at the HTML source for k5 lately? Nontraditional HTML constructs are being heavily used for visual effect. These constructs and some redundant tags are increasing page sizes by approximately 16k/page.

Does the visual appearance justify the added weight, or should k5 return to simpler formatting techniques for a slimmer figure?


Take the "OSDN Navbar", for example. Note the redundant font tags being used. Each phrase like "Linux.com" or "My OSDN" has its own enclosing tags, as do the ·'s between the phrases.

Each pair of these tags is 83 characters long, and they are repeated 15 times for a nifty 1245 characters per page. Assuming 1 byte/char, that's 1k blown just formatting the blue bar. Additionally, CSS tags for each of the phrases specify the exact same text attributes.

Moving on to the navbar (having "Everything", "Freedom & Politics", etc.), notice the use of background images to build the table. This looks sharp, but comes at the price of another 4k of HTML code.

Marching down we find that small .gif's are used instead of font-based bullets. Again pretty, but this uses another 85 chars/bullet. The frontpage has ~100 bullets on it. Added cost: another 8k.

I could go on, but I feel my point is clear. Assuming there's 16k/per page of HTML simply being used to make k5 go from 'good' to 'sharp', I halfway want to retract my earlier vote of "Love It!" on the design poll.

On the campus ethernet, these pages still don't take long to load. However, 2k/second is the average rate at my home--meaning it takes 8 seconds just to download the extra formatting for any given page. Not to mention the extra time taken to render the pages.

Am I over-reacting, or does the HTML code need to go on a diet? Either way, this seemed like an issue that needed to be addressed. Is anyone bothered by lengthened loading times?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
HTML code status:
o bloated 69%
o not an issue 19%
o necessary evil 6%
o clearly unobfuscated 4%

Votes: 135
Results | Other Polls

Related Links
o Also by nuntius


Display: Sort:
k5 needs a diet? | 87 comments (84 topical, 3 editorial, 0 hidden)
Font tags, etc. (4.07 / 14) (#1)
by J'raxis on Sun Jan 21, 2001 at 09:11:34 PM EST

Font tags are evil and should be stricken from the web.

I posted something to my diary about the HTML and forgot about it; glad someone else feels the same about bad HTML.

The solution is simple HTML (XHTML/1.0 actually) and a stylesheet to accompany it. The only "bad" HTML that might be needed is a table to produce the three-column layout. Other than that, everything could be done with normal tags, with only maybe a few special classes needed.

Once more, font tag delenda est.

-- The XHTML/1.0 Raxis

[ J’raxis·Com | Liberty in your lifetime ]

A Font of Wisdom (4.83 / 6) (#13)
by Monster on Sun Jan 21, 2001 at 11:46:00 PM EST

The solution is simple HTML (XHTML/1.0 actually) and a stylesheet to accompany it.
Absolutely. HTML is not supposed to be about appearance, but about logical structure. I don't give a rat's rump what my pages look like on a non-CSS-compliant browser, because the person viewing the page clearly doesn't. If they did care about my opinion of the page's appearance, they'd be using a different browser. Mind you, they may have damned good reasons not to care, such as visual impairment, that requires their own styles to override, or even text-to-speech/braille/etc. But for whatever reason, they don't care, so it'd be silly for me to spend effort and ASCII trying to shove it down their throats.

But I'm old-school: I don't care much for client-side scripting, plug-ins, or any other forks.

SVM, ERGO MONSTRO
[ Parent ]

[rant] Fonts (4.66 / 6) (#31)
by swr on Mon Jan 22, 2001 at 05:38:38 AM EST

I have to agree that font tags are at best a waste of bandwidth.

I run X at a resolution of 1280x960 on a 17 inch monitor. This is a slightly high resolution for "only" 17 inches, so I set font sizes fairly large in my browser to keep things readable.

With Mozilla 0.7, most sites are pretty readable. All of the fonts on K5 are the same Helvetica except for the buttons and pulldowns which appear as Times. So basicly, all of the font tags that are on the page are nothing more than a waste of space.

When I was using NS 4.76 the situation was much worse. A lot of sites set font sizes that were just too small, even though I had set "always use my fonts" in the Netscape preferences. Even with Mozilla, some sites manage to force the small fonts down my optic nerves. Worse, with Mozilla setting "always use my fonts" causes some sites (including K5) to be rendered with the correct face but at a smaller size. Ugh!

Another thing: Why are web designers so fascinated with Helvetica? Sure it looks neat and clean and high-tech compared to old-fasioned Times, but serifs make text easier to read. That's why most printed material uses Times. Must people ignore hundreds of years of refinement "just because"?

And why does K5 go to the trouble of overriding the font settings in the browser's preferences only to provide a font selection on their preferences page? Does anybody really think users are going to want to mix and match fonts all over the page? It's text! Stop playing with it and READ (or WRITE) it!

Web designers: I set my browser to use 24-point Times. Leave it there or I'll send you the bill for my next pair of glasses.



[ Parent ]
Killing tags the Mozilla way (4.33 / 6) (#47)
by YellowBook on Mon Jan 22, 2001 at 09:56:40 AM EST

If you want to kill font tags totally, you can, in Mozilla, and presumably any other browser that supports user stylesheets. In Mozilla on Unix, your user stylesheet is $HOME/.mozilla/default/chrome/userContent.css, elsewhere YMMV. Here's the stuff to stick in your stylesheet:

FONT {font-family: inherit !important;
  font-size: inherit !important;
  color: inherit !important;
  }

You may want to take the !important off the color: setting, since it may make some text unreadable (where font tags are used to set a foreground and the background has been set to a noncontrasting color in a table cell or somewhere).

This solution is more effective than the "always use my fonts" setting in Netscape/Mozilla. Pages can still change the font using CSS; you may want to repeat that section, replacing FONT on the first line with *, which will prevent any web page from changing your fonts ever.

This has been a message from the Union of CSS Anarchists.



[ Parent ]

The wonders of CSS (4.50 / 2) (#57)
by swr on Mon Jan 22, 2001 at 08:33:36 PM EST

Nice try... The CSS you've provided does force the font sizes to be bigger, but Mozilla doesn't allocate more space for them, causing lines of text to overlap. Very ugly.

I've got a bug report in about the "always use my fonts" checkbox not working 100%, and it looks like the Mozilla developers on it.

BTW, is there some similarly simple CSS to move scrollbars to the left? Since I first heard about Mozilla's design I figured it would be easy to do but I have no idea where to start.



[ Parent ]
YMMV (3.00 / 2) (#59)
by YellowBook on Mon Jan 22, 2001 at 09:45:54 PM EST

Nice try... The CSS you've provided does force the font sizes to be bigger, but Mozilla doesn't allocate more space for them, causing lines of text to overlap. Very ugly.

Not for me it doesn't -- maybe you have some other CSS that's competing with it and causing that effect? For me (Moz nightly build 2001011811) it looks very nice. Of course, I don't have my font size set to "huge", either, so that may be the difference.

BTW, is there some similarly simple CSS to move scrollbars to the left?

I think that's something that would have to be done in a skin; I don't think it can be done in a user stylesheet. I'm sure anyone who groked XUL (I don't) could make the change to an existing skin pretty easily.



[ Parent ]
correction (but YMMV) (4.00 / 1) (#61)
by FunkyChild on Tue Jan 23, 2001 at 12:36:36 AM EST

serifs make text easier to read. That's why most printed material uses Times.

The reason that most printed material uses Times or a similar serif font it that yes, in print, serif fonts are easier to read. The serifs tend to lead the eye from one letter to the next.

However, on screen it's quite a different story. It is very widely accepted that sans-serif fonts are much easier to read. If you have a grid of, for example, 14 x 14 pixels in which to construct a character, the serifs do much more harm than good, by cluttering up the very limited space. In print, a serif may well be 1/5th of the thickness of the stem of the letter, but serifs on screen (at average for the web sizes) usually are the same thickness as the stem - i.e. one pixel.

The Microsoft web fonts are quite good in this regard (search for typography or something at their website). They are designed with large X-heights with easy to recognise shapes when viewed on screen.

Once we are all using 300dpi displays running at some wicked resolution, this will change, but for now, that is the reason. Even noticed that subtitles and TV credits are (almost always) sans-serif? It's the same reason.

Of course if you choose to use 24pt Times (blech!), you're very free to, and it would be nice for web deisgners to let you to. However, people don't use sans-serif fonts on the web "just because".


-- Today is the tomorrow that you worried about yesterday. And now, you know why.
[ Parent ]
[rant] Fonts (2.77 / 9) (#33)
by swr on Mon Jan 22, 2001 at 05:41:29 AM EST

I have to agree that font tags are at best a waste of bandwidth.

I run X at a resolution of 1280x960 on a 17 inch monitor. This is a slightly high resolution for "only" 17 inches, so I set font sizes fairly large in my browser to keep things readable.

With Mozilla 0.7, most sites are pretty readable. All of the fonts on K5 are the same Helvetica except for the buttons and pulldowns which appear as Times. So basicly, all of the font tags that are on the page are nothing more than a waste of space.

When I was using NS 4.76 the situation was much worse. A lot of sites set font sizes that were just too small, even though I had set "always use my fonts" in the Netscape preferences. Even with Mozilla, some sites manage to force the small fonts down my optic nerves. Worse, with Mozilla setting "always use my fonts" causes some sites (including K5) to be rendered with the correct face but at a smaller size. Ugh!

Another thing: Why are web designers so fascinated with Helvetica? Sure it looks neat and clean and high-tech compared to old-fasioned Times, but serifs make text easier to read. That's why most printed material uses Times. Must people ignore hundreds of years of refinement "just because"?

And why does K5 go to the trouble of overriding the font settings in the browser's preferences only to provide a font selection on their preferences page? Does anybody really think users are going to want to mix and match fonts all over the page? It's text! Stop playing with it and READ (or WRITE) it!

Web designers: I set my browser to use 24-point Times. Leave it there or I'll send you the bill for my next pair of glasses.



[ Parent ]
serifs make text easier to read (4.00 / 2) (#49)
by jokerbone on Mon Jan 22, 2001 at 01:48:52 PM EST

As a designer I simply must quibble with this... In the world of print, it is true that serifs aid the eye in reading text by acting as an arrow to the next letter in the same line. This effectively keeps most readers from having to "follow with their fingers"... The same is -not- true of screen fonts where resolution is an issue. Instead of arguing the point, I'd rather refer interested parties to these resources: These are just a few links google dug up - that last one has a rather good interview with the designer of both Verdana and Georgia. Designers make desicions regarding this type of thing for a reason! :) Unfortunately, most don't write validating HTML or care that they can't - which is where the true problem lies.

[ Parent ]
Font tags/CSS (4.00 / 1) (#58)
by bigelephant on Mon Jan 22, 2001 at 08:59:07 PM EST

Who said you have to use <font> in the first place? CSS should be used instead. And with CSS, you can actually make the page scale down gracefully. If you are concerned that the user with some ghetto version of their browser won't be able to see all your pretty fonts, forget it. If they choose to use an outdated browser, they probably don't like all the new stuff like fonts, etc. Of course, some people don't get to choose what they use, but I don't think that their experience is going to be detrimented significantly if they see plain formatted text. The advantages: the stylesheet can be cached, and all of the style definitions won't have to download all over. You can make some very neat stuff - like not use a single <table> for highlighting and stuff and still have the same results. Also, you can have a bunch of themes and you could maintain scoop much more easily: you don't need to change <font color="black"> to <font color="green"> 20 million times, but just once in the stylesheet. Not to mention that it makes more sense to classify things as a navigation header than a table with a blue background. Besides, if everyone starts using CSS even though the current browsers don't render it so well, they are going to make them better and more compatible. And if everyone doesn't stop using the lame layout tags, browsers will never become 100% CSS-compatible.

[ Parent ]
Light mode (4.18 / 16) (#3)
by xriso on Sun Jan 21, 2001 at 09:14:25 PM EST

Perhaps k5 needs to follow slashdot's lead and have a "light mode" option in the user preferences. It is very applicable for slow connections, and also for browsers that are text-only.
--
*** Quits: xriso:#kuro5hin (Forever)
Good for PDA's as well (4.00 / 3) (#18)
by josh_staiger on Mon Jan 22, 2001 at 12:59:39 AM EST

I definitely agree. A "light" mode would also allow people to more easily read K5 using PDA's with AvantGo and such.

I frequently use Slashdot's "light" mode to download it to my Visor and read it on the go. It is very convenient.

[ Parent ]

Lose an ad/frames? (3.50 / 2) (#23)
by vastor on Mon Jan 22, 2001 at 02:00:37 AM EST

If the ads are 11k each, that adds another few seconds for each one too. Perhaps if the bottom one gets very few hits it might be worth losing it in the light mode too.

Turning the - images into LI's would make things slightly smaller too in the hotlist.

For that matter, a frames version would save lots of duplication too. The top/right hand side could be seperate frames and thus save having them reloaded every time a new page is visited since for the most part they never change.

Lots of people dislike frames, but if it was a purely optional selection and not the default I think it'd probably be a good idea. Though possibly, just a right frame would be the best option as you wouldn't want the ad stuck in the top frame, it'd be better if it was over in the left one.


[ Parent ]
Eeek! (2.62 / 8) (#5)
by Arkady on Sun Jan 21, 2001 at 09:18:26 PM EST

It looks like he's right. I just checked the front page; it's 118,023 bytes (at 2,416 lines). That's a bit over the top. I certainly agree that <FONT> should be stricken, though it's embedded pretty deep into Scoop. It's _not_ necessary, though. Since I don't use a CSS browser (or "XHTML", whatever that is), I'd naturally argue against CSS dependancy. It's quite possible to achive almost this look without all the extraneous stuff. You could probably trim the HTML down by at least 25% without changing the look at all. Mond you, I'm on a dual-DSL connection, so I never noticed this myself. But I remember the days of modems and can sympathize with the 33,6 users out there. -robin

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.


id fix the font tags but keep the bullets (2.80 / 5) (#6)
by zzzeek on Sun Jan 21, 2001 at 10:06:41 PM EST

Assuming your browser uses regular caching of images, the bullet image that uses 83 bytes is cached, so the 83 bytes is 83 bytes no matter how many there are. This goes for the table cell background images as well, so the bandwidth taken up is not so huge. But I agree about the font tags, if there are already CSS's being named then all the font stuff should happen there (CSS usage probably saves space by combining many formating attributes into a single mnemonic). Perhaps it was meant to support browsers that support FONT tags but not CSS. Not too many of those around these days.

Image caching isn't the problem (4.33 / 3) (#9)
by /dev/niall on Sun Jan 21, 2001 at 10:33:58 PM EST

Assuming your browser uses regular caching of images, the bullet image that uses 83 bytes is cached, so the 83 bytes is 83 bytes no matter how many there are.

That's no problem, but each time you see one these bullets it means this:

<IMG SRC="http://209.208.150.46/lidisc.gif" BORDER=0 ALT="o" WIDTH="12" HEIGHT="12">

... is in the html file. That's 84 bytes. The image itself is 74 bytes. I count 91 of these on the homepage, so assuming your browser is caching the image that's 7644 bytes, plus the 74 for the image itself.

Compare that to <li> </li>, which is only 9 bytes. Quite a savings.
--
"compared to the other apes, my genitals are gigantic" -- TheophileEscargot
[ Parent ]

Only 4 bytes (4.00 / 4) (#11)
by fluffy grue on Sun Jan 21, 2001 at 10:46:39 PM EST

The </li> tag is optional. :) It's only necessary in cases where an ambiguity forms, and I can't think of any situation offhand which would cause an ambiguity, at least inside the context of a <ul> or <ol>. Hanging loose it probably does need the </li> though.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Depends on what you mean by optional (3.00 / 1) (#14)
by /dev/niall on Mon Jan 22, 2001 at 12:15:48 AM EST

I dunno... something in me just HAS to make sure all tags are closed. I even stick the closing tag on my images.

<img src="blah.gif" height="11" width="11" border="0" alt="blah" />

Okay, I'm anal. ;)
--
"compared to the other apes, my genitals are gigantic" -- TheophileEscargot
[ Parent ]

Yes, that's anal. (5.00 / 1) (#56)
by fluffy grue on Mon Jan 22, 2001 at 08:28:03 PM EST

nt.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

No, it's not (none / 0) (#71)
by henrik on Tue Jan 23, 2001 at 01:56:07 PM EST

No, it isn't in any way anal.
XML (thus XHTML) mandates that you close all tags - that the document is wellformed for it to be parsed. Sloppyness like not closing your tags (and browsers accepting it) is what caused todays browser hell in the first place. Please don't go around encouraging bad habits

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

Why must all tags be 'closed'? (5.00 / 1) (#75)
by fluffy grue on Tue Jan 23, 2001 at 09:07:04 PM EST

A lot of tags, such as IMG and the like, make absolutely no sense to contain things. Why can't XML specify that close-tags are optional? Also, HTML itself (though not XHTML) specifically states that many of the close tags are - get this - OPTIONAL. It's not XHTML I'm talking about, but HTML. There's a BIG difference - XHTML is, as you are probably aware, a porting of HTML to XML, whereas HTML is simply a specification of SGML, which specifically DOES allow there to be non-closed tags.

The 'browser hell' you refer to is mostly from liberal application of HTML standards where it allows certain tags (such as TABLE) to not be closed even if HTML specifies that they must be. In addition, HTML 1.0 had P as simply a paragraph marker at the end of a paragraph - it was NOT a markup tag to begin with, which is why /P is specified as optional (and for most purposes of P as a markup tag, such as specifying a stylesheet or alignment or the like, you should use DIV instead).

It's anal to apply XHTML's standards to HTML. Although they have similar syntaxes, they are NOT the same thing.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: Why must all tags be 'closed'? (none / 0) (#76)
by henrik on Wed Jan 24, 2001 at 08:14:25 AM EST

Why can't XML specify that close-tags are optional?

The main reason is to keep parsers simple - it's a lot easier to implement a parser when you dont have to worry about possible dangling end tags. the big problem with SGML is it's complexity - XML was designed to make it easy to both use and implement by removing a lot of junk (as i'm sure you already know :)

The 'browser hell' you refer to is mostly from liberal application of HTML standards where it allows certain tags (such as TABLE) to not be closed even if HTML specifies that they must be. In addition, HTML 1.0 had P as simply a paragraph marker at the end of a paragraph - it was NOT a markup tag to begin with, which is why /P is specified as optional (and for most purposes of P as a markup tag, such as specifying a stylesheet or alignment or the like, you should use DIV instead).

As you noticed, HTML wasn't designed, it evolved. Whouldnt it be nice to have a strict standard so that implementing a browser was as easy as following the standard - today you have to not only implement the standard but emulating other browsers rendering bugs *and* support broken code?

As you've pointed out, close tags dont make a lot of sense in HTML (as implemented now) from a practical point of view. But it would be a better world if there'd been a bit less flexibility in HTML from the beginning.. (of course, it's easy to look at this in hindsight and suggest what everybody should have done). And i still maintain that closing tags is a good habit - it'll be useful :)

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

Not in XHTML... (4.00 / 2) (#22)
by meldroc on Mon Jan 22, 2001 at 01:58:12 AM EST

XHTML and other XML based languages require opening and closing tags at all times. This means <li> must have a </li>, <p> must have a </p>, etc. While this seems silly to us humans, this makes life much easier on parser writers, making the standard easier to implement and more uniform.

[ Parent ]
<br /> <li /> <p /> (3.00 / 2) (#27)
by delmoi on Mon Jan 22, 2001 at 03:04:28 AM EST

actualy, you should have a <p></p> pair, but XML does alow 'single elements' in that format.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Breaks in older browsers. (3.50 / 2) (#39)
by Chiron on Mon Jan 22, 2001 at 07:55:17 AM EST

IE4, NS4 and earlier.
WebTV.
Lynx.

All these browsers either react badly to <BR /> or <BR></BR> pairings. Also, you have to watch out for <P></P>, and others.

There is quite a long list of things that have to be done to bamboozle HTML3 and HTML4 browsers into accepting a well-formed XHTML document. To be honest, I would say XML, and server-side XSLT transformations for browsers that can't do it client-side would be the best solution, but that won't be a common method for another year or two.


[ Parent ]
Always worth the effort to 'go small' (4.80 / 20) (#7)
by General_Corto on Sun Jan 21, 2001 at 10:06:42 PM EST

Pages that you've put on a diet are good for everyone, regardless of the speed of your connection (Mr "I don't care, I have a K5 kabal modem" :)

First important item, it means that you shouldn't have to work as hard to make your site available for low-bandwidth users - one site serves all.

Secondly, and far more importantly, since your pages are smaller, your bandwidth usage (as a server of content) is also smaller, which means it either costs you less to host your site, or you can serve more pages given your current bandwidth allowance.

Looking at the front page, MS IE5.01 is reporting to me that it currently stands at 67k (that may not include the images, but I'll work with that number). If you're allowed to serve up to 4Gb a month in traffic, which I currently am, you're looking at serving about 67,000 pages. Which is *very* few indeed, when you consider that there are over 10,000 registered users of the site, and each of them is going to visit many pages each time they come.

I'm currently working on a personal project that has some very similar look and feel to that which is shown at K5, and I've managed to keep things small. Even including quite a bit of flat text, I'm only at 8k for a page, which I'm rather proud of. Of course, I'm using things like CSS to help me in my quest and vision of the site's look, but the important part is to keep the page weight down while keeping it looking cool.


I'm spying on... you!
Nice and plump. (3.50 / 4) (#10)
by Holloway on Sun Jan 21, 2001 at 10:39:25 PM EST

Mostly, it's more a choice to support old browsers than unnecesary bloat (at least for the, erm, bulk of the example you mention).

The top bar with a dark blue background requires light coloured links to be seen. Netscape 3 and older do not support CSS so to change the link colour to a lighter one you do need to put FONT tags inside the A tag. The size could be lowered a little by surrounding the OSDN 'four sites' with a font tag rather than defining it four times. A saving of about 140bytes rather than

The only other thing I have noticed is the overuse of nested tables. But then that's to achieve the same effect in older browsers too.

It would be nice to support a trim version that uses CSS throughout for IE4+/Mozilla, and I've volunteered to do one. Does Scoop support themes though?


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

Not yet but it is in the ToDo list [nt] (2.00 / 1) (#24)
by driph on Mon Jan 22, 2001 at 02:09:07 AM EST

.

--
Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave
[ Parent ]
A simpler solution (4.00 / 1) (#34)
by AndrewH on Mon Jan 22, 2001 at 06:15:59 AM EST

The top bar with a dark blue background requires light coloured links to be seen. Netscape 3 and older do not support CSS so to change the link colour to a lighter one you do need to put FONT tags inside the A tag.

Use CSS for the background as well as the links, so that non-CSS browsers just drop through and keep the contrasting colours.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
But... (3.50 / 2) (#36)
by Holloway on Mon Jan 22, 2001 at 07:29:38 AM EST

...for one theme there is no solution. That's my point.

Defining the background and foreground in CSS wouldn't solve anything as the majority of the bloat is there for a reason: it helps keep the design consistant on browsers.

The only thing HTML/CSS promises is to degrade gracefully - not to be consistant. CSS backgrounds and foregrounds cannot achieve this - HTML bloat can.

The only solution (as many realise) is to make several templates (read: themes) and let people choose a bloat-free version if their browser understands it (or to browser detect - and deliver one of several themes, anyway).


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

Insert Formatting vs Content Rant Here (4.33 / 3) (#40)
by Chiron on Mon Jan 22, 2001 at 08:03:34 AM EST

You've all heard it a thousand times. Nothing to see here. HTML is a content language, not a formatting language. You specify your content, and the browser should do whatever is most appropriate to display it to the user.

(Possibly using your CSS or what-have-you to improve things, because the art-geeks have ruined the code-geeks' paradise. ;) )

[ Parent ]
Yay! (4.00 / 2) (#44)
by Holloway on Mon Jan 22, 2001 at 09:18:02 AM EST

[...and insert form response here ;]

The coming reign of HTML/CSS is mighty tasty. I want it too.

I await that warm day with teary eyes - tears of joy - when I can further remove content from presentation. But it's about three years away, at least.

HTML is a content language, not a formatting language. You specify your content, and the browser should do whatever is most appropriate to display it to the user.

Yes but even the W3c don't walk that talk. They use TABLEs for formatting like the rest of us webmonkeys ;)

...the same goes for K5, Slashdot, Freshmeat, practically every other webpage ever created (even the long standing holdout, GNU.org). 99% of webdesign has always been about doing the best you can with the tools available. Even this thread avoided ideology in lue of functionality (removing bloat).

To 99% of people markup idealogy is something they'll pay lip-service to (and also defend religiously) - but will never use. And I don't just mean the wanker webdesigners that rule 99% of webpages - I also mean people who preach markup idealogy. They're all hypocrites who do the best with the tools they have.

I'm glad the tools are getting better in XHTML and CSS, and it will be nice when I can avoid HTML hacks, but dammit Siegel.. you ruined everything!


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

Actually.. (4.00 / 2) (#54)
by Chiron on Mon Jan 22, 2001 at 06:50:09 PM EST

For my internal sites where I work, I use XML and XSLT.. But it does wind up being HTML4/CSS, because the Company standardized on IE5, and I hate Mickeysoft's MSXML object.

Once you've wrapped your head around seperating content and display, the management of your site can become quite a bit easier.

To be honest, I just posted this to take potshots, and just be generally snide about web designers that don't take pride in their work.

[ Parent ]
You make your bed, and you lie in it (2.50 / 2) (#41)
by AndrewH on Mon Jan 22, 2001 at 08:21:07 AM EST

The only thing HTML/CSS promises is to degrade gracefully - not to be consistant. CSS backgrounds and foregrounds cannot achieve this - HTML bloat can.

If you want websites to come out pretty, go get yourself a browser that renders them prettily. Simple as that.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
What's your point in this thread? (3.00 / 2) (#42)
by Holloway on Mon Jan 22, 2001 at 08:49:58 AM EST

Well, yes, and that's what I said in my initial post.


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]

Yes indeed, but some people want it both ways (3.00 / 2) (#43)
by AndrewH on Mon Jan 22, 2001 at 08:58:23 AM EST

Worse, all too many web designers try to deliver it both ways, usually with bad results.


John Wilkes Booth, Lee Harvey Oswald, John Hinckley Jr — where are you now that we need you?
[ Parent ]
Agreed. (3.00 / 2) (#45)
by Holloway on Mon Jan 22, 2001 at 09:22:24 AM EST

Dear god yes! The webdesigners that don't know how to balance HTML and CSS on public sites should have been still born. The lot of them. ps. Please direct your attention to this branch in which I commit mortal sins.


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]
I love it, but... (3.20 / 5) (#12)
by Seumas on Sun Jan 21, 2001 at 11:24:38 PM EST

I have to say that I love the way Kuro5hin looks. Every design I've ever created on the web is completely inferior to this. The extra bandwidth is absolutely worth it.

That being said, I'm on a 768k/768k DSL connection, so K5 could be one giant streaming video for all I care.

I think that, among other things, there should be an extremely light version of K5. even lighter than Slashdot -- and more attractive. Slashdot's light version is too much of a jumble and would look better if it just did away with everything (font sizes, etc) and just stuck with ASCII and hyperlinks.

Among other things refers to the ability to have a greater selection of how the site is presented to each individual. Something along the lines of perlmonks.org, which does a nice job of allowing you to modify the color scheme (yes, this is important for some of us depending on our monitors, our eyesight and other things) and, to a limited degree, what shows up and where. K5 has the ambition and technical ability to make some very interesting changes as far as user preferences go.
--
I just read K5 for the articles.

The thing is. (3.50 / 2) (#26)
by delmoi on Mon Jan 22, 2001 at 02:57:03 AM EST

Yeh, k5 looks great. I wouldn't say it's the greates development ever, but it does look OK.

the problem the story poster has, and I share is that there is a ton of *redundant* HTML code there. Take a look at the code use just for the words "Newsforge * slashdot * linux.com * sourceforge

    <A CLASS="osdn" HREF="http://www.newsforge.com/"><FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">NEWSFORGEgt;/FONT></A> <FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">·</FONT>
     <A CLASS="osdn" HREF="http://www.linux.com/"><FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">LINUX.COMgt;/FONT></A> <FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">·</FONT>
    <A CLASS="osdn" HREF="http://www.slashdot.org/"><FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">SLASHDOTgt;/FONT> <FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">·>/FONT>
    <A CLASS="osdn" HREF="http://www.sourceforge.net/"><FONT COLOR="#FFFFFF" SIZE="1" FACE="Verdana, arial, helvetica, sans-serif">SOURCEFORGE>/FONT></A>

Now, this could be done with the following HTML for *exactly* the same effect:

<font color=white> <a class="osdn" href=http://newsforge.com>NEWSFORGE<a> ·
<a class="osdn" href=http://slashdot.org>SLASHDOT<a> ·
<a class="osdn" href=http://linux.com>LINUX.COM<a> ·
<a class="osdn" href=http://www.sourceforge.net>SOURCEFORGE<a> ·

See the diffrence? You wouldn't when you saw the page on the screen.

(Ug, writing HTML in HTML really messes with your mind...)
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
it looks it needs fixing too. (2.20 / 5) (#15)
by camadas on Mon Jan 22, 2001 at 12:26:27 AM EST

The logo is no longer rendered aligned to the lower grey bar no my browser, a plain Navigator 4.75 on X. Before you all start shouting reduce the window with to a little less than the grey bar width to see this.

Size of main page depends on your display prefs (3.33 / 6) (#16)
by nospoon on Mon Jan 22, 2001 at 12:33:33 AM EST

Display Preferences play a big role in the size of the main page. Set to 50 stories the size is 149,233 bytes. Set to 10(the default) it is only 66,978 bytes. Keep the default low and the amount of text allowed in the Intro to a decent length and this helps alot.


'Desire that is Friday'
tips from a web developer... (4.30 / 13) (#17)
by Tumbleweed on Mon Jan 22, 2001 at 12:57:23 AM EST

Strip all the spaces/tabs that are making the messy indented effect - you'll lose a lot of weight there.

_Proper_ indentation is a life-saver for development, but it should be stripped out for the code that goes live.

Combine that with fixing all the 'identical font tag inside paragraph tag' problems (of which there are many), and there could be a considerable amount of savings on the site.

re: non-CSS browsers (or browsers with CSS turned off (turn off Javascript in Nav 4.x, and you turn off CSS, too!))

If you're targeting browsers without CSS, _and_ you want it to look the same, then you might as well not use CSS at all, since it's just adding to the code bloat. Either make a CSS-only version, or do a non-CSS site.

The only real use I have for CSS on a mainstream-accessible site these days is for turning off link-underlining. Also, inline-CSS is _evil_. Use an external .css file to describe the whole site. Much easier maintenance, though it _is_ another connection to the webserver...

I almost agree (none / 0) (#50)
by Jim Dabell on Mon Jan 22, 2001 at 02:08:50 PM EST

If you're targeting browsers without CSS, _and_ you want it to look the same, then you might as well not use CSS at all, since it's just adding to the code bloat. Either make a CSS-only version, or do a non-CSS site.

I wouldn't say that. Sure, using CSS and HTML tags to do the *same things* is a bit of a waste, but just using CSS for fonts and colors would be a big improvement, even if other stuff like text size is specified with HTML.

I think that there is an Apache module that strips out non-significant whitespace, but no way would I strip out whitespace from the actual source files. Too much hassle for too little gain. What happens when you just want to track down a minor bug? Reformat the entire tree, look for the bug, and then strip out the whitespace again?



[ Parent ]
CSS & saving space... (2.00 / 1) (#53)
by Tumbleweed on Mon Jan 22, 2001 at 04:48:13 PM EST

> Sure, using CSS and HTML tags to do the *same things* is a bit of a waste, but just using CSS for fonts and colors would be a big improvement, Uhhh, using CSS for fonts and colours would be silly as that kind of thing can be done easily for non-CSS browsers. There's _no_ reason to be using that in CSS if you're trying to make things look the same for non-CSS browsers. Using CSS for things that simply can't BE done without CSS is appropriate, but certainly not for that... re: whitespace stripping There should be a difference between what you edit, and what's on the web server. What you develop should have the indentation, what goes online doesn't need all those extra spaces or tabs. Two copies, see?

[ Parent ]
Not really (none / 0) (#73)
by Jim Dabell on Tue Jan 23, 2001 at 06:04:33 PM EST

Uhhh, using CSS for fonts and colours would be silly as that kind of thing can be done easily for non-CSS browsers.

Well firstly, this article wasn't about easy, it was about space. Secondly, if you think that specifying the font and color for every cell in a table is not annoying, then you haven't done many complex tables. Using CSS for fonts is a big time saver as well as space saver. It also cuts back on code complexity.

There's _no_ reason to be using that in CSS if you're trying to make things look the same for non-CSS browsers.

Who said that was necessary? Why should CSS browsers and non-CSS browsers render a site identically? Reverting to default fonts for non-CSS browsers in order to clean up code is worthwhile, IMO. It's a lot easier to find what you are looking for in a page of code if it isn't obscured by dozens of <font> tags all over the place.



[ Parent ]
same topic, different day (none / 0) (#74)
by Tumbleweed on Tue Jan 23, 2001 at 07:47:40 PM EST

>> There's _no_ reason to be using that in CSS if you're trying to make things look the same for non-CSS browsers.

>Who said that was necessary? Why should CSS browsers and non-CSS browsers
>render a site identically? Reverting to default fonts for non-CSS browsers in order to clean up code
>is worthwhile, IMO.

_I_ said that was what I was talking about. Sure, not fully supporting non-CSS browsers is easier, and will save space, but that's not what I was talking about. I've got more experience in making websites that support super-old versions of browsers (I'm talking down to second generation browsers here) than I care to think about, so I know what's possible. The problem with relying on CSS to do things is that once you start getting complex with your CSS, you start running into some really _nasty_ CSS bugs (especially with Navigator 4.x).

[ Parent ]
Sorta agree... (none / 0) (#79)
by Jim Dabell on Wed Jan 24, 2001 at 03:06:29 PM EST

I've got more experience in making websites that support super-old versions of browsers (I'm talking down to second generation browsers here) than I care to think about, so I know what's possible.

Personally, my rule of thumb is that when a browser cannot use 25% or so of the web, it's time to stop supporting it. That means no HTTP/1.0 browsers (not sure what generation that was introduced in), and 3rd gen browsers are rapidly breaking as well (especially now the SSL certificates have expired on them).

The problem with relying on CSS to do things is that once you start getting complex with your CSS, you start running into some really _nasty_ CSS bugs (especially with Navigator 4.x).

Arggh! I can *definitely* understand NS4 woes. But supporting and fully supporting browsers are different issues. Full support for legacy browsers (such as specifying fonts) is not worth the effort, IMO, especially with a tech-savvy forum like this. As long as the site actually works with non-css browsers, it doesn't matter if it looks ugly. And as long as you stay away from the problem areas (such as layout), you don't have to worry about nasty bugs rendering the site unusable.

I'm not advocating xhtml strict & css without any hacks like table layout, just a little cleanup of the code to make it smaller and simpler.



[ Parent ]
Time for the light version (3.50 / 8) (#19)
by evvk on Mon Jan 22, 2001 at 01:35:27 AM EST

Keep the current, bloated table-kludged version for those who want it, but add a "light" version without any colour settings, without any table kludges and other HTML abuse, just like on the other site. Even with a fast connection, I'd prefer the light version if just for the looks and usability.


Another big issue (2.60 / 5) (#20)
by TigerBaer on Mon Jan 22, 2001 at 01:43:44 AM EST

As a whole, web pages are getting very complex these days.

Complex web pages coupled with massive user increases have made packet loss unfortunately common nowadays. Many routers are starting to drop packets due to crazy amounts of traffic. Imagine, if every major website did away with the fancy images, and such, and stripped there web pages down to simple expanded hypertext.. one object, one connection, one transfer, one packet... the internet would easily increase in notable percentages due to lower amounts of packet traffic. I think a pure fancy text version of K5 should be available.. i.e. no images.. If it was really slimmed down.. it would benefit everyone. TCP connections would get a peak far higher than they do now (lousy flow control!)

What about compression? (3.80 / 5) (#21)
by dr. greenthumb on Mon Jan 22, 2001 at 01:55:22 AM EST

Another approach to this problem is server-side compression, as all(?) HTTP/1.1 browser support transparent decompression of gzipped web-pages.

AFAIK, mod_gzip can't be used on dynamic pages - but there is a couple of server-side programs that do. Vigos is one of them - check out the live demo here.

Of course, this raises other issues (like increased server-load) - but one would be able to serve a helluva lot more pages on the same bandwidth.



- 3 out of 2 have problems understanding statistics -

mod_gzip can serve dynamic content (4.00 / 2) (#30)
by Paul Crowley on Mon Jan 22, 2001 at 05:05:18 AM EST

See the mod_gzip homepage - the top item, dated April 2000, announces a new version of gzip that can cache CGI output, PHP, whatever. I don't know why this doesn't see wider use...
--
Paul Crowley aka ciphergoth. Crypto and sex politics. Diary.
[ Parent ]
Modem compression (2.40 / 5) (#25)
by delmoi on Mon Jan 22, 2001 at 02:34:02 AM EST

One of the other postes mentioned Gzip compression. While that might be a good idea in general, I do belive that almost all modems have their own built in compression. It wouln't be as effective as compressing the whole file, but it can help, especialy on plain text files (even moreso on XML type data). I think I've seen d/l rates of over 10k/sec on a modem with pure text.
--
"'argumentation' is not a word, idiot." -- thelizman
Modem compression GOOD (2.25 / 4) (#28)
by Orca on Mon Jan 22, 2001 at 03:29:13 AM EST

On NetObjects Fusion database files I've seen eyepopping download rates of 20K/sec (yes, that's big K kilobytes) using a 56k modem. Even my crappy 28.8 I've seen burst to 8K/sec on easily compressible files (of course this is pretty occasional, but I was still surprised as heck to see it jump that high and stay there for a few minutes. Thought the next thing I'd be seeing would be smoke pouring out of my modem :)

[ Parent ]
And what does that have to do with the parent? (2.33 / 3) (#38)
by Chiron on Mon Jan 22, 2001 at 07:48:57 AM EST

Those databases very likely have a large amount of repetition in them to achieve that level of compression, since the V.42 et al protocols use a very primitive algorhithm for their compression.

The point that was made, is that the re-compression of compressed data is usually inefficient, and can actually result in a /larger/ file, unless the header structure is sufficiently repetitive. (.zip files have a fairly repetitive header, when compared to bz2 and the latest crop of formats.)

[ Parent ]
Not only that, it's patented *cough*Unisys*cough* (none / 0) (#72)
by pin0cchio on Tue Jan 23, 2001 at 04:24:17 PM EST

Those databases very likely have a large amount of repetition in them to achieve that level of compression, since the V.42 et al protocols use a very primitive algorhithm for their compression.

Not only that, the V.42bis protocol is actually just LZW (ecch! Unisys!) compression and then V.42 error correction. There are better algorithms than LZW such as Deflate (used in zip and gzip) and Burrows-Wheeler transform algorithms (used in bzip2)

zip files have a fairly repetitive header, when compared to bz2 and the latest crop of formats.

This is because .zip files are not a "solid archive," that is, they do the compression before archiving. By comparison, the .tar format is also quite repetitive; .tgz and .tar.bz2 hide this repetition in the compression layer. There is a similar difference between solid and non-solid .rar files (commonly used to store sets of similar files such as Genesis and Super NES music rips that use the same sample set several times).


lj65
[ Parent ]
The last sentence (none / 0) (#81)
by Orca on Thu Jan 25, 2001 at 08:11:29 PM EST

From the parent post: I think I've seen d/l rates of over 10k/sec on a modem with pure text. Just another anecdote. Not *completely* off topic :p

[ Parent ]
Re: Modem Compression (4.00 / 2) (#35)
by baruch on Mon Jan 22, 2001 at 07:09:53 AM EST

The modem compression is fine for textual stuff but it only handles one side of the connection, the isp to your computer, gzip compression of the page actually gives the compression for all the way. It saves bandwidth and can speed up the whole connection since there are less TCP/IP packets traveling along the way, less packets means less chances for loss and thus improved speed overall.

Besides with gzip compression you save bandwidth in a way that helps everyone who shares your lines along the route, and not only saves a bit of time for you.

You lose nothing by getting it compressed, after all it is more likely to be compressed better when the whole file is compressed than when the modem compresses it with its small buffer and small memory.

If everyone would at least use gzip compression for their static pages you'll have far more bandwidth for your pr0n downloading :-)



[ Parent ]
Don't forget accessibility (4.70 / 10) (#29)
by seb on Mon Jan 22, 2001 at 04:41:52 AM EST

There have been several calls for a text-only version of the site. With only a few changes to a text-only version, you could get the massive added beneift of a page that is accessible to people with various disabilities. At the moment k5 is more or less unuseable for anyone with restricted vision or motor problems. This is a great shame for such an inclusive and community-centric site. However, making the current site accessible would be a huge task, and would in fact increase the bloat (alt tags on every image, accesskey strokes for each form input, etc). So there's another reason to develop a parallel, simplified version of the site.

Here's some resources for web accessibility:
W3C Web Access Initiative
W3C guidelines for web accessibility
Bobby's analysis of k5. Bobby is an accessibility checking engine, with specific recommendations for improving a page.
Accessablenet is informative, especially the interviews section.

Suggestion (4.33 / 9) (#32)
by Orteko on Mon Jan 22, 2001 at 05:39:00 AM EST

Rewrite the page and make it validate as xHtml 1.0. All formatting is done by the stylesheets, which removes the huge quantity of unneeded font tags (which will reduce the size of text quite considerably)

XHTML doesn't solve the main issue.. (3.50 / 2) (#37)
by Chiron on Mon Jan 22, 2001 at 07:45:14 AM EST

.. Which is inefficient HTML coding, in the first place. Case in point, the redundant CSS properties from the navbar. Going to XHTML won't reduct the amount of elements in the initial page, either.. In fact, it may very well /increase/ the size of the page, due to the various workarounds necessary to make XHTML render correctly on legacy browsers. (Read that as, damn near all of the production browsers.)

[ Parent ]
XHTML (none / 0) (#48)
by J'raxis on Mon Jan 22, 2001 at 11:52:08 AM EST

I don’t know what XHTML you’ve been using, but I’m talking about using tags that have been around since HTML 2.0, and using a stylesheet to alter their appearance.

H1-6, P, BLOCKQUOTE, UL, OL, LI, DL, DT, DD, (form stuff), STRONG, EM, (not B and I though; unnecessary), CODE (not TT), A, CITE, (maybe) TABLE, TR, TH, TD.

Except for the common use-tables-for-multiple-columns hack, I’ve never needed to use any workarounds to get these tags to work and render comparably in all browsers. Now, when applying CSS, there are needed workarounds — particularly for Netscrape/4.x, but that's CSS, not XHTML.

-- The XHTML/CSS Raxis

[ J’raxis·Com | Liberty in your lifetime ]
[ Parent ]

The XML Well-Formedness Constraints, and XHTML (3.00 / 2) (#55)
by Chiron on Mon Jan 22, 2001 at 07:48:19 PM EST

What is XHTML? --
"XHTML documents are XML conforming. As such, they are readily viewed, edited, and validated with standard XML tools."

XML Start-Tags, End-Tags, and Empty-Element Tags
This one is a bit more long-winded, since the xml recommendation is aimed towards application designers and the parsing of xml documents. But, in essence, in order to be a well-formed document, all elements must either have a closing tag </TAG>, or be an empty tag. <TAG />

What does this mean to Joe Web developer? Well, first of all, closing many of the tags that HTML1,2,3,4 web browsers comprehend as empty elements with </TAG> can have undesired effects. </BR> for example, often generates a hard return on browsers up to and including MSIE 5.0, but not always. If memory serves, MSIE 4 on the Macintosh disregards </BR> entirely, which is the behavior closest to desirable for XHTML documents.

Using the empty tag syntax, </TAG>, results in even more wildly varying results. Some browsers will completely ignore the tag, considering it to be some malformed text, due to the habit of WWW browsers of trying to outthink bad web designers.

The point is, the usage of XHTML is not something to be taken lightly, and once you /have/ managed to work your way around all the landmines, what exactly have you gotten? An HTML document that can be easily parsed by XML parsers into a DOM tree, etc.

It is MNSHO that we would be much better served by not going half-measures with XHTML, and proceed directly to XML, CSS & XSLT. Server-side XSLT can perform the transformations for browsers incapable of XML/XSL, and client-side XSLT can be used with newer browsers, giving them the option of rearranging your XML content in whatever way suits the user, be they blind, using one of those silly phones, their PDA, a serial term, or integrating it into a compound document.

Just my $0.01.



[ Parent ]
Hmmm... (3.00 / 2) (#62)
by J'raxis on Tue Jan 23, 2001 at 12:37:51 AM EST

I use tags like <IMG ... /> and <BR /> and it works fine. Haven't run into any problems yet; checked my pages in the big two browsers on Mac and Windows, and Lynx on various Unix systems.
C.2 Empty Elements. Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents.
HTML Compatibility Guidelines

-- The HTML/3.2 Raxis

[ J’raxis·Com | Liberty in your lifetime ]
[ Parent ]

the larger point: K5's HTML sucks (5.00 / 2) (#80)
by xah on Wed Jan 24, 2001 at 06:45:59 PM EST

Although upgrading to XHTML or XML wouldn't really reduce the size of K5's hypertext source, it would spur the solution to lots of other problems. When web browsers encounter broken hypertext, they can't render it as quickly as they can good hypertext. Admittedly, the redundancies in K5's hypertext should go away. But so should all of the HTML errors, as indicated by validator.w3.org (hyperlink in parent comment). K5 is rendered very very slowly on Netscape 6 running Windows 98. (I'll let you brave folks out there beta test Mozilla.) Netscape 4.x is what I end up using for K5 (and only K5). So K5 is supposed to be using HTML 4.0. Fine. Just don't have 500 HTML 4.0 errors on every page.

FWIW, I like XHTML. I use it for my own pages. Not insignificantly, XHTML is valid XML. Thus, those who say "skip XHTML, just go straight to XML," are missing the point. XHTML is XML. Upgrading to K5 would spur the cleanup of all the hypertext problems. It would also be a statement that sensible hypertext on the web is important. In the end, however, it doesn't matter what W3C standard K5 tries to meet. I just wish K5 would do hypertext better.

[ Parent ]

K5 is not for travelling philosophers... (4.84 / 13) (#46)
by WWWWolf on Mon Jan 22, 2001 at 09:55:42 AM EST

I mean, look at the Other Site. See what they've got. They also have this "The Other Site Lite (reduce HTML complexity)" which I used extensively at one time because it made the site actually usable with Netscape 4 and its slow table rendering.

I have both Nokia 9110i and a Palm m100, these PDAs nicely complement each other. (Nokia does the on-line web stuff, terminal emulation and mobile applications, Palm does my notekeeping and calendar, as well as off-line web... and Palm's web channels can be synced using the Nokia easily over IR.)

When I loaded K5 to the Nokia one day when I was in train, I was sort of gasping with horror. Can you imagine what is it like to download 70 kilos of stuff over 9600 bps GSM network??? <old-fart>You haven't lived until you have experienced that! And try the same with a Commodore 64 and a 300 bps modem someday, too!</old-fart> (Then again, C64 supports everything up to ISDN these days... =)

So, when do we see http://www.kuro5hin.org/pda/? =)

I would really like it if the CSS would be used more widely in the K5, because that would help the "desktop" users too - K5 front page is sort of sluggish to load, even with Lynx and single-channel ISDN. Also, "light" version of the pages would rock. And then "even lighter" for PDA purposes. This is a dynamic website, I don't think these are impossible.

-- Weyfour WWWWolf, a lupine technomancer from the cold north...


I second that motion (none / 0) (#67)
by reel_life on Tue Jan 23, 2001 at 07:56:23 AM EST

I'd would also like to see a lite version for K5 for pda users.

Madness takes its toll on everyone. Please have exact change.
[ Parent ]
Light weight, anyone? (4.00 / 7) (#51)
by dr. greenthumb on Mon Jan 22, 2001 at 03:31:22 PM EST

Ok, I may lack a life since I took myself the time to throw together a live light-weigth (proxy) version of kuro5hin.org ... great way to spend an otherwise boring afternoon ... ;p

Should work with all pages on kuro5hin.org, with exeption of those requiring HTTP POST (and GET?) data.

As of now, the mainpage is 28889 bytes in light version versus 66188 bytes in the normal version.



- 3 out of 2 have problems understanding statistics -

Getting a bit nervous ... (2.00 / 1) (#52)
by dr. greenthumb on Mon Jan 22, 2001 at 04:02:21 PM EST

Awright, I realize that this perhaps violates the stuff on the legalese page; so to whom it may concern - if you don't like it being there, let me know. It'll be gone in no time (time zone differences not accounted for). I have no intention of keeping it there for any long time anyway.



- 3 out of 2 have problems understanding statistics -
[ Parent ]
lightweight K5 (3.00 / 1) (#64)
by driph on Tue Jan 23, 2001 at 06:23:34 AM EST

Heh... We're working on a light version of K5, as well as one that will work well with PDAs, and maybe a couple other varieties(especially as we get closer to theming). If you(or anyone else reading this) happen to have a suggestion, feel free to send me an email.

We should have a lightweight version of the site available fairly soon..

--
Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave
[ Parent ]
time to stop worrying about pixel perfect design (4.66 / 6) (#60)
by artificeren on Mon Jan 22, 2001 at 11:02:41 PM EST

I've been a web developer for a while now. If there's one thing i've come to accept, it's that we have to stop attempting to make sites look exactly the same on every browser. It's NOT going to happen. especially now with very non-traditional browsers coming up.

we have 2 choices, spend untold amounts of time and kilobytes to make the site look almost exactly the same on a couple of the big browsers, and look like Utter Trash in all the rest...

Or design our sites using standard html3.2 structural tags, and use css to style it.

if there are 2 tags that have ruined the web, it's font and table. they've turned it into a bloated mess.

and don't give me that, "but people can turn off css", or "netscape navigator 4.x destroys it". First off, anybody who uses either of those to things doesn't really care at all about the look of the page, and I don't worry if that bottom margin is 5 pixels bigger on their screen.

but the bigger point is that it won't break the page completely for anybody. if somebody reads my PlainHTML/CSS page with an older browser... they can still read and understand it Just Fine. however, try opening up Kiro5hin with a web browser for the blind sometime... it's not pretty.

the bottom line... if you want Pixel Perfect across viewers, go design for a magazine. because that's the only place you'll get it. This is the web. Treat it that way.

Viva variety (4.00 / 2) (#63)
by driph on Tue Jan 23, 2001 at 06:19:40 AM EST

Actually, I'd be interested in seeing how K5 renders on a browser for the blind. Wonder if I could get screenshots...;]

And as far as I know, K5 renders pretty much the same on every browser out there.. we've gone through a lot of work to make sure it's a [fairly]consistant experience regardless of platform or browser..

I don't accept the "if they wanted a better browsing experience they wouldn't be using a shit browser" line at all. Unless I am building a site specifically for web designers, I am going to assume that the audience does not not know browser X hoarks certain table layouts or that browser N breaks CSS. It's not their job to know that. They just want to get online and have an enjoyable experience.

--
Vegas isn't a liberal stronghold. It's the place where the rich and powerful gamble away their company's pension fund and strangle call girls in their hotel rooms. - Psycho Dave
[ Parent ]
Still, if the shit browsers are in the minority... (5.00 / 1) (#65)
by evilpete on Tue Jan 23, 2001 at 07:00:11 AM EST

The last graphical browser without any CSS support was Netscape 3. IE3+ and NN4+ can use broad stylesheet rules to format text - even if the cascading portion of the spec is badly flawed in some of them. Using more advanced CSS and CSSP will cause page rendering problems, but if you use tables for layout and stylesheets to eliminate font tags then you'll cut down page sizes quite a bit.

If the vast majority of people now have browsers that support css for text formatting isn't it silly to bloat pages for all, just to protect a few people's 3-4 year old browsers from serif text?

[ Parent ]
CSS (none / 0) (#82)
by Yer Mom on Fri Jan 26, 2001 at 07:35:44 AM EST

Ah, but Netscape 4 doesn't render stylesheets unless you leave Javascript turned on, and many people turn it off in an effort to get rid of evil popup adverts and the like.

Of course, the real question is why Netscape couldn't treat the "disable Javascript" button as having an implied "except for the stuff I've generated from a stylesheet". This is why I switched to Opera :)
--
Smoke crack. Worship Satan. Admin Unix.
[ Parent ]

Netscape CSS (none / 0) (#84)
by IntlHarvester on Sat Jan 27, 2001 at 04:23:37 PM EST

Netscape developed a proprietary style sheet system for 4.0 called JavaScript Style Sheets. Cascading style sheets are convered internally to JSSS, which is a hint on why JavaScript must be enabled for CSS to work on NS4, and also why CSS is so poorly supported.

[ Parent ]
I know, but... (none / 0) (#86)
by Yer Mom on Mon Jan 29, 2001 at 10:32:21 AM EST

...surely Netscape knows what JavaScript it's generated itself and what's been downloaded from the page?

Still, it's a bit late to change things now, what with NS6 coming out :)
--
Smoke crack. Worship Satan. Admin Unix.
[ Parent ]

key words there: 'lot of work' and 'fairly' (5.00 / 1) (#70)
by artificeren on Tue Jan 23, 2001 at 01:08:16 PM EST

A) there is a difference between being lazy, and working smartly. Just because it took a very long time and a lot of work to add 4 million tags that make the layout look only "fairly" consistent across browsers, doesn't mean that that was time well spent. Having a pixel perfect consistent layout across probably hundreds of possible clients is a never reachable goal.

2) I've worked on sites for State Colleges and government projects before, and the use of the table tag was strictly forbidden becauase of what it does to the understandability for blind people.
I could be wrong, but I'm willing to bet that the number of blind people using the internet will soon far eclipse the number of netscape 4 users out there very soon. Are you willing to throw away that audience?

III) It's not that the jane-web-surfer should know about how utterly crappy their browser is, it's that those people will not notice at all that the right margin on their netscape window is 10 pixels wider than on ie. The only people that notice, or care, about the differences are the people that compare them everyday. Meaining, the web designers are the only ones who care.

[ Parent ]
Especially since I might load 20 pages per visit (4.50 / 2) (#66)
by JackStraw on Tue Jan 23, 2001 at 07:55:42 AM EST

If this was just a front-page issue, then it would be ok. But since this is the type of site where I'm loading a new page every 40 seconds, and I'm usually on a 56k modem, I'd rather have pages that just flash up without a lot of loading. The average kuro5hin'er spends so much time here that it becomes like his computer desk; it becomes almost invisible compared to the content of the site.
-The bus came by, I got on... that's when it all began.
A simple suggestion (3.00 / 2) (#68)
by timefactor on Tue Jan 23, 2001 at 10:24:21 AM EST

Use >BASE< and >BASEFONT< tags. They work in all browsers and will prevent the duplicated http://209.208.150.46/ and FACE="arial, Helvetica, Sans-Serif". A quick count gave more than 100 of each on the front page.

- I cannot believe in the existence of God, despite all the statistics. - Borges
A simpler suggestion (none / 0) (#69)
by timefactor on Tue Jan 23, 2001 at 11:39:16 AM EST

OK, I'm dyslexic. That should be <BASE> and <BASEFONT>

- I cannot believe in the existence of God, despite all the statistics. - Borges
[ Parent ]
<STRONG> agreement. (5.00 / 1) (#77)
by seebs on Wed Jan 24, 2001 at 09:22:10 AM EST

Yes, please remove all this font crap. Don't tell me that I am *required* to see the page in sans-serif. What if I prefer a serif font? I *hate* Arial. Just strike all the font tags, and use <BASE>, and it'll be a lot more useful. Content over form, people.


The page needs to be validated (5.00 / 1) (#78)
by tbcidy on Wed Jan 24, 2001 at 09:29:32 AM EST

Besides being bloated the kuro5hin page needs to be validated. For example:

  • Line 19, column 22: <STYLE TYPE="text/css"></style> The style element should be in the header, not the body of the page. Also there should be one style element, not two.
  • Multiple unclosed font tags.
  • Many of the images don't have alt tags.

See for yourself



imo (3.00 / 1) (#83)
by jk on Fri Jan 26, 2001 at 01:33:10 PM EST

overall, heavy, but could be worse. <basefont> would solve most of this. aside from that, strip out the whitespace html formatting when you're done editing/scripting the document. it ain't free. every space and \n is another character that needs to be xfer'ed.

as for the guy that said content over form, i can't say i really agree. in my mind, if you want to get that fine-german-engineering feel you need good execution of content and form in equal parts.

later.

no comment, HELP!!! (none / 0) (#85)
by dsilverman on Sun Jan 28, 2001 at 07:50:04 PM EST

I have no comment on bloat, except for two points:
  • I rarely tune in to K5, as every time I load a couple pages of comments, it crashes my browser (IE5::mac) and my whole computer. This is the only site on the web that has ever crashed my computer, but it does it always. Therefore, I never visit. And IE5 for Mac is one of the most standards compliant and leniant browsers out there, so something you are doing is evil here. This is incredibly frustrating: my computer rarely if ever crashes. I usually have an uptime of about two weeks, pretty good for a Mac (yeah, don't make fun of me Linux guys!) I hate having to restart for no reason, instead of because I've installed some new software.
  • I want an option to limit my comment viewing so I can have, say, > 4 or something, so I don't have 100 comments/page slowing down my browsing.

    Please oh please, help me! This site is so frustrating, even though it is pretty. ;-)

    ----
    "Speak softly, and carry a big stick."

  • I'll vote for leaner code (none / 0) (#88)
    by jack doe on Fri Feb 02, 2001 at 08:31:06 PM EST

    Some of the longer discussions, read in flat mode, cause resource issues on typical browsers. Trimming the code might help.

    k5 needs a diet? | 87 comments (84 topical, 3 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!