NYTimes.com Hand-Codes HTML & CSS 496
eldavojohn writes "The design director of NYTimes.com, Khoi Vinh, recently answered readers' questions in the Times's occasional feature 'Ask the Times.' He was asked how the Web site looks so consistently nice and polished no matter which browser or resolution is used to access it. His answer begins: 'It's our preference to use a text editor, like HomeSite, TextPad or TextMate, to "hand code" everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results.'"
Works for me too (Score:2, Interesting)
I find that hand-coding works for HTML/CSS, provided of course you include it in a scripting language like PHP.
It's less work than it sounds and the results DO look better - you get a more original look and things can be made to look exactly how you want, instead of being restrained by the wysiwyg software's design limitations.
I have new respect for the NYTimes (Score:1, Interesting)
Registration evils aside, that's a viewpoint I can respect. I was taught to code webpages when my father handed me an HTML manual and taught me how to look up the source code of a webpage that did something I liked (I was probably 10). This was long before CSS, but I learned those the same way.
I can't say my webpages are as elegant or polished as NYTimes.com, but I'm sure they work on every browser. What's important is that I understand how and why they work.
I also recently inadvertently triggered an argument between my parents on the virtues of IDEs in software development. My dad likes them, my mom regards them as the bane of true programmers everywhere. What does /. think?
Benefits vs Issues (Score:2, Interesting)
1. Handcoding takes a lot more effort and needs more 'actual' writers than before. So more techies keep their jobs in a recession.
Score: Hancoding 1: Dreamweaver: 0
2. Hancoding requires extensive knowledge of all CSS and DHTML codes plus javascript/JScript. So only the really good techies get the job, and not some script monkey. Survival of fittest.
Score: Hancoding 2: Dreamweaver: 0
3. Handcoding takes far more time than is necessary in a changing scenario of today's news. Effort not proportional to returns. As a shareholder, i would sue them for wasting money.
Score: Hancoding 2: Dreamweaver: 1
4. Dreamweaver allows preview easily and pretty much automates repeatable tasks. Handcoding requires a Mechanical Turk.
Score: Hancoding 2: Dreamweaver: 2
So its a tie.
I appreciate NYTimes sticking to manual tasks for an electronic page as an end user and a techie.
I hate them for wasting my money as a shareholder.
Dreamweaver is an excellent tool (Score:5, Interesting)
1. DW lets you code at the source code level if you choose.
2. DW is much faster--in Design View--at creating tables.
3. DW allows for flipping back and forth or split view.
4. DW does not rewrite your code (for the most part).
I use DW every day. I am not even conscious of flipping between the 2 views. Some things are done better in Design View and some in Code View.
CSS support is very good in DW.
Well it looks great (Score:3, Interesting)
The re-design they did a couple years ago is a pleasure to navigate, to read (I love the fonts) and while the photos are always top notch, I must say the award goes to whoever makes the graphs. They have the most fantastic and unique ways of presenting data - far beyond a boring Excel bar graph. I am really really impressed by the interesting and informative graphs which are often highly interactive, and I would love to know who thinks them up.
At the end of the day, they use templates (I believe he says as much in TFA, IIRC, I read it a week or so ago) and hand tweak the site to make it sure it stays cross-platform pretty. Each story has a similar layout so it can't be hard for them to simply tweak by hand where needed.
Re:W3C (Score:3, Interesting)
Link Management (Score:3, Interesting)
As much as it may work in principle to build highly optimized pages by hand markup, it must be a nightmare to make any changes to something as tightly constructed as a hardwired web site.
Re:Dreamweaver is an excellent tool (Score:3, Interesting)
1. DW lets you code at the source code level if you choose.
2. DW is much faster--in Design View--at creating tables.
3. DW allows for flipping back and forth or split view.
4. DW does not rewrite your code (for the most part).
I use DW every day. I am not even conscious of flipping between the 2 views. Some things are done better in Design View and some in Code View.
CSS support is very good in DW.
2. Nobody uses tables anymore, at least not as much as they incorrectly used to before for formatting since CSS gives you a lot more control. This practice thankfully died out.
3. Alt-Tab is just as fast if you have your browser open, or multiple browsers. I usually check IE and FF when I'm working on layout.
4. For some people, even a little bit of code changes is too much.
If I'm working on a php or jsp page that retreives content from a database how does DreamWeaver get it? Does it have a php engine or a servlet engine? If I want to include a page fragement from a php or jsp page or text from a java bean can it do that?
Back when I was playing around with it, it couldn't do any of that. Even if it can now, I'm better off testing it directly in the servlet engine or php/apache setup I plan to deploy on to make sure there are no problems with db connections, unexpected session behavior, etc.
When dealing with sites that have a lot of dynamic content and or more complex interactive attributes, like more and more sites are having, DreamWeaver seems to get in the way for me. I have, on ocassion used it to generate the initial design and then cut and paste the pieces in the appropriate php/jsp files then work from there. It never seemed necessary though.
It's not a big deal to install Apache, mod_php, tomcat, database on a development server or even locally to be able to test things out in a real environment.
For simple sites, or for the initial design of the site it may have it's place but for me that's not worth the price.
Valid Markup != Good Code (Score:5, Interesting)
In the real world us web developers have to deal with interoperability on many different levels. We have to make sure the layout looks the same on Internet Explorer, Firefox, Opera, and Safari with Windows XP & Vista, OSX, and Linux using the same code base. Most of this however has a lot to do with how talented your CSS developer is. And unfortunately for you kiddies, any less isn't perfect.
So to spell it out for those that don't know, here's the real difference between WYSIWYG and pure text:
In a WYSIWYG editor you tend to do everything the same way every time you do it. That means that all your links, images, and code snippets come from the same code base and therefore have all the same pitfalls and good points. Unfortunatly the wonderful world of DOM doesn't work that way. HTML, CSS, JavaScript, and objects like Flash, Quicktime, and Java have very specific ways that they interact with each other and the browser and so what you generally find is that the reason you code by hand is not for the specific reason of coding by hand but simply put you really can not build good, quality websites with WYSIWYG editors. At some point you will most assuredly find yourself digging in the HTML.
Finally, on the topic of validating your markup. The Markup validaters that are out there are only good as tools of the trade and shouldn't be used as the end-all be-all certification of quality markup. They are tools that should be used by a web developer to run through and make sure they can be as close to valid as possible but I am willing to bet that out of the top 100 sites on the internet, the front page of all of them will produce Markup validation errors. The reason is simple: The validation rules are so restrictive that there is no point even worrying about them. It would be impossible to make a working website by being totally loyal to the markup rules.
Especially with the validator's stupidity in treating & signs in the href attribute of my a elements as the beginning of an entity which it's not!
Re:W3C (Score:5, Interesting)
53 walmart.com
36 exxon.com
26 chevron.com
33 gm.com
76 conocophillips.com
0 ge.com
29 ford.com
52 citigroup.com
105 bankofamerica.com
26 att.com
28 www.berkshirehathaway.com
8 jpmorganchase.com
148 aig.com
55 hp.com
0 ibm.com
144 valero.com
2 verizon.com
180 mckesson.com
5 cardinalhealth.com
1082 www.goldmansachs.com
Re:Well it looks great (Score:3, Interesting)
Summary: "A good graphic can tell a story, bring a lump to the throat, even change policies. Here are three of history's best."
Re:Valid Markup != Good Code (Score:3, Interesting)
You're right about valid code being rare, but wrong about the reason. Sturgeon's Revelation applies to developers.
That's not even close to being true. Take the NYTimes for example. Would you care to point out a syntax error they've made that is actually necessary, where the valid alternative wouldn't work?
The same goes for those "100 top sites" you mentioned. They aren't invalid because valid code is impossible to get working, they are invalid due to apathy and ignorance. In practically every case, you could take a mildly competent developer, throw the code at him, and have it valid in next to no time. Hell, in many cases, a program can do it automatically! The cases where invalid code is actually required to achieve a particular effect are far and few between these days.
The validator is completely correct. That's a syntax error and the job of a validator is to point out syntax errors to you.
Re:Valid Markup != Good Code (Score:3, Interesting)
Re:Works for me too (Score:3, Interesting)