Slashdot Mirror
Help Beta Test Slashdot CSS
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!
The "design for all browsers" paradigm isn't a good one. It promotes the use of non-compliant browsers. It's much better to design to the standards no matter what.
Is this in response to that big story last year where someone actually redid Slashdot's main page in CSS to show just how easy it would be to do? Kind of funny in a way because people who usually want to prove how easy something is to accomplish have no idea of just how much glue sits behind the scenes. That's usually what makes these kinds of changes so difficult and fraught with rendering errors, coding slips and the like. Even moreso when you only have a handful of decent people working on the system and a ton of mediocre people making up the majority of the development team. When it comes to systems this big and complicated, it's a wonder they work at all. So who will be making these CSS changes?
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
This has already been done, about two years ago. See http://www.alistapart.com/articles/slashdot2/ and particularly http://www.uwplatt.edu/web/webstandards/slashdot.h tml
Moderate drunk! It's more fun that way!
Um, because:
Of course I know what HTML is. I was trying to be funny (appearently wasted effort). The joke is that HTML is old. For slashdot to only be using HTML makes it old. Something so old that people forgot about it.
Oh nevermind.
"I just want to be able to read articles and comments. Period."
Sure.
But blind / partially sighted / physically disabled folks want to read articles and comments too. Period.
And CSS helps make websites more accessible.
The more advanced the technology, the more open it is to primitive attack
"Design for standards" paradigm isn't a good one. It promotes looking for consultants that won't drive away business.
As x approaches total apathy I couldn't care less.
that has to be the lamest excuse for a list of reasons why not to use something.
Who cares? Three main groups:
People with disabilities prefer CSS because it allows them to trivally alter layout and visual presentation in a way that works for them. For example, some people have trouble seeing low-contrast presentations; they can insert their own CSS into a CSS-aware page to make any site readable.
The folks who pay for the bandwidth tend to like CSS because it costs less to serve (properly implemented, that is). CSS separates style from content, so the style can be cached while smaller content pages are tranferred on request. This makes a better end-user experience and costs less to provide.
Developers and designers like CSS because it follows the excellent practice of separating view from data. It's easier for a developer to make changes to the underlying code because they worry less about breaking the view; likewise, a designer can make layout tweaks without affecting other areas of code. Clean separation makes fewer bugs.
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
Allow me to list people who would be denied the goodness of slashdot if you didn't create something that allowed IE to be compatible:
1) People who for some stupid reason or another can only use IE at work and don't have enough control of their PC to install something better.
2) Geeks and nerds who do not fall into the category of computer nerd. There are science geeks, english geeks, political geeks, math geeks, but just because one is a geek about one thing doesn't mean they are geek about computers.
I'm all for scolding IE for not complying to standards, but since MS's philosophy of embrace, extend and extinguish is still in use in IE, don't allow yourself to be extinguished by designing a page that doesn't work around I.E. bugs and cut off major portions of your audience.
"All great wisdom is contained in .signature files"
This is a site that hires, or at least otherwise uses the services of, Zonk.
And you're surprised they don't test anything?
Y'know, that's a great idea, why target what is most prevalent on the Internet when one can target for some superior solution which NOBODY has completely implemented.
I guess next articles for you are:
ACHTUNG! Das computermachine ist nicht fuer gefingerpoken und mittengrabben. Ist nicht fuer gewerken bei das dumpkopfen.
So I'm going to be modded as flamebait here but um, honestly, "This Rocks"? My first reaction is, ABOUT GODAMNED TIME?
I mean, couldn't they have found any time in the past 8 years of triple posting the same article, not performing any due diligence regarding fact checking, etc... to fucking fix their html???
Thanks Rob Malda et all, welcome to the 21st century!
Mod me down, but you know it's true.
Right, so the intelligent thing would be to explain to my clients that it's Microsoft's fault and not mine that the site I just designed for them doesn't display properly for 9 out of 10 of their customers? After all, I followed the standards and it would be stupid not to!
"Sorry Mr. Client, standards evangelism is far more important to me than your customers. Now, when should I be expecting payment?" Yeah, that'll fly.
I think I'll keep using my current methodology: Design to the standards first, then add whatever hacks are needed to handle the various browser bugs in secondary stylesheets to ensure the widest possible compatability across as many browsers and platforms as I can.
Call me crazy, but keeping the client and their customers satisfied (and, as a result, making the site display properly for as many visitors as I possibly can, rather than just those that use a "standards compliant" browser) and subsequently getting paid for my work is more important to me than beating the standards drum.
I discussed this with a friend some six years ago. The problem with standards like HTML and CSS can be summed up in one word:
MAY
By putting the word may into a standard, you make the standard non-standard. If you can't reliably depend upon CSS to render a dashed line on a border, why do you even provide it? Two completely compliant browsers can give you a different picture, depending on their choice to implement optional components.
There are enough issues with non-compliant browsers that we don't need to build issues into the standards!
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
The figures were three years old, when that article was written two years ago. 3 + 2 = 5, LOL!
Welcome to reading the fucking article.
this is getting insain. Just cause your too young to get the joke doesnt mean 90% of us dont get it.
"Slashdot, where telling the truth is overrated but lying is insightful."
No, you should design for standards, and then sit back and relax. Let it look suboptimal in non-compliant browsers; it'll give them incentive to upgrade.
This, of course, assumes that the bugs in the non-compliant browsers result in only cosmetic defects; however, I would say that if something is so broken in IE that it's genuinely unusable, then you should try approaching the problem in a completely different way.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Absolute nonsense. I implement sites for major commercial organisations which use standards-based CSS 1 and 2.1, and they work just fine cross-modern-browser - IE-Win, IE-Mac, Opera, Firefox, Safari, you name it. And when I say "just fine", I mean "look identical to the pixel", as well as scaling seamlessly for visually impaired users, being fully accessible to assistive technologies, having semantically pure markup and degrading gracefully in ye olde browsers.
On my current project I combine floating, absolute positioning and just about every other CSS technique in the book, and out of 1800+ lines of CSS across the entire site, just 13 are to cater for IE's brokenness.
Everything one needs to know to make standards-compliant sites that work in today's browsers is out there (including avoiding the IE-5-Win box model problem), but many "web designers" are so lacking in an understanding of the technologies with which they work that they can't or won't improve. I see new sites produced using nested tables, for goodness sake; I used those techniques myself last century when there was no alternative, but these people really need to get with the programme.
It's the same problem that leads to so many useless implementations in any field: the vast majority of people are unwilling to undertake a process of constantly improving and refining their skills, and the employers aren't sufficiently well-informed to make the distinction between those who work hard to make the best possible use of the available technologies, and those who read a book about HTML in 1997 and have been marking time ever since.
Luckily things are now changing, and clueful organisations are demanding people who can work with standards. A lot of people who think they understand how to produce a web page are going to be looking for alternative employment over the next year or so unless they catch up on the advances made over the last few years.
</rant>Thank you for listening; have a nice day :-)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
The way I design web pages -- and I'm pretty sure I'm not alone, doing something very radical here! -- is to design for Gecko-based browsers and Safari first, because they very rarely show major deviances from one another or standards. Then I take the design to Windows IE and tweak the style sheets to account for anything that broke there, which is usually pretty minimal--frustrating, but its quirks are known and well documented. And I make sure the page is readable and usable in Lynx. At the end of the day, I have fine standards-compliant XHTML and CSS that works everywhere from Firefox to the Sidekick.
In almost all cases you can make IE happy without having to seriously compromise. There are broken browsers I'm perfectly happy to ignore: pre-Mozilla Netscape, pre-5.0 IE, NetPositive for BeOS, HotJava. These are ones that you simply can't tweak for; generating web pages that renders perfectly on all of those platforms can be done, as OS News proves -- and can only be done by creating hideously bloated web pages where 70-80% of what's being sent to the browsers is markup, as, uh, OS News proves. (The term "pathologically compliant" comes to mind.)
But I think there is a point somewhere in there to be made. Remember HTML 1.0? Simply the fact that tags like STRONG, H1-H6, and ADDRESS exists points pretty clearly to the intent to allow a site to describe what was being presented but allow the browser to determine how it was presented. Of course, there were a load of problems with this and people's ideas of how it should be used, and we like to think we've come a long way. But in truth, we're still doing the same things.
Rather than trying to be the control-freak with everything exactly positioned, it's far more useful (and elegant to program) to have a site which can do without X, Y, or Z and still convey all the information it did before. A site that degrades gracefully may not impress the casual user, but the casual user will be able to use it.
Look at the most successful commercial sites out there today. Google's front page and search results are viewable in every possible browser I can come up with. eBay is one of the ugliest sites in existence, but its content is available to nearly any browser. Hit amazon.com with Lynx and you can still buy things.
Successful web sites are not pretty. They're functional. CSS is a tool to make more functional pages. Yes, you can also make them prettier, but if you set out with that as your goal, you'll fail the more important one.
To a certain extent I aggree with you - especially in regards to certain cosmetic things looking suboptimal in non-compliant browsers. However, this design perrogative is only available when you, the designer, are directly making the calls for what goes and what doesnt. In the case of working for paying clients, or poorly-informed employers with phobias for non-microsoft platforms, this is in many cases not an option. I heartlily beleive that it is our duty as designers and programmers to educate those we work with and for about the reasons for writing standards compliant code, but there will always be times when the end product is simply out of our control (client need intranet site, only uses old Windows boxes for for office machines, won't switch browsers -or- client is extremely picky and the bosses demand his every demand be made, naturally when he pulls his lovely full XHTML/CSS site up in IE on his home machine he is pissed and cannot be reasoned with). This is why I suggest a happy median - structure content with standards-compliant XHTML, and use as much CSS as humanly possible that will work in both browsers. Then, you can always add on some of the lovely options that is available with a browser that supports the full extent of CSS2, and begin making suggestions. That way, even if they don't buy it, you still have a site that conforms to the standard, even if you had to make a few sacrifices to do it (not that there's anything against coming up with a new solution that no one has ever thought of that makes your particular design display perfectly cross-browser). The web is about accessability, and if you loose that, then what's the point?
At the time of this posting, the parent of this post is modded 2, Insightful...
If this is actually important to you use a browser that can override specified fonts.
Thank you,
Everyone else
Extra tags needed to embed scripts? Well, if that's just too much work for you, then stick with HTML. See how much work it is for you in "8-10 years" to convert all of your HTML content to XHTML (and I'm sure it will be sooner than you think). Or, you could just start using XHTML now.
The meat of the original author's argument, that XHTML has no benefits over HTML when served as text/html, doesn't withstand even just a little scrutiny. It has the inherent benefit that it is the only path forward from HTML. There are other lesser benefits as well.
Despite what EULAs say, most software is sold, not licensed.
- The difference between "well-formed" (and by this I think they mean content separated from style) documents and messy table-filled documents where all the styling is in the text is huge. As a developer, it is frustrating at first, but lovely in the long run to have good style imposed on you. The restrictions are light and the benefits are immense
- Case insensitivity in HTML is an unnecessary feature. All it does is make code slightly more confusing and difficult to read.
- Terminating each element is highly desirable, so your document is broken up cleanly into distinct sections, which can be easily identified and consequently rendered. A paragraph break is an event, however, the paragraph itself is an element of the document structure. The <p> and </p> tags signify the beginning and end of each paragraph. Then you can use style sheets to describe how paragraphs should be rendered. If you just want line returns, use <br
/>. - Quoting attributes makes code more clear and less error-prone. When the whole value is in quotes, there is no ambiguity as to what the value should be and what might be a typo or extraneous information. Surely you can imagine a situation where the next bit of text after an attribute would be a valid part of that attribute. and there is ambiguity as a result
- Removal of attribute minimization also just makes fore cleaner, more deliberate code which clears up ambiguity. Surely you cannot be decrying the omission of a feature that you call "brain-dead."
As you can see, XHTML aims to make HTML more clean, standardized, and reusable. It aims to remove ambiguity and clutter from the code and separate the distinct realms of content and design (which is done using stylesheets). No, it is not perfect, but having switched from HTML to XHTML, I find it to be a much more pleasent environment to code in.> No, you should design for standards, and then sit back and relax. Let it
> look suboptimal in non-compliant browsers; it'll give them incentive to
> upgrade.
I take an approach that's sort of a compromise between these positions. First, I design the site using documentation that's based on standards (e.g., the XHTML and CSS documentation at w3schools.com is mostly pretty decent). Then I validate it at validator.w3.org. Then I test it in several web browsers and make sure it adheres to the following:
First, the site should look basically the way I intended it to look in recent versions of Gecko at resolutions from 640x480 through 1600x1200, at 24 bits per pixel. This generally is not a problem.
Second, the site should look reasonable (not necessarily exactly as intended) in the latest version of every major browser that I have at my disposal, at resolutions from 320x200 through 2560x2048, at 16 bits per pixel and higher. (I try to keep a copy of the latest at my disposal for this testing, even though it's usually the hardest one to please, because it's so widely deployed.) The definition of "reasonable" fluxes a little depending on how important aesthetics are to the site and how important the site is to me. Images are allowed to be ugly at 16bpp.
The site must be legible and navigable (i.e., the text can be read and the links can be followed) in all browsers, including really old and crufty and horrible ones, even at very low resolutions, and in 16-color mode (4bpp), and in 256-shade greyscale. It's allowed to look suboptimal, even very suboptimal, but it should be usable. This usually is not a problem with well-designed sites.
I do not attempt to support 1-bit color. Sorry, not going there.
Cut that out, or I will ship you to Norilsk in a box.
Of course if you designed for IE first then detailed what it would cost to make it work on the less popular browsers - very few customers would actually pay for non-IE support.
If your customers only care about IE you are doing the wrong thing and costing them more by designing for 'standards' (which are only one group's perception of the standard) instead of IE which, frankly, is the most popular standard.