MozillaZine

Netscape DevEdge Redesigns As Standards Showcase

Wednesday February 12th, 2003

Bistronaut writes: "Netscape DevEdge has been redesigned to use CSS for layout. It has CSS menus (turn off JavaScript and try them!), multiple styles and (best of all) looks great." The Netscape Evangelism team have published a page all about the DevEdge redesign.


#1 If it validated strict I'd be much more impressed.

by kberk <kberk@bigfoot.com>

Wednesday February 12th, 2003 10:10 PM

Reply to this message

If you want to demonstrate the capabilities of standards based pages, then you have to write to the stirict doctype.

#2 Re: If it validated strict I'd be much more impres

by grayrest

Thursday February 13th, 2003 12:52 AM

Reply to this message

I agree. The first thing I thought when I read 4.0 Transitional was "wimps". They don't even have pages like <http://cyberbuzz.gatech.e…ue/issues/fall1995/oct13/> that I've inherited. Hopefully I won't be so wimply in my site redesign.

#6 Don't be a lazy reader

by amutch

Thursday February 13th, 2003 6:38 AM

Reply to this message

They explained in the article why they went with Transitional. Next time, try reading the article before showing everyone that you didn't.

#24 transitional/xhtml

by kberk <kberk@bigfoot.com>

Thursday February 13th, 2003 3:39 PM

Reply to this message

They addressed why they used HTML 4.01 transitional instead of XHTML 1.0 transitional. I did not see anything about transitional versus strict.

Web standards are moving to strict mode. XHTML 2 will not have any of the legacy transitional tags. Its not like strict doctypes are new. HTML 4 has been out for a long time now.

#8 The front page does not validate

by deelan

Thursday February 13th, 2003 8:53 AM

Reply to this message

<http://www.deelan.com/weblog/message.m?id=11>

by the way this morning i've sent an email to feedback @ devedge and received now a reply by the guys. they are working on it. :)

#11 validation errors

by rdc

Thursday February 13th, 2003 9:45 AM

Reply to this message

The missing ALT attribute on the image and the meta tag mistakes have been fixed.

#29 Re: Re: If it validated strict I'd be much more im

by grayrest

Thursday February 13th, 2003 9:45 PM

Reply to this message

Looking back on this, it's a bit harsh. I know it's difficult to convert legacy content and applaud the amount of work they've done to move to a more modern layout. I shouldn't post after midnight.

#12 Use of Standards does not require Strict DOCTYPE

by rdc

Thursday February 13th, 2003 9:49 AM

Reply to this message

Our pages use an HTML 4.01 Transitional DOCTYPE with URI which in Mozilla/Netscape Gecko produce a page which invokes "Almost Standards" mode and in IE6 produce a page in CSS1Compat mode.

There is no absolute requirement to use Strict in order to get Standards. An HTML 4.01 Strict DOCTYPE has several restrictions that we did not wish to encur. HTML 4.01 Transitional with URI was perfect for our needs.

#25 OK, point taken

by kberk <kberk@bigfoot.com>

Thursday February 13th, 2003 3:42 PM

Reply to this message

But, lets keep in mind that transitiional tags are GOING AWAY. XHTML 2 will not have them.

The goal of this changes seemed to be to show people what web standards can do. In that context, it only makes sense to push the envelope by moving to strict doctypes with CSS and DOM.

#28 Re: If it validated strict I'd be much more impres

by kberk <kberk@bigfoot.com>

Thursday February 13th, 2003 9:13 PM

Reply to this message

OK,

Sorry this was so negative. Clearly there was quite a bit of work invovled in the site redesign. It is impressive that you got rid of all the table based layout and replaced it with stylesheets. I don't envy you the number of hours it must have taken to undertake the effort.

I guess I was just a bit surprised that you went so far, but did not go strict. I'm curious about what restrictions prevented you from using the strict DTD?

#30 To be strict or not to be strict

by rdc

Thursday February 13th, 2003 10:21 PM

Reply to this message

Well, it is a good question and actually one that I personally didn't spend a lot of time on.

<http://www.w3.org/TR/html401/conform.html#h-4.1> recommends that we all use strict rather than other DOCTYPEs. So, I guess we missed the boat on that one.

I don't think we ever really considered using strict since much of our older content would not validate strict and may not even validate as transitional.

