RE: [WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
Hi. If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? If some js feature bring me 100 costumers i can effort loose 1, which don't support js. Another question that i try to keep all of them, if it's possible. Graceful degradation is better than nothing, but progressive enhancement rocks. ACK. It rocks. Problem: Often some js feature (AJAX for example) is key to the project. Than first i develop server side scripts and front end, which depends on AJAX. And after i finish, if there is enough time and budget is OK, i modify front end (if needed) and write additional server side scripts so user may work without js. If code is good — add such accessibility feature is not a problem. But if you get project with low budget and where deadline was yesterday, than accessibility must first be sacrificed. If project stay alive — you may return to this question. Yes, progressive enhancement rocks. But, if don't use it wisely, you'll starve. Also I do support witches, but that's off-topic. Sorry for my English. I need more practice. Much much more practice. :) Regards. Raven aka Silent Imp. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
Out of curiosity, what sort of feature are you talking about that can't be done server side (ie, *without* AJAX)? I'll confess to relying heavily on server side JS on some projects, but I did so because I knew those apps would be used exclusively on an intranet where the SOE was known to support JS. The user experience is definitely enhanced from the use of client side JS (it was a kind of online spread sheet used by the finance dept), but it's nothing I couldn't have done, with a little work, on the server side (and *lots* of page submissions). On Mon, Jun 15, 2009 at 4:29 PM, ravenrav...@mail.ru wrote: Hi. If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? If some js feature bring me 100 costumers i can effort loose 1, which don't support js. Another question that i try to keep all of them, if it's possible. Graceful degradation is better than nothing, but progressive enhancement rocks. ACK. It rocks. Problem: Often some js feature (AJAX for example) is key to the project. Than first i develop server side scripts and front end, which depends on AJAX. And after i finish, if there is enough time and budget is OK, i modify front end (if needed) and write additional server side scripts so user may work without js. If code is good — add such accessibility feature is not a problem. But if you get project with low budget and where deadline was yesterday, than accessibility must first be sacrificed. If project stay alive — you may return to this question. Yes, progressive enhancement rocks. But, if don't use it wisely, you'll starve. Also I do support witches, but that's off-topic. Sorry for my English. I need more practice. Much much more practice. :) Regards. Raven aka Silent Imp. *** 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] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
I think the point is if you should be spending time developing something with a bad user experience that hardly anyone will use. Yes you could implement a spreadsheet app with tons of page requests, but the user experience would be so bad that people probably wouldn't want to use it. On 15 Jun 2009, at 16:42, nedlud wrote: Out of curiosity, what sort of feature are you talking about that can't be done server side (ie, *without* AJAX)? I'll confess to relying heavily on server side JS on some projects, but I did so because I knew those apps would be used exclusively on an intranet where the SOE was known to support JS. The user experience is definitely enhanced from the use of client side JS (it was a kind of online spread sheet used by the finance dept), but it's nothing I couldn't have done, with a little work, on the server side (and *lots* of page submissions). On Mon, Jun 15, 2009 at 4:29 PM, ravenrav...@mail.ru wrote: Hi. If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? If some js feature bring me 100 costumers i can effort loose 1, which don't support js. Another question that i try to keep all of them, if it's possible. Graceful degradation is better than nothing, but progressive enhancement rocks. ACK. It rocks. Problem: Often some js feature (AJAX for example) is key to the project. Than first i develop server side scripts and front end, which depends on AJAX. And after i finish, if there is enough time and budget is OK, i modify front end (if needed) and write additional server side scripts so user may work without js. If code is good — add such accessibility feature is not a problem. But if you get project with low budget and where deadline was yesterday, than accessibility must first be sacrificed. If project stay alive — you may return to this question. Yes, progressive enhancement rocks. But, if don't use it wisely, you'll starve. Also I do support witches, but that's off-topic. Sorry for my English. I need more practice. Much much more practice. :) Regards. Raven aka Silent Imp. *** 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: Re: [WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
Hi. Out of curiosity, what sort of feature are you talking about that can't be done server side (ie, *without* AJAX)? As a matter of fact, you right. Without AJAX (in any form) server side scripting remains intact and matter disappears. My front end development order: 1. XHTML coding of structure. Semantic and accessibility features fully included. 2. Adding style sheets for all devices i support (in external files). 3. Adding js (in external files). There is just no sense to develop it in any other way a.f.a.i.k. But, if there is AJAX, i must assess time and budget and decide: what type of communication with server side i must support primarily and do i have enough resources to support another. Regards. Raven aka Silent Imp. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] functionality without JavaScript [WAS: returning to scroll position in a table inside a fixed hight div]
At 6/14/2009 11:28 AM, raven wrote: Keep in mind as always that a JavaScript solution will not work in user agents not running JavaScript, which can include search engines, mobile devices, assistive technology, browsers in certain corporate contexts in which JavaScript is globally turned off or stripped out of incoming pages by firewalls, old browsers, and modern browsers used by folks who turn it off for whatever reason. Hmmm... what exactly problem can cause using of JavaScript *in this case* from SEO point of view? Not having seen the original poster's development plan, we can't judge whether any of the parts that are broken without JavaScript will deleteriously affect its search engine ranking. Because the page was SO dead without JavaScript, I made the assumption that the author wasn't considering scriptless UAs and therefore my remarks were intended generally. Or what browser, *witch you really support*, don't support JS? In my own work, my CSS support for mobile devices has lagged, but as my pages all work 100% in the absence of JavaScript (which I do use in every site I produce) I can say I do support to that extent all the JavaScript-disabled user agents listed at the beginning of this post. (Also I do support witches, but that's off-topic.) And what part of your target auditory even know how to disable JavaScript execution in their browsers? Don't use common words! Give us facts, numbers, tests. So, for example, if I could give you the number of individuals who would be unable to use a website because I built it to unnecessarily require JavaScript, then would you be able to tell me whether that was an acceptable sacrifice in terms of loss of revenue to the client, loss of good will, negative reviews, and negative viral spread? What percentage of your clients' target audiences have you decided to block from the sites you build for no reason other than that you enjoy building cool user interfaces in JavaScript? If a website client of yours hired you to manage an actual storefront and you arbitrarily slammed the door in the face of every 100th, 200th, or even 1000th customer, how long do you think would you keep your job? But graceful degradation is good idea. Graceful degradation is better than nothing, but progressive enhancement rocks. http://en.wikipedia.org/wiki/Progressive_enhancement http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/ If you have enough time and budget big enough you may look for solutions for case when JavaScript is disabled. I don't need to. I build sites to work well with server-side scripting, then I enhance the client-side experience with JavaScript. I don't have to justify extra work to make a site functional for any size of sub-market or worry about how many people it's OK to piss off if the site already works for every user agent. I don't provide core functionality with JavaScript. I learned the hard way that doing things the other way around is time-consuming, expensive, and frustrating. JavaScript is fun, but you aren't going to survive long if you consistently eat your dessert before your vegetables. No, first you build a car that runs well, then you add the chrome and fancy sound system. I'd better stop before I think of any more metaphors to throw in the pot. Oops, too late. P.S. In ordinar case if you can get functionality, you need, without JS do it. Exactly. To everyone, I apologize for indulging in a philosophical argument that has already seen so much traffic. Reviewing the wsg list guidelines, I hope this falls into the category of discussing best practices. Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
