[seanrg_2000]

<this is more or less a reply to the whole which browser do you use thread>

Which browser do you use? Does it really matter? Seriously, when I view a web page, I expect to see a page, with content, which is browser/environment agnostic.

Web pages should not break in any serious fashion, when using any more or less moderen browser. That's what html is supposed to be about anyway. If I hit the same page with netscape, explorer, omniweb, i-cab, etc. It should look and act more or less the same. When a site has flash as the "main" entry point, they should also provide a pure html entry point as well.

If we focus on browsers, and not about content and compatibitibily, I think we all miss the point of what the web is, and what the standards should mean. Granted, browsers do have bugs, but they shouldn't be released if they simply don't follow standards in main areas. Ignoring things in a browser these days such as css or javascript compatibility is just a waste of everyone's time.

So, what do you think? Browser wars rule the web? Or should the focus be on standards and as much cross platform as well as cross browser compatibility? Me? I choose the later. You? Comments welcome.

Sean

[macvillage.net]

Read: http://forums.macnn.com/cgi-bin/ulti...3&t=000102

[dogzilla]

How far do you think this should extend? AOL 3.0? WebTV? Lynx? Links? Netscape/Explorer 3? What about the PalmOS browser? Galeon or Konqueror? The current iCab (which still has missing features in CSS and Javascript)? Or the current Opera beta? What about audio-browsers for the blind (although I don't even know of any)?

I'm not trying to start a flame, I'm honestly curious as to where you would draw the line - or if one should be drawn at all. Should *all* websites work with *all* browsers, or should some sites target specific browsers depending on their content (say, a PalmOS news site targeting modern browsers and PalmOS browsers).

[macvillage.net]

What is funny is that it is really not hard to adapt most sites to work well with all browsers. It really isn't. The problem is that to many use Dreamweaver, Frontpage, or GoLive with all that IE only CSS code. That is what is causes it. I have (no joke) seen sites that didn't render in anything else than IE 5, looked at the code and saw over 30 lines of CSS to bold headlines in the page.... is that good coding?


A good designer could make a page good in all major browsers... IE, Netscape 3.0, iCab, Opera, OmniWeb.

[dogzilla]

Well, this doesn't really answer my question. I agree that IE 5.x-only sites are a *really* bad idea - but your statement about GoLive and Dreamweaver aren't really accurate. The code they generate works in Netscape 4+ and IE 4+. The WYSIWYG software developers target these browsers because they currently account for about 95% of the web browsing public. Can't speak for other WYSIWYG tools (eg: Frontpage) as I've never used them, but I'm not surprised that a Microsoft-provided tool only works with Microsoft-provided browsers.

Your last sentence states "all major browsers". What does that mean, exactly? IE 6 is starting to appear. What about text-only browsers? And older versions of major browsers (that tail-end of the bell curve, about 2% of web users). And what about Opera - which version? Mac beta? Where do you guys draw the line? This is something I'm struggling with - sooner or later you have to draw the line, whether it's telling a client you can't add features they want or dropping support for some browsers. I'd love to say "Our sites will work on every browser", but that's just not the real world (at least, not with my clients) so in the real world, how do you deal with these issues? Avoid using layers and all animation? Use Flash?

And it *is* a chore to adapt sites to work on all browsers if you use the DOM via Javascript at all.

[TheJoshu]

For general-purpose sites, I think it is far to limit the spectrum of supported browsers to modern, desktop ones - say, Netscape 4.X and IE 4.X and up.

For Palm OS news sites, it makes sense to have at least a version of the site that works with a Palm OS browser. Et cetera.

[Amorph]

Unfortunately, the problem has two sides: Poor HTML and incomplete/buggy browsers. Since this isn't the browser development forum, the only thing under control is generated code.

If there are to be restrictions on which browser can view the site, they should be driven entirely by the nature of the content rather than the presentation. It's ridiculous to restrict content to what can be rendered by WannaBe, but even a site that requires a recent graphical browser and a plug-in or two expect a site that showcases Flash animations should, at the absolute minimum, be designed so that the user of an older (or text) browser is able to navigate around the site, get an idea of what's there and what format it's in, and be able to download - or write down the URL of - anything that their browser can't handle. On the other hand, it's ridiculous to make it impossible for a text only browser to display text, just because of a presentation decision.

Of all the alternatives, I think the least palatable is writing nonstandard HTML code. If you can't stick to the subset of HTML that works consistently at this point, better to put standard code out there so that when the browser companies do support it, they can do so by writing to the spec instead of reverse engineering and hacking until your page displays well. Then check for graceful degradation. It doesn't have to look the same in every browser, only in the ones that adhere to the standards. Just make sure that a Lynx or Netscape 4 user can make heads or tails of the content.

*plink, plink*

[dogzilla]

Amorph -

OK, now that makes sense to me. The content/audience should drive the features of the site. I have two questions, though, and one comment:

Q1) When you say sites should support text-only browsers, what is your approach in implementing this? By using ALT tags and avoiding frames, by using XML or PHP to rewrite code on the fly, or by creating alternate sites? I personally lean toward creating alternate sites and have both call content from PHP/MySQL, as this makes it easy to have the client maintain their own content and also lets me create new interfaces as needed, but I'm wondering if other approaches I haven't tried offer other advantages.