Another consideration is the limitation of our build environment. Although our raw HTML documents have a template applied to them that preserves the DOCTYPE and thus would allow different HTML documents to have different DOCTYPEs, our newer content is actually contained in an XML format that allows us to record meta data along with the HTML markup for the content. This is transformed via XSLT into HTML and by definition uses the same output DOCTYPE for any document of a given type. Given the varied authoring styles in our team, it would have added even more complexity to our project than what we experienced. Considering the broken builds due to not-well-formed XML, and the fact that I can't get them to use Unix line endings, strict DOCTYPEs would have made the process even more painful.

I think that we never really considered strict and were mostly concerned about invoking standards mode and using CSS 2 in our layout.

What are the benefits of strict that we missed out on by going with transitional?

#3 Halla-freakin'-lullah!!

by DeepFreeze3

Thursday February 13th, 2003 2:52 AM

Reply to this message

It's about freakin' time!! Until recently, that site wasn't truly based on open standards, only being able to be viewed correctly in IE (UGH!!) I guess somebody over there took their head out of their ass and saw the light of day. ;-)

#13 DevEdge never required IE

by rdc

Thursday February 13th, 2003 9:51 AM

Reply to this message

I am sorry but your are incorrect in your statement that DevEdge (devedge.netscape.com) ever required Internet Explorer.

#4 Why XHTML doesn't used instead of HTML?

by sinchi

Thursday February 13th, 2003 5:14 AM

Reply to this message

XHTML is a more progressive

#14 Why use XHTML?

by rdc

Thursday February 13th, 2003 9:59 AM

Reply to this message

I think the better reason is to ask yourself why you would want to use XHTML. XHTML is not supported in Internet Explorer unless you serve it as text/html. Content-type text/html invokes the HTML parser in Mozilla and you do not really get the benefits of XHTML because of that.

Since XHTML as it is currently used on the web is really just HTML and not XML or XHTML, you up seeing pages like <http://www.zeldman.com/> where he uses SGML comments to hide CSS Rules from downlevel browsers. That is fine if your page is served as text/html, however it will break Mozilla / Netscape-Gecko if you serve the page as text/xml or application/xhtml+xml. This same error has been evident on the W3C pages as well.

I think that the current state of the web is that XHTML is useful as a namespace in XML documents and can be reasonably be accessed by Mozilla / Netscape Gecko however XHTML as text/html is just being "cool' with no benefit.

#20 Re: Why XHTML doesn't used instead of HTML?

by bzbarsky

Thursday February 13th, 2003 12:51 PM

Reply to this message

#5 Site is unusable in Konqueror (KDE 3.0.4)

by Schnacki

Thursday February 13th, 2003 6:26 AM

Reply to this message

I just visited the site using Konqueror from KDE 3.0.4 and couldn't navigate the menu at all. Having JS activated, the top-menu-items, which are rendered in a vertikal list rather than horizontally, are hidden by the dropdown-elements, and after disabling JS I didn't get any submenus at all.

#16 Site not supported by Konqueror/Safari etc

by rdc

Thursday February 13th, 2003 10:03 AM

Reply to this message

Sorry about that however I have hope that with the new developments in this area your browser will soon support the standards sufficiently to use the site fully.

We finally bit the bullet and designed a site that is best viewed using a modern, standards-based browser. Since you are on mozillaZine, I assume you have access to one. :-)

#7 This is great and all, but...

by bmacfarland

Thursday February 13th, 2003 7:34 AM

Reply to this message

