Re: [WSG] JavaScript Language Clarifying within HTML
The language attribute was deprecated in html 4, so I wouldn't advise using it. see: http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1 Thanks, David On 14/7/09 13:23, Brett Patterson wrote: I am not sure about the most recent standards regarding the language attribute of the SCRIPT tag within an HTML page, so I would like to know if it is still recommended to use the language attribute within the SCRIPT tag? And what version, if it is recommended to use that attribute, would one specify to have the most in both backwards and forwards compatibility? -- Brett P. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] utf8 character display problem
you should also be able to add/edit a .htaccess file on the shared web space and add the following: AddDefaultCharset utf-8 most hosts, even shared hosts should allow this (and it saves adding php headers to every page) Thanks, David On 7/7/09 18:46, Nick Roper wrote: Hey Rimantas, I added a line of PHP code as follows: ?php header(Content-Type:text/html; charset=UTF-8); ? and it works fine now. I also installed Live Headers in FF for future debugging. Many thanks for that. Cheers, Nick Rimantas Liubertas wrote: Here's the issue: We are working on a site that incorporates Russian text. It displays OK on our development server, but when transferring the files to the live server we get garbled output. … However, the same file uploaded to the live server displays the last menu item incorrectly: http://www.imperial-russian-dating.com/utf8-test.php The file has been saved as utf8 encoded in the editor (Komodo) and then uploaded to each server. Any ideas ? There are headers sent by your live server: Connection:close Content-Length:862 Content-Type:text/html; charset=ISO-8859-1 Date:Tue, 07 Jul 2009 16:22:43 GMT Server:Apache/2.2.3 (CentOS) X-Powered-By:PHP/5.1.6 Take a look at Content-Type header: it specifies charset as iso-8859-1. Charset specified in HTTP has preference over charset in META. If you have access to your server configuration look for AddDefaultCharset directive in Apache config. You can either change it to UTF or comment it out. Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] SEO vs. Accessibility
It will only be an issue if what you present to a user is different to what you present to a search engine. If what you're doing is using a text replacement technique using an image etc, then there are no problems with that. But if you are adding invisible headings or links etc (ie anything that should be allow for user interaction, but doesnt because its been move out of sight to enhance seo etc) then this will be a problem as it is, what is commonly referred to as, a black hat technique. The thing to remember is that while its doubtful google will spot it through an automatic spider, google do manually check pages (either randomly, or when the spider, or even a person, flag something up). Its that manual detection that will spot this kind of fraud, and will likely result in an immediate ban. regards, David Dixon e: da...@temperedvision.com w: www.temperedvision.com On 26/5/09 17:26, Spellacy, Michael wrote: Hello list! I have a quick question for any accessibility and SEO mavens out there. It was recently brought to my attention that a few elements I have placed on a site that have text indented px to the left for accessibility might be viewed as a form of cloaking by some search engines. Is my colleague correct in this assessment? If so, is there a middle ground that can be met to make search engines and visually impaired folks happy? Thanks in advance! Regards, Spell *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Javascript Accessibility
Interesting blog entry by the creators of the Cappuccino project (http://cappuccino.org) on the subject on Web Accessibility vs JavaScript Availability: http://rossboucher.com/2009/02/26/accessibility-degradation-in-cappuccino Personally im in favour of the distinction he makes, but the expectation for the WAI ARIA team to contact _them_ to help their framework use it is rather unrealistic although the WAI ARIA team (as with the W3C in general) need to start producing more palatable documentation rather than just having huge technical manuals on the subject. Interested to know others thoughts on the subject. David -- David Dixon t: 07967 569 489 e: da...@digitaloasis.co.uk linkedin | http://www.linkedin.com/in/davidjdixon twitter | http://twitter.com/daviddixon *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Javascript Accessibility
michael.brocking...@bt.com wrote: David, I think you are reading things differently to me. I don't know the authors true intention, but I read his words as being a call for anyone who wants to see ARIA implemented to join their team, not necessarily someone who is on the ARIA team. Thanks Mike, t'was a fairly minor point, but yes i think you're interpretation of the request is more accurate than my initial one. David -- David Dixon t: 07967 569 489 e: da...@digitaloasis.co.uk linkedin | http://www.linkedin.com/in/davidjdixon twitter | http://twitter.com/daviddixon *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Javascript Accessibility
Mathew Robertson wrote: Its been possible to do ARIA style accessibility since about 1995 - its just now that people are starting to care. Mathew Robertson Before this question gets sidetracked, the request was for opinion on the position of the distinction of accessibility vs availability, not on WAI ARIA, apologies if the content of my original email didn't make this clear. My issue with ARIA is one of documentation, and would prefer deal with ARIA in a separate conversation. David -- David Dixon t: 07967 569 489 e: da...@digitaloasis.co.uk linkedin | http://www.linkedin.com/in/davidjdixon twitter | http://twitter.com/daviddixon *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Javascript Accessibility
Guys please, move this to a different topic, this ARIA issue has now clouded the original question. David -- David Dixon t: 07967 569 489 e: da...@digitaloasis.co.uk linkedin | http://www.linkedin.com/in/davidjdixon twitter | http://twitter.com/daviddixon Matt Morgan-May wrote: As someone who's on the working group producing ARIA, I have to say the editors have done a pretty remarkable job in terms of documenting a specification that hasn't even advanced past Working Draft. First, there's the spec itself: http://www.w3.org/TR/wai-aria/ Then there's the User Agent Implementation Guide, for browser developers to follow: http://www.w3.org/TR/wai-aria-implementation/ And the Best Practices Guide, for authors: http://www.w3.org/TR/wai-aria-practices/ In addition, Steve Faulkner, also in the PFWG, has done lots of writing on the subject: http://www.paciellogroup.com/blog/?cat=23 And Universal Design for Web Applications, the book I co-wrote with Wendy Chisholm, has a more basic introductory chapter on ARIA. The point is, it may not all have a W3C banner at the top, but generally speaking, W3C is more responsible for being complete and precise, than being prosaic. I expect that the Web Standards Curriculum is most likely to have author-friendly material on ARIA, and that's only when the spec is stable enough for general consumption. - m On 3/1/09 6:32 AM, David Dixon da...@terrainferno.net wrote: although the WAI ARIA team (as with the W3C in general) need to start producing more palatable documentation rather than just having huge technical manuals on the subject. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Not quite right im afraid. Patrick Lauke sent an email about this in December that highlighted the Firefox zoom config as shown below: -- Quote -- toolkit.zoomManager.zoomValues, and this will show the various zoom factors at each step. In my case (which should be the default) these are: .3, .5, .67, .8, .9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3 So, nominally 200% (which, according to the Understanding... bit for that SC, means 200%, that is, up to twice the width and height - so really a 400% increase in total area) is actually 6 steps, if you want to go purely by numbers. -- End Quote -- David Gunlaug Sørtun wrote: Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) David Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Parenthesis around list counters
Either that or simply go down the PDF route and put the important legal information into a separate document. I've found similar issues to this from legal teams who require a perfect translation from a word doc etc, and as Georg says, relying on individual browser support is often not acceptable (especially if regulatory bodies etc try to view them in a non fully compliant browser). David On 27 Jan 2009, at 19:25, Gunlaug Sørtun gunla...@c2i.net wrote: James O'Neill wrote: We are a small county displaying our ordinances and parens are important for legal notations and references. If such details are important, they should be written in plain text. Regardless of whether a method is found or not, one can not rely on browsers support for HTML/CSS to replicate importance at such a level. Simplest way to test if a method is acceptable or not for a particular case, is to observe the outcome with CSS and script support off - in Lynx for instance. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Users who deliberately disable JavaScript
Agreed, if people have real long term usage statistics that they can share to support the claim that Javascript use is in decline, and not focus on very one-sided arguments of personal use or everyone i know then I'd be interested to hear. Until that time, or my own analysis supports these claims (which they certainly do not) I will remain completely sceptical. Oh and arguments over technical solutions that provide the ability to limit Javascript usage and talking about increasing threats etc are not terribly insightful as these are the same arguments that were made years ago and its a very old and unsubstantiated argument (for example, I can assure you that the large array of anti-Flash extensions for Firefox has made bugger all impact on the market penetration of Adobe's Flash Player or its usage). David Patrick H. Lauke wrote: David Lane wrote: Given the increased number of threats and the availability of slick script blocker extensions for Firefox like NoScript (http://noscript.net/) it's only going to get more common, particularly among security conscious people. I certainly use it, only enabling Javascript for a site I'm visiting when I can see what benefit it has to me. As good as it is to hear anecdotal evidence from expert users such as list members here, I'd say it's much more important to bring some actual live user stats to the table. Most normal users don't even know that the internet is not just the blue E on their desktop, or what javascript is, or how to install extensions, or what security threats are. Heck, most don't even know that they can zoom/text resize/print most of the time, without having a widget or icon on the actual pages. P *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Users who deliberately disable JavaScript
Again, can you show that the small decline in IE's market share has contributed to users blocking Javascript or using specific Firefox extensions? IE has had plugins such as the Web Accessibility Toolbar etc for some years now that allow disabling of Javascript very easily, so why would the usage of another browser and additional extensions change this? People do change their viewing habits all the time, and migrations between browsers will continue (whether to IE detriment or not), it doesn't mean people are getting smarter or that they are concerned at all about Javascript (im sure the security concerns over IE6/7 that have talked about over in the mainstream news networks over the past couple of years have had nothing to do with Javascript, and are far more related to Microsoft's proprietary ActiveX functionality). If memory serve's, the people are getting smarter observation has been stated on this mailing list since its inception, and we've yet to see any evidence of this. David David Lane wrote: Agreed - the level of savvy of most user is absurdly low, and at present few will know what Javascript is, much less how to disable it. The question is whether people today design for today's users, or tomorrow's... The trend will continue towards more sophisticated users, using better browsers (i.e. not IE) which support useful plugins like NoScript and their analogues for Opera, Webkit, etc. I suspect as more and more people get burned by identity theft and other forms of exploitation, the pain individuals experience will provide a strong motivation for learning. Also, organisations will increasingly make that decision on behalf of their users to minimise their own risk... Cheers, Dave *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] CSS IE6/7 - what a surprise
Just to correct Todd's reply, the :after property isnt support by either
IE7 or IE6 (and below), therefore you would need to adjust your CSS to
state (assuming you're using a CSS hack, for ease of display):
#NameofContainingDiv {
*zoom: 1;
/* all your other styles for the element */
}
#NameofContainingDiv:after {
clear: both;
content: '.';
display: block;
height: 0;
visibility: hidden;
}
David
Todd Budnikas wrote:
Damian probably gave you your answer, but I'll also say that if you
review the original documentation
from http://www.positioniseverything.net/easyclearing.html for the code
you're using, you'll see that they recommend conditional comments to
trigger hasLayout. In your case, in the head of your document you should
add:
!--[if IE]
style type=text/css
#NameofContainingDiv:after {
zoom: 1; /* triggers hasLayout */
} /* Only IE can see inside the conditional comment
and read this CSS rule. Don't ever use a normal HTML
comment inside the CC or it will close prematurely. */
/style
![endif]--
Either way, the end goal is the same.
On Jan 23, 2009, at 5:15 AM, Damian Edwards wrote:
Most likely a lack of hasLayout triggers or layout context changes, or
both.
For the coloured boxes, add overflow:hidden to the divs with classes
catalougeMid and subscribeMid. This will force them into a new layout
context and in turn expand the container to contain all elements. If
you want it to apply to IE6 and IE7 only, use a selector hack:
* html .catalogueMid, * html .subscribeMid { overflow: hidden; } /*
IE6 Only */
*:first-child+html .catalogueMid, *:first-child+html .subscribeMid {
overflow: hidden; } /* IE7 Only */
I’d have to fire up a VM to look at the IE6 issue and it’s late J
Regards,
*Damian Edwards
*Microsoft MVP
https://mvp.support.microsoft.com/profile/Damian.Edwards | ASP/ASP.NET
Readify | Senior Consultant
M: 0448 545 868 | E: damian.edwa...@readify.net
mailto:damian.edwa...@readify.net | C: damian.edwa...@readify.net
sip:damian.edwa...@readify.net | W: www.readify.net
http://www.readify.net/
*From:* li...@webstandardsgroup.org
mailto:li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] *On
Behalf Of *Henrik Madsen
*Sent:* Friday, 23 January 2009 19:37
*Subject:* [WSG] CSS IE6/7 - what a surprise
HI all,
I'm hoping there's a simple solution to my two problems.
All looks fine in Mac browsers x5 and IE8b2 (according to
netrenderer) but not in:
IE6 - Mysterious margins are appearing between the header and the top
menu and in both coloured boxes in the right hand column of the main
content.
IE6+7 - the coloured boxes are not 'expanding' to contain the content
(in this case a floated image in both)
I found this CSS as an alternative to a clearing div and it seems to
fix things in other browsers - except those IE's:
#NameofContainingDiv:after {
clear: both;
content: .;
display: block;
height: 0px;
visibility: hidden;
}
Would anyone be able to have a look?
Here's the link:
http://www.igenerator.com.au/dev/sm09/homepage.html
Any other thoughts, comments, suggestions - always appreciated.
TIA,
Henrik Madsen
*Generator*
hen...@igenerator.com.au mailto:hen...@igenerator.com.au
www.igenerator.com.au http://www.igenerator.com.au/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Examples of great high-school websites?
Perhaps the blatant disregard for common web standards could be the reason? (this is after all a web *standards* list and not a web designers list...) Lets see: - tables for layout - no alt attributes for images - obtrusive javascript (are professional companies really still getting away with the default Dreamweaver rollers???) - reliance on javascript for basic functionality - the marquee tag ?!? - no form labels So that's inaccessible, non-semantic and non-xhtml/html compliant ... im not sure i can stand to review any more of the site, the home page is enough to kill my spirit. David Rick Faircloth wrote: What did you find to be so bad about the site, Stuart? -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Stuart Foulstone Sent: Saturday, January 17, 2009 2:11 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Examples of great high-school websites? Perhaps the students should code the site - they couldn't do much worse! On Fri, January 16, 2009 7:00 pm, Fred Ballard wrote: Take a look at Sullivan High School's http://www.sullivanhs.org/. As you can see in the homepage's lower right corner it's from the Chicago Public Schools, http://www.cps.k12.il.us/, with a company, Educational Networks, http://www.educationalnetworks.net/, behind it. Is it too slick? I'm of two minds. It's great that it's a good-looking site, but it might be nice to let the students be the designers. I don't actually know what the students think about it, on the other hand. Fred On Thu, Jan 15, 2009 at 8:29 PM, David Lane d...@egressive.com wrote: Oops - should've been Disclosure rather than Disclaimer :) On Fri, 2009-01-16 at 15:21 +1300, David Lane wrote: Disclaimer: I've had occasional association with the work being done at Hagley, and have been a guest speaker to the computing students on a couple occasions :) -- David Lane = Egressive Ltd = d...@egressive.com = m:+64 21 229 8147 p:+64 3 963 3733 = Linux: it just tastes better = nosoftwarepatents http://egressive.com we only use open standards: http://w3.org Effusion Group Founding Member === http://effusiongroup.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] dl v table for form layout
Personally I think that form elements lend themselves to practically all the semantic meaning you need. Labels and input elements are either implicity or explicity linked (ie either labellabelnameinput ...//label or label for=myinput/labelinput id=myinput.../), and then you have fieldsets as the basic method for containing groups of form elements. I never use tables or lists (definition or otherwise) for form elements as their structure is typically far more complex than a basic list would account for without lists of lists (which gets a little silly), and i prefer to use semantic-neutral elements such as div and span eg. fieldset div class=surround label ...text/labelinput / /div div class=surround label ...text/labelinput /spanaddition text, errors etc/span /div /fieldset Ive never found a situation where this kind of structure has ever let me down using any kind of layout (text above, beside etc) with the help of float-fixing styles etc, and its infinitely more flexible than a table (i cant begin to describe how many table-based forms ive had to convert simply because someone wanted an additional info column to look like it covered 2 or more input areas (help text etc)). Cheers, David. Benedict Wyss wrote: Hi all, I am having a discussion with colleagues here at work (won't mention our site as it stinks) about the best way forward for form layouts. I have one person saying he will continue to use tables till otherwise informed. I have another who uses none of the above, which you can imaging is not that good to look at with everything butting up against each other. His other suggestion was to add nbsp's to move things about. I like to use the definition list with Labels. Now I know the dl I am using is not being used exactly as it was originally used (good point), but I say it is 100 times better than tables. Can I get a WSG response on the best format to layout a form. Cheers, Ben *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Hack for all IE versions including 7
The problem is though, that these browser never actually go, they simply evolve a little which doesn't always make the hack redundant, just altered slightly. Therefore, for me, having the hacked styles alongside the valid css styles makes things infinitely easier to see what is actually happening. There certainly isn't a right answer here, but consistency is key. @imports and conditional comments etc can be useful in terms of absolute validation, but present problems (especially for very large, complex projects) where you always have 2+ versions of a style sheet to maintain, and in real world web projects, there is rarely enough thinking time to fully plan css changes, let alone work out the nuances of different browsers separately. Hacks are very useful, but only if the context of the hack is obvious (putting a */_ hack 50 lines away from the original declaration is of no use to anyone). Its very easy to maintain, with experience, the targets of the hack are very obvious, and i find it does a much better job at highlighting the actually differences between the browsers than separate style sheets would ever provide. Validation is often a problem, yes, but then no 2 browsers actually obey the CSS2.1 spec in the same way (if at all), so personally i find trying to obey a spec which isn't adhered to in the first place is pretty fruitless. Cheers, David. Thierry Koblentz wrote: I agree on the amount of hacks that should be needed, if you need to serve a 5Kb styles sheet to fix IE then you have a problem... But don't you think that once these browsers (the ones that rely on these hacks) are gone, it'll be easier to remove an @import directive or a link element than to go through CSS files hunting for *, _, ,, voice-family, , /*\*//*/, etc.? Also, regarding maintenance (other authors working on your styles sheets), I think it'll be easier for many people to maintain browser specific *hack-free* styles sheets rather than having to learn about CSS filters to be able to maintain those files. --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] PopUp windows
Hi Bob, You may want to look at solutions like thickbox (http://jquery.com/demo/thickbox/) which offers a very degradable way to open faux popups, or floating divs, and also adds some nice animation in there too. This way, if the browser has javascript support (and it's enabled) then what the user gets is quite a fancy alternative to standard to popups (and it'll definately keep the client happy) and it will degrade nicely to simply open a new site (in the same window if you choose) if the JS support isnt there. There's also greybox (http://orangoo.com/labs/GreyBox/) which does a similar thing without the need for the jquery library. I've spent a good couple of weeks developing a solution on the prototype library that combines thickbox with lightbox (http://www.huddletogether.com/projects/lightbox2/) but its not yet ready for release as I havent fully stress tested it. Cheers, David. Bob Schwartz wrote: Problem: client wants (insists on having) popup windows. Question: can they be made OK according to all canons of WSG? (ie served in a different/alternative manner for people, devices, etc. - leave aside the js argument, as that I have solved). *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