Q2) What do you mean when you say "non-standard HTML"? If it's just the straight HTML, I grok that. But what about Javascript, CSS, and DHTML? Do you strictly avoid it's use? Or do you also use a cutoff for standard HTML support? The W3C doesn't have a lot to say on the DOM, or rather, what it has said hasn't really been implemented by any currently popular browsers (say, any with more than a 1% market share) that I know of.

Comment: You mentioned Flash and other plugin-based content. Have you read that Microsoft has disabled support for *all* netscape-style plugins in IE 5.5 (Service Pack 2) and has disabled (or not included it) in IE 6? Not sure whether this will spread to the Mac version(s), but this means that Microsoft has silently killed Flash, RealAudio, QuickTime, and any other plugins for all Windows users who upgrade to the latest version.

Personally, I'm glad I haven't used Flash very often and instead relied on DHTML when I wanted special effects, but the combination of this and lack of Java in XP makes for interesting times on the web.

[ 08-18-2001: Message edited by: dogzilla ]

[Amorph]

Q1) When you say sites should support text-only browsers, what is your approach in implementing this? By using ALT tags and avoiding frames, by using XML or PHP to rewrite code on the fly, or by creating alternate sites? I personally lean toward creating alternate sites and have both call content from PHP/MySQL, as this makes it easy to have the client maintain their own content and also lets me create new interfaces as needed, but I'm wondering if other approaches I haven't tried offer other advantages.

You know that Lynx handles frames, right? WannaBe doesn't, though.

I mean using ALT tags or plain-text links especially for navigation, and to describe any content you have. You can use a CSS sheet to hide it (CSS1) or eliminate it altogether (CSS2) in newer graphical browsers if you prefer to, or integrated into the page design. The text browsers can all download what they can't display, so all you have to do for non-textual content is make sure there's enough text there to get around the site and figure out what to download, and from where.

Exactly how you'd go about doing that would depend on the content and the page design. Personally, as long as it was done, I don't really care how.

Q2) What do you mean when you say "non-standard HTML"?

Anything that doesn't appear in a standards document. I should have said "non-standard markup" to include CSS and ECMAScript.

I'm thinking of any code which is deliberately broken (relative to the standards) in order to accommodate a bug or omission in a browser implementation.

If it's just the straight HTML, I grok that. But what about Javascript, CSS, and DHTML? Do you strictly avoid it's use? Or do you also use a cutoff for standard HTML support? The W3C doesn't have a lot to say on the DOM, or rather, what it has said hasn't really been implemented by any currently popular browsers (say, any with more than a 1% market share) that I know of.

