Slashdot Mirror


Retooling Slashdot with Web Standards

Joe Clark writes "Nearly a year after an interview with this correspondent highlighted a few problems with Slashdot's HTML, Daniel M. Frommelt and his posse have recoded a prototype of Slashdot that uses valid, semantic HTML and stylesheets. Frommelt projects four-figure bandwidth savings in the candidate redesign, were it adopted, not to mention better appearance in a wide range of browsers and improved accessibility. Next he needs volunteers to retool the Slashdot engine. And yes, he did it all with CmdrTaco's blessing." Slashdot has kept its HTML 3.2 design for a long time ("because it works"), but perhaps this effort will be a catalyst for change...

23 of 764 comments (clear)

  1. *looks down* by Xerithane · · Score: 5, Funny

    Hell just froze over.

    Brr.

    --
    Dacels Jewelers can't be trusted.
  2. Just another example of the Slashdot monopoly... by CSharpMinor · · Score: 5, Funny

    They're actually proud of this? That they went so many years without complying to HTML standards? It is obvious that Slashdot was just planning to break the HTML standard to force everyone to use Slashdot's "integrated" browser, Mozilla.

    This isn't the first time this has happened. Remember when BBS's became popular, and Slashdot "integrated" one into their site to kill any competition? Or all the times that Slashdot has brought down "competing" sites by linking to them, thereby safeguarding their website monopoly?

    It's a shame that the DoJ let them off for this....

    --

    Whatever it is I'm complaining about, I'm sure the Republicans did it. This is /., after all.
  3. While you're at it by GoldMace · · Score: 5, Insightful

    Could you please make page 2 of comments actually be page 2 of the comments. I might be incredibly naive, but it seems something more like page 1.5. I don't know about the rest of you, but I always just read the odd numbered pages of comments, because like way too much stuff if repeated from the previous page on the even numbered ones.

  4. universal access by kurosawdust · · Score: 5, Funny

    will this work for browsers for those with disabilities? I think its only fair, considering I clicked on slashdot Games article and am now freakin' blind.

  5. Re:Not ANOTHER non-standard page... by The+Unabageler · · Score: 5, Insightful
    did you not read the article?

    the code was converted to XHTML 1.0 Transitional, and validated


    that's almost as standard as you can get.
    --
    perl -e '$_="\007/4`\cp%2,".chr(127);s/./"\"\\c$&\""/gees; print'
  6. The prototype is slowing already by Amiga+Lover · · Score: 5, Funny

    The prototype is slowing already. You bastards! you slashdotted slashdot!

    1. Re:The prototype is slowing already by Maserati · · Score: 5, Funny

      It's worse than that, we've slashdotted future Slashdot. The implications for the time-space continuum are dire.

      --
      Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
  7. Hallelujah! by EchoMirage · · Score: 5, Insightful

    This is long long long long long overdue. Just because HTML 3.2 "worked" didn't make it good, or right. A proper application of [X]HTML and CSS can be a huge bandwidth saver. It looks like Google also updated their design yesterday or today - no doubt to subtly cut down on the huge amounts of bandwidth they serve out. More importantly for Slashdot, however, is that writing their code in an open and updated fashion really opens up the market for the kinds of people that can access the site, and that's never a bad thing. So congratulations on starting this project, and I hope it gets underway soon!

    Now maybe I'll finally be able to change my .sig!

    1. Re:Hallelujah! by Anonymous Coward · · Score: 5, Informative

      I'm a blind /. user and I use either JAWS interfacing with IE (yes, I know, windows sucks but Gnopernicus is not there yet) or command-line browsers such as lynx and links. For the most slashdot works alright, and I'd say CSS and XHTML only affect people using more semantic tools, like those who use Emacs to browse.

  8. Wow, slashdot is ugly... by anthony_dipierro · · Score: 5, Funny

    So I looked at final example and I was just about to complain about how messed up it was. The words in the boxes on the right were all scrunched against the left edge. There were these stupid little dots in front of the links. It was just plain ugly. Then I went to the real site and realized it had always been that way, I just haven't paid attention to it.

  9. About the author... by Lank · · Score: 5, Funny

    Daniel M. Frommelt is the University World Wide Web Coordinator at the University of Wisconsin - Platteville, an executive committee member of the Campus Web Council of Wisconsin, and a web standards advocate. Daniel spends his free time brewing beer.

    I like the guy already.

    --
    Gotta get me one of these!
  10. Teeny Bug by Audity · · Score: 5, Interesting

    That's all well and good, but you don't want to break the old page. I read slashdot often with my "text zoom" on mozilla 1.0.1 at 120 or 150%.

    Right now slashdot looks normal at any text zoom setting, but the version proposed in the article hides parts of words when I turn up my zoom to 200%. I don't often read with text that large, but I've done it before, and I'm sure there's users out there who do it regularily.

  11. Not complying with any HTML standard by LiamQ · · Score: 5, Informative

    Actually, they have been complying with HTML standards, just the old version 3.2.

    That's not true.

  12. Re:F5 by ergo98 · · Score: 5, Insightful

    This is the classic response to that comment (about wasteful whitespace), yet I don't buy it.

    a) Totally guessing, but about 99.9999% of the pages served up are interpreted by "no one" other than the browser. It's more "readable" by the browser minus the whitespace.

    b) Most pages, like this, is "mechanically generated" - What you see in the final results was rendered: It isn't the "source-code". As such there is absolutely no code maintenance issues.

    What you're left with is the prospect that maybe one out of every million page hits is going to a Slashdot developer who's debugging that the rendered properly, though if it's XHTML transitional then a XML editor would be a great choice and would again make it irrelevant if it's clogged full of waste whitespace.

  13. Re:Explains some stuff by BJH · · Score: 5, Informative

    IE's character code handling is heuristic if no character code is specified in the HTTP header or the HTML head block.
    It scans through the page and tries to match the character frequency against average character frequencies for various languages. If you're seeing Slashdot as Big5, then that means IE thought that the character frequency matched Big5 most closely.

  14. Editor Queue enhancements? by Speare · · Score: 5, Insightful

    Not a flame.

    If you're thinking of retooling the slash engine itself, I hope you consider some of the oft-complained areas for the most improvement. Things get mixed up in any random-access submission "queue" engine, but slash seems to suffer from these things often. Even editors have grumbled about not seeing other editors' status on various stories.

    • detect multiple/overlapping story submissions by their URLs, and make it easier for editors to find the earliest and to find the best (longest, most links, no broken links) examples of a breaking story
    • automatically give submitters a reason for their rejections: "rejected; another poster broke the story earlier and/or better."
    • capitalize stories according to title rules (not just every word)
    • fix or highlight the top fifty most common grammatical mistakes in submissions automatically (s/\bmore then\b/more than/g)
    • automatically mirror (and provide as separate link) a front-page snapshot of featured stories for the first hour of a story going public
    • searcher should be aware of common three-letter acronyms, and index them better
    • allow meta-moderation of "overrated" and "underrated"
    --
    [ .sig file not found ]
  15. Article by yerricde · · Score: 5, Funny

    Many languages have two articles, which correspond to English "an" and "the". Many of those languages have multiple forms, called "allomorphs," for each article, determined by context; in English, "an" becomes "a" before a consonant and "some" before a mass or plural noun. Russian has no articles, their function having been replaced by sticking nouns before the verb (to imply "the"-itude) or after the verb (to imply "a"-ness).

    Another meaning of "article" is any of the interesting pages linked to in the story at the top of a Slashdot article.pl page. In this case, Slashdot users would call this page "the article".

    --
    Will I retire or break 10K?
  16. Slashdot CSS Suggestions by scoobysnack · · Score: 5, Insightful

    Good article, just a couple of suggestions...

    In general, it's usually better to avoid giving layout-suggestive names to your div tags. In the example, the author calls the Login/Sections/Help div leftcolumn. It would probably be better to name it something that is more suggestive of it's content rather than it's location - this way, if in the future a new skin was added that moved the content to the right-side, or even bottom of the page, the div name wouldn't contradict it's location.

    Another suggestion would be to disable all images in the print.css file. The author already went ahead and disabled the advertisement, the left and right columns, but he left those pesky story icons. I know that when I print an article, usually all I care about is the text. It's a simple way to make a page a little more printer friendly.

    My last suggestion would be to move the content div tag, up near the top of the page. This way, as your browser downloads the information from the server, it will download the story information (important) before downloading the left/righthand content panes (unimportant). If someone stops loading their browser before the page download has been completed, at least the browser can attempt to render the story data. And with css, the layout will be preserved.

  17. This article is intended to be read by humans by yerricde · · Score: 5, Insightful

    how about eliminating all of the completely wasteful, bandwidth and processor consuming, whitespace?

    As you point out, XML, CSS, and ECMAScript, unlike Python, are not very sensitive to whitespace. Slashdot can mitigate whitespace's contribution to bandwidth in two ways: 1. mod_gzip (which Slashdot already uses), and 2. caching proxies that strip excess whitespace. But this article itself is intended to be read by developers, and clarity counts.

    --
    Will I retire or break 10K?
  18. What about PNGs? by Yosho · · Score: 5, Insightful

    Come on, Slashdot still hasn't converted its GIFs to PNGs. That alone would save a good amount of bandwidth, not to mention that Slashdot is supposedly pro-open source and all that.

    The only argument I've seen against them is for compatibility's sake -- honestly, I would be surprised if even as much as 1% of Slashdot's readership was using an image-based browser that did not support PNGs. There are probably plugins available for the ones that don't. So, why not?

    --
    Karma: Terrifying (mostly affected by atrocities you've committed)
  19. XHTML or HTML 4.,01 Strict? by kuzb · · Score: 5, Informative

    If XHTML, there are some things to consider:

    It's important to note that using XHTML 1.1 requires you to send your documents as XML. This means the document should have an XML declaration above the doctype, and needs to be sent with an XML mime-type, ideally application/xhtml+xml. This has a significant drawback; IE can't see it.

    A fairly well established workaround is to use mod_rewrite and munge the mime-type of a document based on what a user agent sends in its Accept header (To date, Mozilla is the only browser to include application/xhtml+xml in its Accept header). However, some would argue that this too has drawbacks. Since only Mozilla understands application/xhtml+xml, your documents will be sent as text/html, and XHTML does not validate as HTML.

    The arguments around this issue have been summarized in the widely linked "Sending XHTML as text/html Considered Harmful"

    --
    BeauHD. Worst editor since kdawson.
  20. Sweet. i've been working on the same thing by legLess · · Score: 5, Informative

    This is an elegantly-designed page, and a nice recode of the original.

    For the last several months I've been working on the same project from a slightly different perspective. We have a working Slash-based site, currently in live beta, at http://www.news4neighbors.net.

    The site doesn't validate, but it's all structural XHTML with CSS for layout and style. This is much rougher than the beautiful markup presented here, but the difference is that nearly our entire site is running this template system. My work is based on the Openflows strict theme, released early this year at http://strict.openflows.org. But not much of that theme is left, as their project and mine had very different goals. I've changed all of the 120-something templates, and much of the code that sends them data.

    The site needs a lot of work, no doubt. But we're developing it rapidly, and have made much progress.

    The biggest challenge is that Slash itself doesn't separate content from presentation from business logic. To change one set of tags you may have to rewrite a template, change a database variable, write some Perl, or a combination. This isn't a knock on Slash -- it's very powerful and I enjoy using it -- it's just that the presentation layer hasn't been their focus.

    The end-goal for this project, Slash-wise, is to have a fully XHTML/CSS compliant theme that people can easily use on their sites.

    If you want more information about it, send me email at randall -at- sonofhans.net

    [ FYI, I also posted this in the ALA discussion ].

    --
    This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
  21. Re:Blech... by setmajer · · Score: 5, Insightful
    The designer hardcoded a fontface because CSS doesn't automatically resize columns like tables do.

    Er, 'fontface'? WTF is a 'fontface'?

    As for CSS resizing automagically, resize in relation to what, pray tell? A box with width: 30%; resizes in relation to the viewport, a box with width: 15em; resizes in relation to font size, as of CSS 2.1 a box with float: left or float: right and no width resizes in relation to content (most browsers--including IE/Win--do this anyway) and table-layout will get you table-style layout with whatever tags you like. MS just didn't feel the need to support it in IE 5/Win or IE/Mac so people don't use it much. That's Microsoft's fault, not the W3C's

    Because CSS was designed by doofus eggheads and not experts in solving real world web design problems.

    Ian Hickson edited the CSS2.1 spec, and he's been 'solving real world web design problems' since at least 1998 when I worked with him at the Web Stanards Project. Hakon Wium Lie edited CSS 1, 2 and 2.1 and has been working on Opera since 1999, earned an MS in Visual Studies from MIT and wrote his thesis on electronic display of newspapers. TantekCelik is responsible for the widely-lauded Tasman rendering engine used in IE 5.x/Mac. These people do use this stuff in the real world, and if you don't like the directions they're taking your'e free to join the www-style discussion list and let them know.

    Which then forces me to do a bunch of work

    One line of CSS is 'a bunch of work'? I suppose you find tying your own shoes a pretty onerous task as well?

    or accept undesirable browser settings

    Let me get this straight: you're hacked because the site doesn't use your settings for font size and face, but setting your browser to override the site's settings with your choices is 'undesirable'? Huh?

    --