I still know a lot of people that disable javascript on their browser. It sounds like a lot of the features rely heavily on javascript (I'm thinking the user selectable styles here). In one sentence, they that they want it to work for 'alternative' browsers like those on handhelds (of which Blazer on my Treo 300 would qualify), but some (i.e Blazer) don't support javascript. I don't need to have all the customization features on my handheld (except maybe to shut off images, which would be nice), but I have to be sure that it's going to it's going to navigate decently (or at least in some logical form).

#10 Re: This is great and all, but...

by WillyWonka

Thursday February 13th, 2003 9:15 AM

Reply to this message

You can still select alternate stylesheets without javascript. It just won't remember the change from page to page. Instead of using the customize button on the page, use the view menu instead and then change pages.

You can see the same thing on the mozilla 1.0 start page... <http://www.mozilla.org/start/1.0>

#15 close to what I'm looking for, but ...

by bmacfarland

Thursday February 13th, 2003 10:00 AM

Reply to this message

I don't think the average user is likely to go to View --> Use Style --> [select sheet]. When you put in on the page itself it stands out and people can use it. I would have some server-side scripting language (coldfusion or php) at my disposal. I couldn't think of a way to make it work as clean, because you'd have to reload the page, when someone clicks on the customize features unless you use javascript, right?

#17 JavaScript not required

by rdc

Thursday February 13th, 2003 10:07 AM

Reply to this message

In Mozilla / Netscape Gecko you can get the full menu experience even if JavaScript is disabled. In Internet Explorer you wont get the pull down menus with JavaScript disabled but you will still be able to navigate the site and suffer no real harm. For text based browsers, such as Lynx the site is fully accessible.

Check it out for yourself.

#21 I know the menu's work...

by bmacfarland

Thursday February 13th, 2003 12:58 PM

Reply to this message

The article said that the menu's work. I'm not sure the customization box does though. I'm really looking to get teh customization box to work without javascript. I haven't tried it, maybe it does, though for this minute I need javascript to do my work, I'll check it out later tonight.

#22 by the way...

by bmacfarland

Thursday February 13th, 2003 1:01 PM

Reply to this message

I didn't mean to imply the menus didn't work without javascript. It was pretty clearly stated in the article that they did with browsers with CSS2 support. I haven't looked at the code behind it, but that sounds like a tremendously well done job!

#26 Re: I know the menu's work...

by WillyWonka

Thursday February 13th, 2003 7:00 PM

Reply to this message

"I'm really looking to get teh customization box to work without javascript."

The customize box sets a cookie with a flag for which stylesheet it should use. How would you create a cookie without JavaScript? It also, on load, looks at the value in the cookie and through code, turns the alternate stylesheed on. There is no way that I know of to do that without scripting.

#27 well...

by bmacfarland

Thursday February 13th, 2003 8:26 PM

Reply to this message

I sort of kludged together a server-side script (in coldfusion, but you can take your pick) that made the bigger and smaller icons load up the same page, but with a variable attached that would trigger the bigger or small font. Bingo, no javascript, but it leads to ugly URLs. My next idea is to have a part of the site that lets you configure it all at once and then save your settings as a cookie all using the server-side scripting language to write the cookies.

I have to plead a lot of ignorance to how the server-side scripting writes cookies behind the scenes. Maybe it all boils down to javascript.

#9 XML -> PDF

by WillyWonka

Thursday February 13th, 2003 9:11 AM

Reply to this message

They say that they can now easily convert the pages to PDF format for printing, but they don't say how. Does anyone know?

#19 Re: XML -> PDF

by stu42j

Thursday February 13th, 2003 12:07 PM

Reply to this message

This is just a guess but FOP <http://xml.apache.org/fop/> would be one option. XML->LaTeX->DVI->PS->PDF would be another.

#23 FOP

by doron

Thursday February 13th, 2003 2:15 PM

Reply to this message

We use a JAVA FOP impl. to do it. I wrote a XSL:FO stylesheet that creates a pdf looking more or less like the current site.

#18 Needs better usability

by FattMattP

Thursday February 13th, 2003 11:13 AM

Reply to this message

It may technically correct, but it's still using hard coded font sizes instead of relative font sizes. They need to get rid of the point and pixel specifications and replace them with percentages for the font-sizes. Right now it overrides my default font size settings in my browser unstead of scaleing gracefully like MozillaZine does.

#31 No Safari either

by pbreit

Thursday February 13th, 2003 11:19 PM

Reply to this message

Can't even access DevEdge with Safari. Can someone summarize what's there?

#32 silly text resizer

by mlefevre

Friday February 14th, 2003 9:39 AM

Reply to this message

generally cool, but the one thing I don't like is the text resizer. their resizer widget requires script, which some people have disabled, and the way it works means that IE and Mozilla/Netscape's own text-resizing doesn't work (IE's doesn't work at all because the font sizes are fixed, and resizing in gecko screws up the layout). I can see that it might be nice to enhance browser's resizing, but better to have simple sites where the browser's builtin stuff works, rather than have every web site out there doing their own thing so users have to download and figure out lots of different resizer widgets...