My reservations about those technologies have more to do with the wildly variable and generally poor quality of their implementation than anything else. When I can expect widespread, competent implementations of CSS and ECMAScript I will be more enthusiastic about them. Their potential is impressive, and CSS in particular results in prettier, more maintainable HTML.

Comment: You mentioned Flash and other plugin-based content. Have you read that Microsoft has disabled support for *all* netscape-style plugins in IE 5.5 (Service Pack 2) and has disabled (or not included it) in IE 6? Not sure whether this will spread to the Mac version(s), but this means that Microsoft has silently killed Flash, RealAudio, QuickTime, and any other plugins for all Windows users who upgrade to the latest version.

They haven't made it so that you can't extend IE for Windows with those applications. They have required that all IE "plugins" use Microsoft's ActiveX API instead of Netscape's plugin architecture. This will not, in itself, have a significant impact on web developers. Apple has an ActiveX version of their QuickTime plug-in in the works.

It will, however, require plug-in developers to maintain an ActiveX version for IE for Windows and a Netscape version for the other browsers, forcing those companies to decide if it's worth it to continue making the Netscape version for some small percentage of the market (and the Operas and Netscapes get to decide whether they want to substantially change their Windows browsers to use ActiveX as well, to avoid getting left behind). Only Windows has ActiveX, so it will be more difficult and more expensive to keep other platforms at parity as well.

[ 08-18-2001: Message edited by: Amorph ]

[macvillage.net]

1. For text only systems such as phones and PDA's, they rely on WAP, which uses WML rather than HTML, so it's a totally different story, and I do have a WAP site for MacVillage.net in the works, but it has been delayed for various reasons.

2. DreamWeaver and GoLive does deliver Netscape 4.x problems, they are not nearly as compatible as they seem. With basic stuff there isn't much of a problem, but with complex pages they are IE only for the most part.


Here is my rubric for my site:

Site will render in a "usable state" with IE/Netscape 3.0 or later, iCab, Opera. That doesn't mean that dHTML functions will work, but the user can navigate the site and view the content (text image etc.)

Page will render Properly in IE 4, Netscape 4, Mozilla, and OmniWeb... I only use code I know will be viewable in all browsers. I do not use IE only tags, or plugins that aren't available to all users.

I use flash sparingly at best so that users with older computers can still view the site. When full flash sites are done, it is impossible for an older computer with limited RAM to go through that... thus a lost audience.


That is really what I am saying. A page should be viewable and usable in all major browsers. If you support IE/Netscape 3.0, you get iCab and Opera Free pretty much.... If you render in Netscape 4.x, most likely IE and Mozilla will have no problem..

Really it's just testing in a variety of systems. Not just an IE/Windows environment. Normally making a site Netscape compatible, means just using a <FONT> tag to bold rather than CSS or something else really minor... it's what separates the web developers from the designers. The designers are concerned with design, and know nothing about the technology factor, while developers are the oposite. I personally am a developer and think that way.

[dogzilla]

Originally posted by macvillage.net:
<STRONG>2. DreamWeaver and GoLive does deliver Netscape 4.x problems, they are not nearly as compatible as they seem. With basic stuff there isn't much of a problem, but with complex pages they are IE only for the most part.</STRONG>

What problems specifically have you seen with Netscape? I've never seen a problem with Netscape 4 (unless you specifically set the program(s) to develop for one browser - but that's pilot error). I have seen problems with Netscape 6 and Opera, but I've always had everything GoLive & Dreamweaver offer work in both Netscape 4.x+ and Explorer 4.x+. I suppose it's feasible that some 3rd-party Dreamweaver/GoLive extensions have problems. These tools certainly don't write compact code, but they do target the major browsers to a fault - they ignore the W3C spec as much as the browser developers do.

<STRONG>Really it's just testing in a variety of systems. Not just an IE/Windows environment. Normally making a site Netscape compatible, means just using a &lt;FONT&gt; tag to bold rather than CSS or something else really minor... it's what separates the web developers from the designers. The designers are concerned with design, and know nothing about the technology factor, while developers are the oposite. I personally am a developer and think that way.</STRONG>

