Netscape DevEdge Redesigns As Standards Showcase
Wednesday February 12th, 2003
#1 If it validated strict I'd be much more impressed.
by kberk <firstname.lastname@example.org>
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 impres
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.e…ue/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.
by kberk <email@example.com>
Thursday February 13th, 2003 3:39 PM
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
Thursday February 13th, 2003 8:53 AM
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 im
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.
#12 Use of Standards does not require Strict DOCTYPE
Thursday February 13th, 2003 9:49 AM
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 <firstname.lastname@example.org>
Thursday February 13th, 2003 3:42 PM
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 <email@example.com>
Thursday February 13th, 2003 9:13 PM
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
Thursday February 13th, 2003 10:21 PM
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?
Thursday February 13th, 2003 2:52 AM
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.
#4 Why XHTML doesn't used instead of HTML?
Thursday February 13th, 2003 5:14 AM
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.
#20 Re: Why XHTML doesn't used instead of HTML?
Thursday February 13th, 2003 12:51 PM
#5 Site is unusable in Konqueror (KDE 3.0.4)
Thursday February 13th, 2003 6:26 AM
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
Thursday February 13th, 2003 10:03 AM
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...
Thursday February 13th, 2003 7:34 AM
#10 Re: This is great and all, but...
Thursday February 13th, 2003 9:15 AM
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 ...
Thursday February 13th, 2003 10:00 AM
Check it out for yourself.
#21 I know the menu's work...
Thursday February 13th, 2003 12:58 PM
#26 Re: I know the menu's work...
Thursday February 13th, 2003 7:00 PM
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...