Help Beta Test Slashdot CSS 581
After almost 8 years, Slashdot's HTML is finally getting an overhaul. For now the changes are almost entirely under the hood, as we migrate the current skin to CSS. Slashdot itself will migrate in the next few weeks, but for now, we'd appreciate it if people who understand CSS could take a look at Slashcode. If you use a browser that lets you select a stylesheet, you can take a look at that site with the Slashdot CSS Skin. Keep in mind that Slashcode doesn't look exactly like Slashdot, so there will be some differences between that site, and the final version that will appear on Slashdot. We're mainly looking for feedback on compatibility issues and blatant bugs. You can use our our SF bug tracker to submit bug reports. Thanks for your help. Once we move Slashdot, work will begin on a new look & feel. If you have ideas, you could start playing with the CSS stylesheets now!
Will the beta bring the site down? (Score:5, Interesting)
Considering the fact that it took nearly two minutes for the form to arrive makes me think we are in for a bumpy ride!
Oh My God, It's Actually Happening! (Score:5, Interesting)
This. Rocks.
Kudos on finally bringing Slashcode into the 21st century! The Slashdot style over on Slashcode looks absolutely wonderful, with none of the chunky layout problems that plague Slashdot itself! What I'd love to know is, how much bandwidth are you saving by using CSS? Many of the experiments done to date suggest that you could cut your bandwith usage by 30-50%! Will this update usher in a new era of faster page loading? Inquiring minds want to know!
Maybe adding a little JS ... (Score:5, Interesting)
XHTML (Score:5, Interesting)
Slashdot.... testing??? (Score:3, Interesting)
I'm more surprised that after 8 years, slashdot is testing something on a machine that isn't the main server.
Seriously, while you guys are changing things, how about changing it so ALL code changes go through regression testing along with some major user testing before you drop ut into the production servers. We all dislike 503s, and we have see a TON of bugs pop up (like last weeks 'unable to see comments' for several hours).
huh? (Score:4, Interesting)
Re:css!! (Score:4, Interesting)
Incidentally, I agree with him -- designing web sites for broken browsers is like giving illegal immigrants drivers' licenses: it's stupid and it doesn't fix the underlying problem.
Re:XHTML (Score:2, Interesting)
Re:XHTML (Score:5, Interesting)
This guy is seriously arguing that people should not adopt a now mature standard, because one aging piece of software hasn't been updated in four years? He just needs to get over his love affair with IE and realize that the rest of the world is still progressing.
Addmitedly, I don't know when the article was written, but that's only because the author didn't date it. To argue that XHTML is bad because old UAs poorly support it is truly a case of the tail wagging the dog. I can hardly believe that the author doesn't understand that.
Re:css!! (Score:5, Interesting)
It doesn't cost them anymore than before, but it really opens their eyes.
Bob
Re:Fortunately (Score:4, Interesting)
"Perhaps the biggest benefit of this particular example is the bandwidth savings:
* Savings per page without caching the CSS file: ~2KB per request
* Savings per page with caching the CSS file: ~9KB per request
Though a few KB doesn't sound like a lot of bandwidth, let's add it up. Slashdot's FAQ, last updated 13 June 2000, states that they serve 50 million pages in a month. When you break down the figures, that's ~1,612,900 pages per day or ~18 pages per second. Bandwidth savings are as follows:
* Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth
Most Slashdot visitors would have the CSS file cached, so we could ballpark the daily savings at ~10 GB bandwidth. A high volume of bandwidth from an ISP could be anywhere from $1 - $5 cost per GB of transfer, but let's calculate it at $1 per GB for an entire year. For this example, the total yearly savings for Slashdot would be: $3,650 USD!
Remember: this calculation is based on the number of pages served as of 13 June, 2000. I believe that Slashdot's traffic is much heavier now, but even using this three-year-old figure, the money saved is impressive."
Let me use Sans fonts (Score:5, Interesting)
Thank you,
Tester
Move content to top of output... (Score:2, Interesting)
...and use CSS to reposition the sidebar/navbar content below it. Half the point to using CSS for accessibility is to avoid going through navlinks at the beginning of every page. I hear these guys [nau.edu] managed it across their site without compromising performance in IE 6 or spectacular hacks (and yes, it was tested in IE, Safari, Firefox, Opera and Konqueror).
For the curious, the left and right navbars are absolutely positioned and the central content has left/right margins which mimic their width, to achieve the same liquid layout.
The HTML4.0 thing is bullshit, plain and simple. Authoring tools like Dreamweaver work better when working within XHTML spec, just lose the XML prolog until The Brave New World of XML-parsing UAs is here and we can stop serving text/html. XHTML1.0 Transitional plays nice with every UA I've tested, from Netscape 4.7 up.
Mobile phone and PDA support???? (Score:1, Interesting)
To make things even worse the CSS version of Slashdot is not as compatible anymore with these mobile browsers as they are not so CSS-capable as desktop browsers are. In other words: sh*t.
What I need is a special mobile version of Slashdot that loads AUTOMATICALLY when the 10-15 most popular mobile browsers hit the slashdot.org site.
Re:css!! (Score:3, Interesting)
Again, it doesn't cost the client anything more than normal, and I have plenty of clients who come back for more business.
Bob
html 4.01? are you serious? (Score:3, Interesting)
HTML 3.2 [w3.org] - 1997
HTML 4.01 [w3.org] - 1999 (!)
XHTML 1.0 [w3.org] - 2000, revised in 2002
XHTML 1.1 [w3.org] - 2001
Welcome to the year 1999. The future is now. While I appreciate the efforts of the Slashcode developers, I would like to point out that it is still possible to write spectacularly awful code in HTML 4.01. Yes, it is possible to do so in XHTML, but it is more difficult. My one request to the developers (and believe me, you will thank me when maintaining this code base) is to use <div> tags, lists, and CSS positioning for layout instead of tables. It makes your code so much cleaner and easier to edit. In fact, to me it is the main benefit of CSS.
(If you remember this article [alistapart.com], posted to
Re:Let me use Sans fonts (Score:3, Interesting)
I guess that is a valid request, but you are in the minority, and slashdot actually does fonts "correctly".
For most people, a proportionally spaced serif font is easier to read for the body of a document, and a proportionally spaced sans-serif font is better for thing like headlines or section titles. However, after just typing that I went to a number of popular news sites, and they use sans-serif fonts everywhere.
Is my font data only applicable to printed text and not text displayed on a screen? Personally, I'm a fan of the way slashdot does their fonts (in the right browser
Re:Let me use Sans fonts (Score:3, Interesting)
That's generally true for print, I'm not so sure about on screen reproduction (anyone care to offer any case studies?). The theory is that the serifs are supposed to help guide your eye, so it's easier to see what the letter is. However, given the relatively low resolution of screens, it doesn't seem to work as well for me. I certainly prefer serif fonts, and have told my browser to always override the font to my own preference.