Well, this is certainly true - for a simple site. Anything that is static text in a browser should display on a wide variety of browsers - and frankly, there's not much trick to that. Like you say - it's simple. What does get complex is when you want to animate a layer: suddenly your issues multiply.

And I agree that there's this artificial divide between designer and developer. Personally, I never had much patience for that - I figure you're a lot better off if you can understand and be good at both. I remember seeing/hearing the same stuff when I ran a digital prepress department: the production people and external designer were constantly complaining about each other, until the next generation that could design *and* do production came up through the ranks and took all their jobs. I predict the same thing will happen in the web arena.

[Amorph]

dogzilla wrote:

Well, this is certainly true - for a simple site. Anything that is static text in a browser should display on a wide variety of browsers - and frankly, there's not much trick to that. Like you say - it's simple. What does get complex is when you want to animate a layer: suddenly your issues multiply.

True. So I restrict myself to straightforward layouts. I aim for resizeable designs rather than static ones, and I don't mess with text attributes at all. It means that I have a rather limited palette, but I accept that as the nature of the medium - both by design and by accident.

I'm beginning to work on my first dynamic site, and I'm shunting as much of the work as possible to the server. I know it's theoretically nicer to have the client do some of the work, but after paging through an alarmingly thick JavaScript book and finding out that 2/3 of the text consists of exceptions, workarounds, disclaimers, and bugs for every version of every browser on every platform, I gave up on that idea. It's just not worth it to me to write convoluted, brittle code just to get the cutting-edge (ha! how long has CSS been a standard?) features, especially since most of what I want to offer is text and still images.

[seanrg_2000]

Some good points to deal with. As for me, I code for the html 3.2 standard which has been around for a while. For me, this means that any html 3.2 (or above) compatible web browser will render my site in a consistent manner.

As for users with disabilities, that is spec'd out via the Web Accessibility Initiative(WAI) documentation. A good resource for checking your pages against that specification is Bobby. It's up to browsers designed for users with disabilites to be able to "render" compliant pages.

As far as PDAs/Web enabled handhelds, its been pointed out that they use WAP/WML for display. They do pose a different problem due to the lack of screen real eastate as well as available memory concerns.

If you really want a "run anywhere, under any condition" site, I would personally look at deploying the Cocoon framework on the webserver. Basically, you write your pages in XML which is then transformed via a stylesheet. That way when a specific browser/html version hits a page, the page could be rendered for the level of html or wap/wml that the browser supports. Of course this does mean you need access to a java enabled deployment environment, so not a solution for everyone.

As for javascript, I don't use much of that, since I mostly work with more robust (and more standard) server side solutions (PHP, JSP, etc.).

On a side note, with Microsoft dropping java under XP, well I think they're shooting themselves in the foot on that one. However, there's nothing forcing people to not use Win2k or NT instead.

Sean

[seanrg_2000]

Double post bleh.

[ 08-19-2001: Message edited by: seanrg_2000 ]

[dogzilla]

Sean,

Do you ever hear requests from your clients to use features that can't be handled with HTML 3.2/PHP/JSP? I use PHP pretty extensively, but there's a whole area of functionality that isn't available to PHP (no experience with JSP). For example, a new client recently asked us to redesign and add functionality to a section of their site. They already have an existing framework for their site, but they would like this particular section to get a makeover. Inside their shell, they want some simple animation and a few other features that would be really easy to do with Javascript - if we limit to Netscape 4.7+, IE 4.5+, and compatible browsers. We're discussing with them if they want the tradeoff of a (somewhat) limited audience or the features they want to see. I suspect they're going to choose limiting the browsers, as it doesn't cut off much in terms of viewing public, and the code will work with future (reasonably standards-compliant) browsers. In this case, PHP isn't even an option, because they're hosting their own site.

And concerning WAP and Web Accesibility - my point was, how many of us even consider these methods of access when building web sites? Should we?

[macvillage.net]

