Speaking of hacks, here is an example of what I was talking about. It is from the <www.digitalmedievalist.org> website's screen css http://www.digitalmedievalist.org/dmlscreen.css.
b) Screen Geography */
div { /* controls width and location of all blocks except div.navigation and children */ margin-left: 20%; max-width: 35em; top: 0; }
div.navigation { margin-left: 0; position: absolute; /* position: absolute is for MSIE only; the style is removed below */ top: 15px; left: 4px; width: 18%; }
/* MSIE workaround */ /* This instruction hides "position:fixed" from MSIE5.5~6.0 */ body>div.navigation { position: fixed; }
This is a harmless enough hack, I suspect (it would be better if the second instruction referred to "body div.navigation" to keep the two instructions exactly parallel). Currently it works; if MSIE later implements the > child rule, then it won't work for MSIE anymore, and users of MSIE will end up with scrolling navigation. I am beginning to wonder if it is not better, however, to design a sheet to the standard, and then allow users of MSIE to choose a simpler sheet if some effect doesn't work well in their browser. Comments? -dan
On Monday, June 28, 2004, at 10:34 AM, Daniel O'Donnell wrote:
I am beginning to wonder if it is not better, however, to design a sheet to the standard, and then allow users of MSIE to choose a simpler sheet if some effect doesn't work well in their browser. Comments?
i'm all in favor of user choice, as long as it doesn't get confusing. just remember that most users will use whatever you've got set as the default. i would just rather see user choice for the sake of the users than users having the choice of fixing their browser's poor implementation of standards.
j
Il lun, 2004-06-28 alle 17:58, Jeffrey Fisher ha scritto:
On Monday, June 28, 2004, at 10:34 AM, Daniel O'Donnell wrote:
I am beginning to wonder if it is not better, however, to design a sheet to the standard, and then allow users of MSIE to choose a simpler sheet if some effect doesn't work well in their browser. Comments?
i'm all in favor of user choice, as long as it doesn't get confusing. just remember that most users will use whatever you've got set as the default. i would just rather see user choice for the sake of the users than users having the choice of fixing their browser's poor implementation of standards.
I fully agree. Leaving the users a "choice", in this case, means that the developer doesn't dare make a choice himself. Good user interface design often simply means choosing sensible defaults, and not bothering the user with the notion of different stylesheets for different, non standard complying, browsers. In an ideal world, at least ... :)
I've heard that MS finally decided to revive the IE development group, and that the main developer has shown some willingness to listen to suggestions, provided that they're not as generic as "better compliance to web standards": I wonder why he chose this particular example!
Ciao
So is the feeling that providing, say, a stylesheet that handles the most important visually impaired demands (e.g. underlining and whatnot) is a good idea? Or should that also be left up to users, who may have unusual needs and well-developed personal stylesheets?
Roberto Rosselli Del Turco wrote:
Il lun, 2004-06-28 alle 17:58, Jeffrey Fisher ha scritto:
On Monday, June 28, 2004, at 10:34 AM, Daniel O'Donnell wrote:
I am beginning to wonder if it is not better, however, to design a sheet to the standard, and then allow users of MSIE to choose a simpler sheet if some effect doesn't work well in their browser. Comments?
i'm all in favor of user choice, as long as it doesn't get confusing. just remember that most users will use whatever you've got set as the default. i would just rather see user choice for the sake of the users than users having the choice of fixing their browser's poor implementation of standards.
I fully agree. Leaving the users a "choice", in this case, means that the developer doesn't dare make a choice himself. Good user interface design often simply means choosing sensible defaults, and not bothering the user with the notion of different stylesheets for different, non standard complying, browsers. In an ideal world, at least ... :)
I've heard that MS finally decided to revive the IE development group, and that the main developer has shown some willingness to listen to suggestions, provided that they're not as generic as "better compliance to web standards": I wonder why he chose this particular example!
Ciao
Il lun, 2004-06-28 alle 19:59, Daniel O'Donnell ha scritto:
So is the feeling that providing, say, a stylesheet that handles the most important visually impaired demands (e.g. underlining and whatnot) is a good idea? Or should that also be left up to users, who may have unusual needs and well-developed personal stylesheets?
Again, I think that catering for special needs, or simply trying to conform to accessibility guidelines, should be the developer's task, on the basis of the anticipated audience. And you can also see why imposing choices on the users is a bad idea: while you probably should keep in mind accessibility everywhere, it could make sense to propose a special version of your site (lighter on resources, for instance, or conceived for PDA browsers, etc.), but if you already have to propose a version for "normal", standard-complying browsers, and another for IE, this probably is not feasible, or would result in a scarcely maintainable site.
Ciao
Hi there,
At 01:40 AM 30/06/2004, you wrote:
I think that catering for special needs, or simply trying to conform to accessibility guidelines, should be the developer's task, on the basis of the anticipated audience. And you can also see why imposing choices on the users is a bad idea: while you probably should keep in mind accessibility everywhere, it could make sense to propose a special version of your site (lighter on resources, for instance, or conceived for PDA browsers, etc.), but if you already have to propose a version for "normal", standard-complying browsers, and another for IE, this probably is not feasible, or would result in a scarcely maintainable site.
I think it's good to strike a balance here. On our Introduction to Hul'q'umi'num' site (http://web.uvic.ca/hrd/hulq/) we let the user choose which audio file format and media player they prefer to use, then store that in a cookie and use it to insert the appropriate media player code for every audio link. We determined this would be the best way to handle the fact that there are no real standards for media files on the Web, and a range of players is available; it's unreasonable to require people to install a particular player just to use one site, so we let you choose between WMP, Real, Flash and Quicktime, and between .wma, .ra, .mp3 and .ogg files. This pretty much ensures that anyone can use the audio material without installing anything special (we hope!).
We also allow people to decide where they'd like to put the navigation menus on the page, and give the option of a high-contrast colour scheme, or a print stylesheet for the pages (which is monochrome, without navigation). All of this is done through JavaScript and cookies, and the individual pages themselves do not need to be changed; the JavaScript reads the cookies and makes changes to the DOM when the page is loaded or when the user chooses an audio segment to listen to. All of this is done client-side, so the site can be run from a CD, or a server with no available scripting, if necessary.
This kind of flexibility is fairly easy to incorporate in a site nowadays. However, the issue of PDAs is a slightly different one; PDA browsers are porrly-featured in terms of CSS, JavaScript and DOM support, so unless a site is very simple indeed, any special version of it for PDAs currently has to be created server-side. In a couple of years, though, PDAs will be running the equivalent of the current FireFox, I think, and most things we do now for desktop browswers will be practical for PDAs.
But then we'll have the legacy installed base of old PDAs to worry about...
Cheers, Martin
______________________________________ Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
This is neat. I was thinking of something very similar using cookies, though I hadn't thought of using a form to allow users to select several options (my plan had been to offer a selection of different sheets: large screen, small screen, accessibility). Are there generalisable scripts on this project that might usable by other members of the list? -dan
Martin Holmes wrote:
Hi there,
At 01:40 AM 30/06/2004, you wrote:
I think that catering for special needs, or simply trying to conform to accessibility guidelines, should be the developer's task, on the basis of the anticipated audience. And you can also see why imposing choices on the users is a bad idea: while you probably should keep in mind accessibility everywhere, it could make sense to propose a special version of your site (lighter on resources, for instance, or conceived for PDA browsers, etc.), but if you already have to propose a version for "normal", standard-complying browsers, and another for IE, this probably is not feasible, or would result in a scarcely maintainable site.
I think it's good to strike a balance here. On our Introduction to Hul'q'umi'num' site (http://web.uvic.ca/hrd/hulq/) we let the user choose which audio file format and media player they prefer to use, then store that in a cookie and use it to insert the appropriate media player code for every audio link. We determined this would be the best way to handle the fact that there are no real standards for media files on the Web, and a range of players is available; it's unreasonable to require people to install a particular player just to use one site, so we let you choose between WMP, Real, Flash and Quicktime, and between .wma, .ra, .mp3 and .ogg files. This pretty much ensures that anyone can use the audio material without installing anything special (we hope!).
We also allow people to decide where they'd like to put the navigation menus on the page, and give the option of a high-contrast colour scheme, or a print stylesheet for the pages (which is monochrome, without navigation). All of this is done through JavaScript and cookies, and the individual pages themselves do not need to be changed; the JavaScript reads the cookies and makes changes to the DOM when the page is loaded or when the user chooses an audio segment to listen to. All of this is done client-side, so the site can be run from a CD, or a server with no available scripting, if necessary.
This kind of flexibility is fairly easy to incorporate in a site nowadays. However, the issue of PDAs is a slightly different one; PDA browsers are porrly-featured in terms of CSS, JavaScript and DOM support, so unless a site is very simple indeed, any special version of it for PDAs currently has to be created server-side. In a couple of years, though, PDAs will be running the equivalent of the current FireFox, I think, and most things we do now for desktop browswers will be practical for PDAs.
But then we'll have the legacy installed base of old PDAs to worry about...
Cheers, Martin
Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
dm-l mailing list dm-l@uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l
Hi there,
You're very welcome to use any of the code you find on the http://web.uvic.ca/hrd/hulq/ pages related to the stylesheet handling and the audio stuff. Neither Opera nor Safari actually allow manipulation of the stylesheet array yet, so stylesheet switching doesn't work in those browsers; Firefox/Moz and Opera do let you switch between stylesheets manually in the browser itself, but they only let you choose one, rather than allowing a cascade, so the effect isn't great because some of our "presets" depend on several stylesheets being active together. Neither IE nor Safari allow stylesheet selection in the browser.
The head of the page contains this kind of thing:
<link rel="stylesheet" title="Basic" type="text/css" href="../../style.css" /> <link rel="stylesheet" title="Alternative" type="text/css" href="../../alternative.css" /> <link rel="stylesheet" title="NavLeft" type="text/css" href="../../nav_left.css" /> <link rel="stylesheet" title="NavRight" type="text/css" href="../../nav_right.css" /> <link rel="stylesheet" title="NavTextCaptions" type="text/css" href="../../nav_text_captions.css" /> <link rel="stylesheet" title="HideBottomNav" type="text/css" href="../../hide_bottom_nav.css" /> <link rel="stylesheet" title="HighContrast" type="text/css" href="../../high_contrast.css" /> <link rel="stylesheet" title="Print" type="text/css" href="../../print.css" />
with the stylesheet switching stuff being handled here:
http://web.uvic.ca/hrd/hulq/script.js
The audio file format switching is handled here:
http://web.uvic.ca/hrd/hulq/audio.js
The Flash player for MP3s is something I wrote myself -- it's a little Flash movie that you can pass an mp3 file URL to using the object tag parameters. The other players are standard, and they're all inserted using object tags so we get valid XHTML. You're welcome to use the Flash audio player too if you like -- it's designed to be as unobtrusive as possible, and has only Play and Stop, with Play turning into Pause while playing. There's a tutorial on how to use it in Hot Potatoes exercises here:
http://web.uvic.ca/hrd/hotpot/howto/audio.htm
The code explained in the tutorial is straight XHTML 1.1, so it's generalizable to any modern Web page, and there are download links to the Flash movie and the Flash project file, in case you want to make some tweaks to the way it works.
Cheers, Martin
At 08:28 AM 30/06/2004, you wrote:
Content-Transfer-Encoding: 7bit
This is neat. I was thinking of something very similar using cookies, though I hadn't thought of using a form to allow users to select several options (my plan had been to offer a selection of different sheets: large screen, small screen, accessibility). Are there generalisable scripts on this project that might usable by other members of the list? -dan
Martin Holmes wrote:
Hi there,
At 01:40 AM 30/06/2004, you wrote:
I think that catering for special needs, or simply trying to conform to accessibility guidelines, should be the developer's task, on the basis of the anticipated audience. And you can also see why imposing choices on the users is a bad idea: while you probably should keep in mind accessibility everywhere, it could make sense to propose a special version of your site (lighter on resources, for instance, or conceived for PDA browsers, etc.), but if you already have to propose a version for "normal", standard-complying browsers, and another for IE, this probably is not feasible, or would result in a scarcely maintainable site.
I think it's good to strike a balance here. On our Introduction to Hul'q'umi'num' site (http://web.uvic.ca/hrd/hulq/) we let the user choose which audio file format and media player they prefer to use, then store that in a cookie and use it to insert the appropriate media player code for every audio link. We determined this would be the best way to handle the fact that there are no real standards for media files on the Web, and a range of players is available; it's unreasonable to require people to install a particular player just to use one site, so we let you choose between WMP, Real, Flash and Quicktime, and between .wma, .ra, .mp3 and .ogg files. This pretty much ensures that anyone can use the audio material without installing anything special (we hope!).
We also allow people to decide where they'd like to put the navigation menus on the page, and give the option of a high-contrast colour scheme, or a print stylesheet for the pages (which is monochrome, without navigation). All of this is done through JavaScript and cookies, and the individual pages themselves do not need to be changed; the JavaScript reads the cookies and makes changes to the DOM when the page is loaded or when the user chooses an audio segment to listen to. All of this is done client-side, so the site can be run from a CD, or a server with no available scripting, if necessary.
This kind of flexibility is fairly easy to incorporate in a site nowadays. However, the issue of PDAs is a slightly different one; PDA browsers are porrly-featured in terms of CSS, JavaScript and DOM support, so unless a site is very simple indeed, any special version of it for PDAs currently has to be created server-side. In a couple of years, though, PDAs will be running the equivalent of the current FireFox, I think, and most things we do now for desktop browswers will be practical for PDAs.
But then we'll have the legacy installed base of old PDAs to worry about...
Cheers, Martin
Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
dm-l mailing list dm-l@uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l
-- Daniel Paul O'Donnell, PhD Associate Professor of English University of Lethbridge Lethbridge AB T1K 3M4 Tel. (403) 329-2377 Fax. (403) 382-7191 E-mail daniel.odonnell@uleth.ca Home Page http://people.uleth.ca/~daniel.odonnell/
dm-l mailing list dm-l@uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l
______________________________________ Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
As a former (long ago) programmer (software engineer ?) I understand the problem of multiple browsers, etc.
But as a user, if it won't run with my preferred browser, I just abandon it and never come back to look at it again, even though I have more than one browser on my PC. (I keep the other browser -- IE -- just for dire emergencies.) I have no idea if this bothers the folks writing the programs.
At 09:10 AM 30/06/2004, you wrote:
as a user, if it won't run with my preferred browser, I just abandon it and never come back to look at it again
I think the pact should go like this:
The developer promises to write code which is compliant with modern, open, non-proprietary international standards (e.g. XHTML, Unicode, ECMAScript, etc.).
The user agrees to install one of the many free browsers which is capable of handling the current standards.
Thus everyone is happy. If users choose to use obsolete or bad browsers, then that's their privilege, but most developers don't have time or money to produce code to support that kind of thing. If developers choose to write sites that aren't based on standards, they deserve to have their sites ignored, and ultimately inaccessible to the majority of people.
All of the current versions of these browsers have pretty good support for the current crop of standards:
Firefox, Mozilla, Camino, Internet Explorer (Windows), Safari, Opera, Netscape.
That's not a bad range of choices.
Cheers, Martin
At 09:10 AM 30/06/2004, you wrote:
Content-Transfer-Encoding: 7bit
As a former (long ago) programmer (software engineer ?) I understand the problem of multiple browsers, etc.
But as a user, if it won't run with my preferred browser, I just abandon it and never come back to look at it again, even though I have more than one browser on my PC. (I keep the other browser -- IE -- just for dire emergencies.) I have no idea if this bothers the folks writing the programs.
dm-l mailing list dm-l@uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l
______________________________________ Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
Martin Holmes wrote:
At 09:10 AM 30/06/2004, you wrote:
as a user, if it won't run with my preferred browser, I just abandon it and never come back to look at it again
I think the pact should go like this:
The developer promises to write code which is compliant with modern, open, non-proprietary international standards (e.g. XHTML, Unicode, ECMAScript, etc.).
The user agrees to install one of the many free browsers which is capable of handling the current standards.
Hear, hear! I agree completely -- well, almost. If you're primarily delivering static content, it's not all that hard to arrange your XHTML, CSS and JavaScript so that it degrades gracefully. My on-line OE grammar (http://www.wmich.edu/medieval/research/rawl/IOE/index.html) does reasonably well in this respect, I think: it looks best in Mozilla, acceptable in IE 5/6 and readable in NS 4.blech. (There you can also see my stylesheet philosophy: a default stylesheet, one for the visually impaired, and an option to turn off stylesheets--for the PDF set. Separate stylesheets for different browsers is madness--Microsoft spends its money that way, I believe.) For the kind of advanced functionality Martin was describing earlier, I think there is no harm at all in expecting users to have an up-to-date browser. My own case in point is the Old English Aerobics anthology (http://www.engl.virginia.edu/OE/anthology/index.html), which really doesn't ask all that much of a browser, but doesn't run in NS 4 and never will.
Peter
At 11:59 AM 30/06/2004, you wrote:
The developer promises to write code which is compliant with modern, open, non-proprietary international standards (e.g. XHTML, Unicode, ECMAScript, etc.).
The user agrees to install one of the many free browsers which is capable of handling the current standards.
Hear, hear! I agree completely -- well, almost. If you're primarily delivering static content, it's not all that hard to arrange your XHTML, CSS and JavaScript so that it degrades gracefully. My on-line OE grammar (http://www.wmich.edu/medieval/research/rawl/IOE/index.html) does reasonably well in this respect, I think: it looks best in Mozilla, acceptable in IE 5/6 and readable in NS 4.blech. (There you can also see my stylesheet philosophy: a default stylesheet, one for the visually impaired, and an option to turn off stylesheets--for the PDF set. Separate stylesheets for different browsers is madness--Microsoft spends its money that way, I believe.) For the kind of advanced functionality Martin was describing earlier, I think there is no harm at all in expecting users to have an up-to-date browser. My own case in point is the Old English Aerobics anthology (http://www.engl.virginia.edu/OE/anthology/index.html), which really doesn't ask all that much of a browser, but doesn't run in NS 4 and never will.
These are lovely sites -- I hadn't seen them before. The access key navigation is very nice indeed.
Cheers, Martin
______________________________________
Martin Holmes University of Victoria Humanities Computing and Media Centre mholmes@uvic.ca martin@mholmes.com mholmes@halfbakedsoftware.com http://www.mholmes.com http://web.uvic.ca/hcmc/ http://www.halfbakedsoftware.com
It's official...
-------
US-CERT ADVISES SWITCHING BROWSERS In light of a recent announcement about an "extremely critical" security vulnerability in Internet Explorer (IE), the U.S. Computer Emergency Readiness Team (US-CERT) has issued a warning advising computer users to stop using Microsoft's browser. US-CERT is a nonprofit formed in September 2003 by the Department of Homeland Security and the public and private sectors to improve computer security preparedness and response. According to the US-CERT notice, there are "significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME-type determination, and ActiveX." The IE bug allows hackers to install spyware on users' computers without any action on the part of the user. The notice goes on to say that, particularly for browsing untrusted sites, use of another browser is an effective way to avoid the security risks mentioned. Internet News, 29 June 2004 http://www.internetnews.com/security/article.php/3374931
Dr. Elizabeth Solopova Department of Special Collections and Western Manuscripts Bodleian Library Broad Street Oxford OX1 3BG Tel.: +44 (0)1865-277073 E-mail: es@bodley.ox.ac.uk Internet: http://www.bodley.ox.ac.uk/ http://www.bodley.ox.ac.uk/dept/scwmss/
-
Daniel O'Donnell -
Elizabeth Solopova -
Jeffrey Fisher -
Martin Holmes -
Norman Hinton -
Peter Baker -
Roberto Rosselli Del Turco