Netscape DevEdge Redesigns As Standards ShowcaseWednesday February 12th, 2003Bistronaut 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 Wednesday February 12th, 2003 10:10 PM 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 impresby grayrest Thursday February 13th, 2003 12:52 AM 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.edu/nique/issues/fall1995/oct13/ that I've inherited. Hopefully I won't be so wimply in my site redesign. They explained in the article why they went with Transitional. Next time, try reading the article before showing everyone that you didn't. 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. 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. :) #29 Re: Re: If it validated strict I'd be much more imby grayrest Thursday February 13th, 2003 9:45 PM 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. 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. #28 Re: If it validated strict I'd be much more impresby kberk Thursday February 13th, 2003 9:13 PM 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? 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? 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. ;-) I am sorry but your are incorrect in your statement that DevEdge (devedge.netscape.com) ever required Internet Explorer. XHTML is a more progressive 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. 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. 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. :-) 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). 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 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? 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. 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. 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! "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. 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. They say that they can now easily convert the pages to PDF format for printing, but they don't say how. Does anyone know? This is just a guess but FOP http://xml.apache.org/fop/ would be one option. XML->LaTeX->DVI->PS->PDF would be another. 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. Can't even access DevEdge with Safari. Can someone summarize what's there? 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... |