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...
I'm all for it. If it makes /. load faster when I hit CTRL-R 10 times per half hour then I'd be very happy!
On second thought, that could mean more time working. Scratch the idea.
Hell just froze over.
Brr.
Dacels Jewelers can't be trusted.
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
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.
but perhaps this effort will be a catalyst for change...
How about a new look altogether?
I had a look at the new site, and while it does fix many problems and should certainly be used to replace the existing setup, why not go a little farther and retool the look of the site as well?
The look of slashdot has barely changed since the late 90's, and while the look certainly brings part of it's character, it's beginning to look dated. Perhaps it can be redesigned with a more effecient and cohesive interface while still retaining some of it's previous character?
Or is it just a pipe-dream...
I would expect such blatant racism on Fark, but on Slashdot? Mods please ban this asshole.
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.
that's almost as standard as you can get.
perl -e '$_="\007/4`\cp%2,".chr(127);s/./"\"\\c$&\""/gees
I like it! Looks just fine in Safari 1.1.1 on Panther.
I love the option of giving the users a choice too! Using the CSS import option would be great. Just create 3 or 4 color schemes and give people a choice (at least for the "main" part of it).
The prototype is slowing already. You bastards! you slashdotted slashdot!
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!
.sig!
Now maybe I'll finally be able to change my
When the time comes, please add some code to switch to a light design when browsing with a PDA. I know right now you can select light mode, but it affects all browsers used from an account which isn't at all what I want...
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.
I've always been partial to F5 myself.
In any case, I've looked at the final example (the "optimized" page), and while it's nice to see someone pushing for the adoption of `cutting edge' (as of 1999) CSS, how about eliminating all of the completely wasteful, bandwidth and processor consuming, whitespace? Unless this is python at whitespace affects scope (which it isn't), I don't see why so many sites have such a fetish with tabbed and spaced HTML when the browser discards it as garbage bytes, actually wasting time (albeit a tiny amount, but nonetheless) parsing through it.
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!
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.
Perhaps you could add a section to preferences that lets users choose which color schemes to use on all of the Slashdot sections. If they don't want to set the same color for all sections, let them choose a default (individual settings for each section would probably eat up a lot of space).
It would be GREAT to see them finally, 3 or 4 years later, dump the old theme and streamline it with CSS and stuff. Is it going to happen anytime soon. Probably not.....
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
Now that you've made slashdot standards compliant, why not make it look good? CSS has powerful leading, word spacing and font tools (all of them with relative measurements to look good across most browsers). If a browser doesn't like a text attribute, it won't display it, so you won't have to worry about the same unpredictability as you would with layers and div boxes. The one thing that sucks the most on slashdot is its typesetting. Type is the one thing web designers forget about, but doing it right drastically improves the appearance and readability of a site.
is a bad idea. Personally, I like it. Reducing the necessary bandwidth to use the site is a good thing though for everyone involved. Why spend money you don't have to in a down economy.
/. is not an issue so what's to prove by changing the look? Gain new users? Have more impact?
/. would prove to be a mistake.
Things do look a bit dated, but maybe that is a good thing. The popularity of
Anyone that matters knows the site already. The content is the reason they return, not the pretty icons. Getting more impact through a more compelling rendering might matter to a few folks, but will the expense be worth it?
Maybe this is the wrong comparison... Take an established publication like the Times or WSJ. Do they make big changes often? No. The formula works and is a big part of their identity.
I think they keep things the way they are because they know change works against the needs of their readers; namely, access to relevant content easily.
Unless I am missing something, major changes to
Blogging because I can...
There is a project called CSSZenGarden. It's a collection of different stylesheets which modify the same content according to contributor's tastes and design abilities. There are few dozens of examples, and amongst them there is the Slashdot interface, albeit not a perfect copy as shows in the article.
You can view all the available CSS designs here. Same content, different stylesheet. Just shows off all the wonderful things that's possible with CSS standards-based page creation.
"HTML is dead." - Friedrich Nietzsche
/. makes money off ads and subscriptions. Why should we work for free? After all, the editors will not even edit their site nor will the check for dups. And some of the bandwidth cost savings could go to those that do the work.
That's not true.
The bit that impresses me more is that the page rendered properly with Mozilla Firebird 0.7 on Win32. The real slashdot doesn't render particularly well at all with Firebird for me.
I find your ideas intriguing and I wish to subscribe to your newsletter.
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.
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.
[
Slashdot doesn't use "Times New Roman." It uses absolutely no font at all. This means that your browser renders it using its default proportional font. Proportional usually maps to one of "sans-serif" or "serif," and then you can change your default sans-serif or serif font.
I'm not sure if this is settable in IE, but Mozilla, Safari, etc etc have these settings.
Personally, I use serif, and then my serif font is Georgia. It looks great to me. But feel free to use sans-serif and Comic Sans if it suits you.
The space unintentionally left unblank.
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?
Well that's one of the key reasons to convert it - an alternate stylesheet can be provided for PDAs, though I don't know if any actually use it -- but more importantly it will lay out in clean text and respect the semantic structure, showing headlines (H tags), paragraphs, lists, etc., so all the freaks here could check it on their phones and such constantly and it should be good and readable.
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.
i just went to the new slashdot code, and it looks horrible in konqueror. /. code renders fine though.
the actual
this sig limit is too small to put anything good h
um, Slashdot already has an RSS stream that you can parse.
"The absurd is clear reasoning recognizing its limits"
-Albert Camus
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?
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)
The final example uses XHTML 1.0 Strict, even. The logical next step, I think, would be replacing the GIFs with PNGs.
Fast page loads would be one thing. Do a view page sometime and see all the CRAP that is in there. If you could reduce it then you could be speeding up your web viewing (slashdot reading) experience, and unclogging/freeing up Slashdot's bandwidth. Sounds like a win/win to me.
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
If Slashdot is going to be recoded, I would like to ask for four features that are easy to implement, and that would be very nice to have.
1. When you click on your username, you see all of your comments, and next to your comments, you see the number of replies to your comments.
It would be really nice if this number would be clickable, so you could immediately read the replies to your comments. (It's quite complicated to get to the replies now, especially when you've put a high comment threshold in place)
2. Can story submissions be placed (more logically & more conveniently) on people's slashdot-homepages, instead of on the page that you get when you click on "submit story"?
3. It would be nice if you could see your own story submissions (not just the subject, but also the body & other details) when you click on them. Just to see them back.
4. Could the default comment-submission mode be changed to "plain old text" instead of "html-formatted"?
It is confusing that you have to write your own html in a text area on slashdot to get something as basic as newlines, where there is no other site that I can think of - not even a geeky one - that requires you to manually enter the BRs.
It's just not useful, not intuitive and not nice this way.
14 gigs PER DAY savings ????
I do ~90-100 gigs per MONTH and freak out at that.
I will never bitch about my bandwidth use again.
I will never bitch about my bandwidth use again.
I will never bitch about my bandwidth use again.
I will never bitch about my bandwidth use again.
I will never bitch about my bandwidth use again.
I will never bitch about my bandwidth use again.
Only on
While you're updating the (X)HTML to be compliant, why don't you make the search engine actually search? As it is now it's almost completely random as to what you get when you click "search", no matter what you put in the box. I've gotten completely different results just by hitting reload.
- Sherman
Though if you read the blurb you'd notice:
four-figure bandwidth savings in the candidate redesign
Though I personally think Slashdot should look something like this All you aesthetic-less, function-over-form folks who are screaming right now might enjoy the the "LITE" link... though the site is very standards/accessibility friendly and with a pretty face!
Ok, I like ALA, I'm a bit of standards guy even, my whole website is XHTML 1.0 strict. Unfortuanately slashdot has a table based layout, which, to put it simply, CSS cannot handle. I've spent days researching correct CSS tables in the past and it is an impossibility. The problem? Font overlapping. Try a text zoom to as little as 200% (yes, doubling the text size is not that extreme) and most CSS table based designs instantly break. Much like this one. My site works fine with it as everything is position ed such that font size only breaks at absurdly high magnification, but if it were any more complex I'd HAVE to use tables. I don't know if this si a browser issue, or a problem with the CSS spec, but text overflow is a serious issue, one which breaks nearly every CSS page with complex layout in existance. There needs to be a way to style tables in CSS without having to use a table tag. In short, CSS boxes are just that, boxes, they don't link together to correctly handle font sizes. The new slashdot is more broken than the current slashdot in a functional sense.
Photos.
Basicly let me explain what you can do with XSLT. Say you have a table, with 20 plus cells.. This each cell is verticaly listed, has a title and a paragraph. In XSLT all that is required is to have a generic cell and map this to each peice of data in the XML Tree. This cuts down the HTML that has to be transmitted. Sure this was a simple example and a lot of the gains would have been reduced due to the size of XML but in more complex examples XSLT is fantastic for reducing the size of your site. Plus i also believe XML helps for future upgrades because of its flexibility and modular design in comparison to HTML (content and data in the one document).
Also, lets not forget about the advantages of chache. Lets say that each slashdot sections, such as apple, main, apache, books etc use the same XSLT sheet for layout. The XSLT style sheet does not have to be redownloaded for each section. You'd prolly have a seperate CSS document for each section but again, these are very small.
If reduced bandwidth is what you want. You can look past XML+XSLT+CSS!
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
Are you serious? Cause if so, you should be modded up funny.
The example page does look pretty much exactly like the existing Slashdot layout, to which I say job well done. The only problem I see with it is that, at least in IE6, when the window isn't maximized, the category images all crowd up in the visible window and overlap things they aren't supposed to instead of trailing off the visible screen to the right. I don't know anything about advanced HTML, so I don't know whether that's a bug or a limitation of the technique, but it's definitely a big issue, I'd think.
the italic words on slashdot are rendered in bold on konqueror 3.1.4 no matter what font i use. also, the font for comments seem to depend on the general font of X and konqueror. i would prefer if slashdot specified a standard typeface for comments and other aspects of the website. while slashdot loads pretty quick here, i would welcome a fresh look to the website. a better way to view comments would be nice too. the threaded system is cumbersome when there are too many comments. just my $0.02
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.
Apparently you don't feel like looking at the style rules before you criticize them either, as they text sizes are set with keywords and ems, not pixels.
Regardless, you don't have to write an entire stylesheet to get your favorite face and size. Just a simple style rule:
If even that's too much trouble, the link in my previous post also tells you how to set your preferences to override whatever the site specifies for face and size. A couple of mouse clicks and you can have whatever font size and weight you want.
However, someone sufficiently motivated can rip it out and slap in something new. Sometimes people end up rewriting amazing portions of software when it's big enough. I'm not sure slashdot really does enough to warrant that kind of manhandling, it might be better to start entirely over.
But then, I've never looked into slashcode, because while slashdot is a fine site, I would never want to run it. I'll learn a lot more if I write my own code, and I don't have lofty goals for my website.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I tried it on my phone, and the display is lots more readable.
The original version had lots of italics and the text flow wasn't great.
The updated version looked much better (except that the header of the first story was separated from the body by the section nav and poll and stuff)
Handspring Treo 600, blazer browser.
Now there's no reason to fix http://slashdot.org/palm (which doesn't seem to work) to be as good as http://www.wired.com/news_drop/palm looks on a handheld.
Maybe even make it automatic.
And what do you do when the User-agent header is not sent, as would be the case for a proxy cache trying to maximize the number of hits, since it is required that cache hits must match the User-agent exactly if it is sent. Unfortunately, I've seen a few sites where the site code crashes when the User-agent is missing, and in a couple cases, actually gave me crash dump information I'm sure the webmaster would not have wanted anyone to see (e.g. a database access password).
now we need to go OSS in diesel cars
You can do the transformations on the client side. Maybe two setups could be developed, one for those who have XML support on the client side, such as Mozilla based browsers and internet explorer and those who dont for older brwosers...
Simple, XML covers everything! But the idea i like is that if i want i could define my own XSL file for slashdot. Say take the XML code from the web site and format it on my machine so i can read it how i want. Also, this is great for little side bars that just want to summerise the news for the day or the major headings.
So many applications. If slashdot DOES plan to do anything. XML is a must!
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
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."
is that the default comment view (i.e., when you don't have an account) is non-threaded, oldest first. Which is just stupid. People visiting are treated to pages of whatever the current first-post troll is these days.
Switch the default to threaded, highest scores first, and then if a visitor wants a more chaotic view, they can deliberately ask for it.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
> You can do the transformations on the client side. Maybe two setups could be developed, one for those who have XML support on the client side, such as Mozilla based browsers and internet explorer and those who dont for older brwosers...
This is something I *really* want to know more about. I've searched for info on client side XSLT transforms, and haven't really found a lot. I've seen something on mozilla.org, and a tutorial for IE.
Is it possible to just send an XML doc to the client, along with a link to an XSLT, and have it work in IE and Mozilla? Would it be easy for the user to select different XSLT engines? (Preferrably without building it in programatically.)
What's the best source of info on this stuff?
Thanks!
If you're seeing Slashdot as Big5, then that means IE thought that the character frequency matched Big5 most closely.
A sad testament to how bad Slashdot grammar is... Next time someone asks you how bad the writing is on Slashdot, you can tell them "It's so bad my browser thinks it's Chinese!"
That's a good point. I used to host Slashcode based sites. The default home page was around 50k normally, but with mod_gzip it got down to around 6k per page. HUGE savings!
Certainly, caching CSS files locally would save a little in this scenario, but not nearly as much as they say.
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
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.
One line of CSS is 'a bunch of work'? I suppose you find tying your own shoes a pretty onerous task as well?
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?
Following your identical post on ALA the following reply from Marshall Roch
Everything mentioned in these comments are fixable, including Andrew's "CSS tables."
Have a look at http://projects.exclupen.com/slashdot/ (does not work well in IE, but that is fixable if there is interest)
I'm also willing to help get /. up to speed. Where's the best place for interested parties to discuss this further? Please post replies on the ALA forum.
-- thinkyhead software and media
You can have 100% W3C compliant pages, but it is very possible that they will be rendered slightly differently in different browsers (even standards compliant browsers).
/. MSIE only.
For example, I can create a validated XHTML page with one paragraph inside it, and it will look different in Mozilla than what it does in MSIE. Even though Mozilla and MSIE support the standards used to render this one paragraph.
When I create a site, I use font sizes like xx-small, x-small, small, medium, large, x-large, xx-large. (Browsers can dynamically resize these with text size settings, to cater for older people or the visually impaired.)
However the fonts appears bigger in MSIE (or smaller in Mozilla if the glass is half full). The solution is to have another style sheet. If the reported HTTP_USER_AGENT contains MSIE, this style sheet is served after the first, and it makes the fonts in MSIE smaller. For example if the forementioned paragraph was x-small and Arial, the MSIE style sheet would need to specify xx-small - to make the font sizes as close as possible in different browsers.
I'm all for web standards, but a web developer who takes his/her work seriously will seek perfection: identical appearance and functionality in different browsers, using W3C standards.
Nobody was suggesting making
I believe that Konqueror DOES include application/xhtml+xml in its Accept header, but it processes the document using the HTML parser rather than a proper XML parser.
:(
Also, I seem to remember reading application/xhtml+xml pages just fine in Opera.
I used to serve all pages on my site as pure XHTML 1.1, with the correct MIME type and everything, until I realized that I'm one of three people I know who uses a non-IE browser.
You can't really hate Microsoft until you've gotten serious about standards. Then their arrogance shines through.
The US Army: promoting democracy through unquestioned obedience
I hope they implement ASAP.
But there is another challenge, and that's the posts people write. Anybody care about their code? For example, quoting, to do it properly, one should write: <blockquote><p>blah, blah</p></blockquote>. That's an awful lot of typing.
A page is not going to validate unless the posts are correct.
The way I have planned to do this on one of my sites, is to make sure that every time somebody clicks "Preview" or "Submit", the post is handled to Tidy for sanity checks and conversion. By using preview, you can correct you're code, but you can never submit something that isn't well-formed.
I'm using Perl too, not Slashcode, but AxKit. Nevertheless, a good Perl implementation of Tidy is still lacking. There is a HTML::Tidy project page on Sourceforge, but it hasn't really gotten off the ground.
Does anybody else want to work on this, or do you have other ideas for cleaning up posts?
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Actually, you'll have to go back to stuff like Internet Explorer 1.5 and the like to find a browser that doesn't support the basics.
And for the record, PNGs are always smaller, except in a few very special cases which doesn't matter because the absolute size difference is next to nothing in those.
And yes, the PNG-writer in Adobe products is fucking broken last time I checked, and to top it off, many "webdesigners" doesn't understand that PNG supports truecolor, so they'll happily compare their paletted GIF and their GIF saved RGBA and explain the size difference not with "I'm an idiot" but "PNG sucks".
And as for animation.. that's a feature! Personally, I have animated GIFs disabled -- always -- but if you really want to animate pictures you'll use MNG which is animations made out of PNG-images
Belief is the currency of delusion.
That should not be too necessary now, since the patent on GIFs has expired (in the US).
And if you want more information about the Openflows Strict theme, send me email at peter -at- openflows.org :)
IE breaks the standards of the future.
Fixed that for you.
-- Gone Crazy, Back Later
The article suggests as a consequence of the CSS-based implementation that printer-friendly and handheld-friendly views would be available. Now that's surely going to be the killer argument for many of us. How much time would I save if I could read slashdot comfortably on the way to and from work? I'd get my life back finally after five years of being glued to my desk every evening...
Slashdot has never been a pretty site (pun not intended), but a site that has been about content, the whole content and nothing but the content. While huge numbers of tables have a way of eating bandwdth, the html 3.2 works on everything on the planet with the possible exception of Mr. Ozimba's Netscape 1. 419 browser in Nigeria, and it renders damn fast as well, and seems to be pretty much indestructible.
There are bound to be issues with the multitude of browsers available, each rendering even CSS 1.0 in their own inimitable style (pun intended), because what Mac IE5 considers as a box, and what Windows IE5 consider as decent box or text attribute sometimes tend to be entirely different things.
If it works don't break it, I think. Rather fix the search engine.
One of the best reasons for change to this is the layout of the page on small screens. Use of lists and divs and real titles and so on gives products like the Nokia Access Mobilizer (ex Eizel) a much better chance to guess what is going on and reformat the page intelligently.
The worst part is, in Mozilla 1.5, even with Proxomitron turned off, Slashdot renders with a number of noticible and mildly annoying bugs, specifically the center column with the news stories tends to get shifted left by 5-10 pixels, and sometimes the stories with comments display a complete mess.
From the linked page in the parent post on XHTML 1.1 document conformance:
Recommended: yes. Required: not in all situations. The W3C specs are filled with compromises on implementation limitations; they don't often demand that developers fly in the face of established browsers to validate their code. And given that the vast majority of the browser population is the vastly broken IE, it seems an acceptable compromise to send UTF-8 encoded XHTML without an XML declaration.
I know this is Slashdot, so there's no requirement to read an article before posting, but I thought people might at least read their references before posting....
I use this all the time with Smarty output filters.
In development the filters are disabled, when it goes to production they strip white space and single line comments.
Combine that with Smarty caching and phpa and you get dynamic PHP pages that perform like static ones.
YES, Slashdot should definitely be perfectly XHTML compliant. This has the following benefits
./ css
./ become compliant.
1) looks better
2) allows people to easily make custom
3) slashdot can have multiple css to choose from, especially for those of us blinded by games.slashdot.org. Also in Firebird users can switch between the different stylesheets with east
4) people can easily write XSLT stuffs to take slashdot and mix it up.
5) Maybe we can make an RSS that's a little bit better and more customizeable. Doesn't exactly have to do with it, but it's related somewhat.
Yes
The GeekNights podcast is going strong. Listen!
Overflow either chops off the text, lets it overflow, or makes it scrollable. It does not change area size.
Photos.
Of course you can do that. You just include the XSLT (usually .xsl) in your XML file as a processing instruction. For example:
<?xml-stylesheet type="text/xsl" href="test.xsl"?>
The browser then does the transformations for you. I have been messing around with this at work for the last week and I got slightly different results with IE 5.5 and Moz 1.5. Nothing significant though and a bit of messing around sorted it out. You can even get your XSLT tranformation to XHTML to link to a CSS file in the transformation and it works all in one go.
HTML is not a semantic web technology! here's the W3C Semantic Web page. Notice how (X)HTML isn't mentioned?
i don't know who to blame for the propagation of this usage of the word 'semantic,' but i think it might be Jeffrey Zeldman. i like the dude, but this has to stop...
Just raise the taxes on crack.
In most well-designed typefaces, there is a certain amount of built-in space around punctuation glyphs, with the amounts chosen to match the other design characteristics of the characters to maximise reading ease. This gives you, amongst other things, a slightly wider space after a '.' (full stop/period) at the end of a sentence, which in turn gives a natural break while reading without being overly distracting. Note that in most typefaces, two full space characters after a full stop would give an excessively wide space, breaking the reading flow more than necessary, particularly where full justification is in use.
For the same reason, serious typography uses separate characters to represent full stops and (English) decimal place separators, and has another character for ellipses ('...'). If you used the normal full stop character singly as a decimal separator or thrice for ellipses, the spacing would be awkward.
Alas, this sort of detail is the bane of the typographer's life: they spend their days designing typefaces that are easy for you to read, without distracting artifacts, but most people will never appreciate the artistry involved, and only ever notice when they get it wrong.
Obviously, this can't apply when using a monospaced ("typewriter") typeface, because the designer doesn't have the luxury of fine-tuning the widths of characters. This partly explains why reading large blocks of text in a monospaced typeface is difficult for most people, and was also the reasoning behind using two full spaces in that context, although it's unnecessary with good proportionally spaced fonts.
If you'd like more information, you might try Microsoft's excellent Typography web site, or Donald Knuth's works on digital typography if you're really hardcore. There are excellent examples in each case of things that good typography will take into account to make for better readability, and of the distracting effects that can happen if you don't account for them. And as a bonus, once you've read Knuth, you'll know exactly how to typeset "e.g.," using TeX with perfect spacing. =:-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I typically enclose quotations in both <blockquote> and <i> as seen above. Are the <p> tags strictly necessary there? I always thought a block quote was free-standing, though it's possible that either I've just always been wrong or the behaviour's been changed by the more formal specs for later (X)HTML revisions...
(I don't find the extra typing slows me down much when posting, BTW.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Slashcode does indeed use templates, based on the Template Toolkit Perl module. It's actually quite slick.
There's a web-based interface to edit the templates which, IMHO, is a bit less slick, but it works.
(I commercially hosted Slashcode sites for a couple years.)
And indeed, I did exactly that once for a site -- changed a few templates and the resulting site was reasonably standards compliant. Wasn't hard at all. Why Taco hasn't done it here yet is way beyond my comprehension.
is intended to be used for posting code fragments. It uses a monospace font, indents the code fragment automatically, and tries to preserve indentation and whitespace as much as possible. Except that I tried it just now and it appears to be broken, and doesn't preserve indentation at all. Oh well. See the Slashdot FAQ entry on posting modes.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}