As for WAP, yes you should consider being compliant if the site is an information based service like MacNN or ABCnews, or something that is not just a corporate page... It's actually a very unadvertised idea. Most larger sites have a WAP site setup, but don't talk about it.

Again that is the difference between web designers and web developers, developers want 100% of the audience, and want the site plain and simple, while developers are concerned with just looks regardless of audience that can view it.

Now as far as content on a regular page goes, a developer only uses a JavaScript that would work in a 3.0 or later browser (IE or Net) a designer would go with IE 5.5 or later. I personally have never run into a situation where I needed to use IE only code. When something came up that a JS wouldn't cut it, then I have 2 options:
1. Create a JavaScript that has two sub scipts in it, a IE version, and a Netscape version.
2. Use flash! that is what Flash is designed for! It's not meant to be abused, but used to the designers advantage. It's great for stuff that can't efectively be done in any other manner.


Overall, don't code with a higher revision of HTML than you really need to for the job. Don't use excess code for no reason. Again, if the only thing besides for plain text is bolding text, you don't need HTML4, you can do just fine with HTML3!


What I am saying is that a good designer does know how to keep the full audience. I hate sites like Sony.com who have half of it unaccessible because of small features that had to be done using IE5 windows only code. That just shows how bad their web team is.

[seanrg_2000]

Originally posted by dogzilla:
<STRONG>Do you ever hear requests from your clients to use features that can't be handled with HTML 3.2/PHP/JSP? I use PHP pretty extensively, but there's a whole area of functionality that isn't available to PHP (no experience with JSP). For example, a new client recently asked us to redesign and add functionality to a section of their site. They already have an existing framework for their site, but they would like this particular section to get a makeover. Inside their shell, they want some simple animation and a few other features that would be really easy to do with Javascript - if we limit to Netscape 4.7+, IE 4.5+, and compatible browsers. We're discussing with them if they want the tradeoff of a (somewhat) limited audience or the features they want to see. I suspect they're going to choose limiting the browsers, as it doesn't cut off much in terms of viewing public, and the code will work with future (reasonably standards-compliant) browsers. In this case, PHP isn't even an option, because they're hosting their own site.
</STRONG>

Good question.

Clients often request functionality and features that would limit the range of web browsers that could utilize the site fully. The key questions from my perspective in your situation is are would the lack of javascript make the site unuseable, and if so, is there another way to accomplish the same overall idea and functionality?

Since they are hosting their own site, I wouldn't think that adding php to their server would really be much of an issue. Is there a reason they simply can't have a php enabled server? As I've stated before, I believe strongly in using server side solutions whenever they're available. Even if they can't have php on their server is something along the lines of a perl/cgi environment available? Maybe you can utilize that for some of the functionality that they require.

Sean

[Millennium]

I'm not trying to start a flame, I'm honestly curious as to where you would draw the line - or if one should be drawn at all. Should *all* websites work with *all* browsers, or should some sites target specific browsers depending on their content (say, a PalmOS news site targeting modern browsers and PalmOS browsers).

Define "work." In my mind, a site works in a given browser if the user can see all the content (excluding images in browsers which cannot display them) in a manner that makes sense. In this aspect, yes, all pages should work in all browsers.

If you want to define "work" as "look exactly as the author intended," however, then no, all pages shouldn't have to work in all browsers. Thanks to standards, they can be made to work in all browsers, but it would be absurd to have an author try and work this out for every browser/platform/medium combination out there. Your example of a PalmOS site is a good example; obviously, such a site would be targeted for AvantGo (or something similar) on a Palm. But that doesn't mean it shouldn't be at least legible, if not pretty, on some other browser as well; one of your users may need to access it via a desktop machine sometimes, for instance.

[pcp_ip]

if I'm implementing a feature or element that will not be supported 100% by the minority (as in not my target audience) then I still try my hardest to have it "degrade gracefully". It's much better than shutting the odd user out completely.

[ 08-23-2001: Message edited by: pcp_ip ]