As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When I first read the principle of unobtrusive JavaScript in the Web Standard Curriculum I thought it's a really great thing.
Unobtrusive JavaScript is more of a programming philosophy than a technique. By far its most important component is a clear sense of which functionality belongs in which layer. All absolutely crucial site functions should be coded in plain HTML, but once you’ve created that base you can add a JavaScript layer on top of the basics in order to give browsers that support it a nicer, cleaner, faster-seeming interface.
Further, unobtrusive JavaScript:
separates structure and behaviour, in order to make your code
cleaner and script maintenance easier
pre-empts browser incompatibilities
works with a clean, semantic HTML layer
For my current project I use this approach. When I turned JavaScript off for some other kind of work I had to do I was surprised how many websites are completely broken without JavaScript: missing functionality, as well as absent of a lot of important information, which were not present at all in the whole DOM.
These were especially social network sites. It should be no surprise that this were the case, the required development time and user experience might be a lot more important than the accessibility.
Still I am asking myself, whether unobtrusive JavaScript is not out of date. I mean which browser does not support JavaScript already natively? Is it still an approach which fits for the year 2012? I started doubting it.
There are two ways of approaching a website and the use of JS:
JS as an enhancement
These types of sites are like "documents" in a sense that they are analogous to newspapers, books and letters. You don't need fancy effects to read and use the content. And with this comes progressive enhancement: Building a basic functionality and add on complexities without sacrificing the purpose.
Most (large) websites use this scheme to preserve its usefulness even when using a non-capable browser. An example is StackOverflow, which even works on a lynx command-line browser!
______
| JS | - JavaScript for (optional) enhancements
|------|
| CSS | - CSS for (optional) style
|------|
| HTML | - (mandatory) HTML with base content
'------'
JS as a platform
For web apps, it's reasonable (more like mandatory) that they are build upon JS for real-time, dynamic content and functionality while HTML and CSS serves as the view. It's synonymous to other programming languages, where you can go "headless" with your program (no UI) like libraries and plugins.
Graceful degradation comes with this approach: "Backwards support only to a certain extent, otherwise you get none at all"
____________
| HTML | CSS | - (optional) HTML and CSS view
|------------|
| JS | - (mandatory) JS platform
'------------'
It generally boils down to a question of "Is it a document, or an app?"
Different companies take different approaches. For example Google for their search uses unobtrusive javascript which degrades gracefully, but for GMail they maintain a separate HTML only site which they developed later after GMail JS version.
To me it depends on
Complexity
Functionality,
Cost
Impacted user count
to decide whether to do Graceful degradation using unobtrusive JS or to build a dedicated HTML only site or to ignore that user base completely.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been looking for a good Java web framework and found Tapestry, which looks quite nice from an application architecture point of view. Another possibility is ASP and .NET, though I'm reluctant to use them since Java is the programming language most of the company's developer are used to. The reason why ASP is considered is due to its rich set of powerful UI widgets (http://demos.devexpress.com/ASPxGridViewDemos/GridEditing/EditModes.aspx for instance). Is there anything similar for Tapestry? What I am particularly interested in is tables (sorting, filtering, moving columns, hiding columns, etc.) and possibly others. Alternatively, is there a sophisticated Javascript library which can be easily integrated in Tapestry?
At my current job we use Tapestry 4, and we chose to use ExtJS widgets when we need a fancier UI component what Tapestry provides. Their grid widgets are exceptional. ExtJS isn't free for commercial apps, but the abundance of great widgets and documentation makes it really easy to work with, and it integrates pretty easily into Tapestry.
Another option would be to use Java Server Faces, which has several high quality component/widget libraries.
A big library of UI components is a good things. On the other hand there may be no such a set of predefined components that will suite everybody or suite anybody in an ultimate way. The alternative to relying on predefined components (which besides all may require an unexpected time to be learned) is to use a technology with which writing your own components would be an easy pleasure unlike what we see in almost every major Java Web Framework. The approach was implemented in HybridJava which in fact pushed it to the limits with zero predefined components. Yet it may be the most powerful for a task like you've describe.
Tapestry already offers a powerful Grid component.
This component covers all the features you are looking for.
Have a look at jumpstart to see how to sort,move columns, and hiding columns.
if you prefer the jQuery way perhaps you will have to check "Tapestry5-jquery" that proposes some components that make it possible to use jQuery plugins. The demo site only show the default grid component because it's implementation is still the best one.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Site markup is targeted to HTML5. So it's assumed to be runned in modern browsers. Does it make any sense to support javascript disabled scenarios?
If it does, how flexible it should be? Should it allow users to do all or just basic things?
And the same question for CSS. Should I use some patterns (e.g. tables instead of divs and so on) to support clients with disabled CSS?
P.S. I don't have any specific requirements, so it's like a personal challenge.
Its up to you on supporting no javascript. Why don't you ask yourself these questions first?
Do I want my site to be used by blind people (who often use browsers which don't play well with javascript)?
Is this for a federal/gov't agency? (Often, gov't agencies REQUIRE this in order to accommodate people from the first item)
Do I want to accommodate all of the security nuts (no insult intended) and people who turn javascript off to avoid annoying ads?
You should ask yourself these questions first. I'm not trying to suggest you don't like blind people or you're lazy. I know, that if you already have a site which doesn't support javascript turned off, this is going to be a nightmare. So I'm not trying to fling insults/guilt trips. But if you're starting from scratch, then IMHO, it is a good idea to build it without javascript, and then go back and add it in later.
As far as CSS being disabled, I think you're ok not worrying about that one.
As far as divs vs tables. Go with divs, and use tables if you're rendering tabular data. Basically, if you're trying to make something render in a certain place, and you're trying to use a table, you're doing it wrong (you can google about it if you're that interested).
If you follow standards, which includes seperating style from content from funcitonality, then you don't have to know the context that someone is experiencing your website - but you can be confident that they are getting it in the manner they are accustomed to.
For example, there has been a robotic hand developed that can both read and write (sign) in manual sign language, which is touch based (for people who can not see or hear - so no screen, no screen reader). If you have made your website to follow standards, it will be easily accessible by this technology - and also other scenarios you might not have considdered.
I think that corporate firewalls and public computers have javascript disabled more often than you would think.
Also, there is an added benefit to simple html, with appropriate markup to define what elements are, in that search engines can correctly interpret your content and list your site accordingly.
Edit: afterthought
Another example of not following standards getting you into trouble, is adding javascript click events instead of allowing the normal browser action. This can cause problems on touch screen devices where the click event can fire twice (if you include touch event too) or not at all (because the touchscreen has no click event, and only sometimes tries to emulate click events badly)
The moral of the story is that if you follow standards, then you don't have to second guess all the possible scenarios that people could be getting your content, you just know it works.
Graceful degradation is needed when it comes to javascript. Users without javascript should be able to browse your site without issues. (Yet not getting the full experience they would with JS)
Disabled CSS? Tables? Madness.
No. If you go down that road, you'll end up making websites for browsers that can't read HTML.
Note:
When I said that about graceful degradation, I had in mind a site where Javascript is just a plus on the website. If you are making a site that mostly relies on javascript to do everything, don't bother. You shouldn't make a site in which the experience that the user get is TOO diferent from what you intended.
It all just depends on your target audience. Remember, HTML5 is supported in modern browsers and would be a problem with older browsers( there's libraries to help with this like modernizer ). You can use a technique called progressive enhancement if you're really worried about supporting all types of clients. Most browsers nowadays DO have javascript turned on. As far as CSS goes a table-less approach is recommended. Tables should only be used to represent tabular data. This makes styling the elements easier and is a more flexible approach.
JavaScript is still disabled by some for "security concerns". The question is: are these users being alienated without cause? Some "rich client" techniques simply require the client-side power of JavaScript. If it does, it does: if it doesn't, it doesn't. Know the target audience and provide a fall-back as required.
I have yet to meet anyone who has purposefully disabled CSS. However, it is important to keep in mind users with vision disabilities who might be on alternative readers where CSS does little or no good -- this includes CSS/JavaScript interactions such as "sliders". It might be worth looking into WAI-ARIA if this is the concern (but no tables, except for truly tabular data -- in which case, no divitus!).
Also, there might still be some people using Lynx -- new versions in 2011 ;-)
Happy web developing.
I don't think using table instead of divs it's a good approach.
When I think in javascript disabled two thinks come in my mind:
Server validation if you have forms (important!)
Alternative to ajax features (maybe, it depends of your site)
Clients with disabled CSS must be able to read your content, so write clean and meaningfull code. The site don't need to be equal with and without CSS enabled.
I would just like to tell you while designing website, don't ever trust your users, as you will never know what can happen at what click, so its better to adopt something strong which can validate all your content of website and user may turn on/off javascript.
So your website should run in proper way without any interference.
And about Table, its not good to use table always while formating your data, so use instead DIV or SPAN as you will need to apply CSS for that also.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm building a site that needs to work with browsers that support JavaScript and browsers that don't (or that have it disable). What are some good resources that explain good approaches in doing this? Any specific technologies or frameworks that handle this well?
The technique is called Progressive Enhancement, Christian Heilmann wrote a good introduction to the subject.
There is a great video presentation from JSConf.eu 2010 on exactly this topic.
No framework will make your site accessible for JS disabled users. It's your job to do that, independently of what library you may or may not use.
There are two steps you need to take:
Build a site fully functioning without Javascript.
all the content should be available
all links should be real links
all forms should work properly
Add interaction to the site.
the content can be manipulated
links can use event listeners to change behavior
forms can be enchanced
A few techniques that you might want to consider:
The HTML <noscript></noscript> tags are very helpful for displaying content to only browsers that have JavaScript disabled.
There is another technique that I use (credit to Paul Irish? / Modernizr?), called the no-js class. For every page, have <html class="no-js">. Then, also on every page, include a line of JavaScript that erases that class from your html element. If JavaScript is disabled, the no-js class will persist on your markup, and you will be able to design your site (via CSS) appropriately. All you have to do is add the .no-js selector at the beginning of the CSS rules that you want to use when JavaScript is diabled.
My ending thought is you should always try to separate structure (html), style (css), and behavior (javascript). The principles of Unobtrusive Design and Progressive Enhancement are your friends.
Start by building a version of a page or group of pages that does not use JavaScript. Add your JS on top of the functioning page(s) and keep your JS out of your html wherever possible (it's almost always possible).
If you're familiar with Rails you can check out a blog post of mine. The post and example project show how you can handle deletes with JS enabled and disabled.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been using Ext JS as my rich-widget toolkit for a while, but I'm thinking of moving to YUI, partly because of the less restrictive license.
The component-oriented model used in YUI seems quite similar to the one that I've enjoyed so much in Ext JS, but I'm interested in how deep those similarities are. So I'm interested in feedback from people who've used both Ext JS and YUI. What is the same, and what is different? What do I lose by moving to YUI, and what do I gain?
I think both libraries actually address different needs.
YUI is designed addresses the needs of Yahoo inc. It is very good at building public facing applications where things like graceful degradation, clean markup and accessibility is important.
ExtJS is a very good and well designed full RIA framework that is very firmly targeted at building line of business applications. Features such as a really powerful grid component, strong layout and good professional look and feel.
I've used both quite considerably, although only up to YUI 2.7.0 and have built several full RIA using the frameworks.
Moving an existing application from one to another would be quite differcult as although they share a common ancestor (ExtJS was once YUIext) the frameworks are quite different now.
One major difference is that YUI is distributed under the extremely permissive BSD license whereas ExtJS is distributed under a very viral interpretation of the GPL. For instance, with Sencha's interpretation of the GPL, if you write a SOAP or REST interface specifically to talk to an ExtJS front end then your server code must be GPL and you must provide access to the source since you have "distributed" it by granting access over the web. Sencha does provide a commercial license for their code but if you read their docs carefully you will see that they do not allow you to convert code you wrote against GPL Sencha to another license when you switch to the commercial version. (http://www.sencha.com/legal/license-overview)
In short, if your code needs to integrate with proprietary business logic or commercially licensed systems then you must develop using the commercial version of Sencha from the outset.
For me the difference is that YUI is very lightweight and flexible, whereas ExtJS is heavier, with a bigger footprint and more rigid in the way you use it. YUI is great if you know what you're doing in Javascript and want to extend your power; ExtJS is good if you want a UI abstraction layer that you don't have to mess with much ... but if you do want to make it do things it wasn't designed to do, it can be a real chore.
When building a recent application I had the exact same decision to make YUI or Ext JS.
I ended up going with YUI for a few reasons:
YUI 3 is extremely light weight and fast for simple tasks and the lazy loading makes things even faster.
Graceful degradation was important for this app.
Using YUI 2 widgets in YUI 3 is rather easy and with 3.1 literally weeks away that will become even easier.
YUI documentation is unbelievable and the irc chat and forums are very helpful and actually have people from the YUI development team.
In a time when all applications are migrating to the web, the clear line drawn by Gareth between public facing and Business app doesn't make sense too me.
I prefer the other answers, like the one of Robusto, and compare both framework on technical/financial grounds.
YUI advantages:
Free
Lightweight (HTML + Javascript)
More efficient
Easier to learn and understand
Better documentation and examples
Larger community
Ext advantages:
Richer features & components
Some (undocumented) Server Side driver (like .NET) (although using such libraries on the server seems bad design)
Conclusion:
If your web site doesn't require the extra features provided by ext, go for YUI.
I haven't used ExtJS a lot yet, still in a learning phase, but for what I was able to do with it, I'm pretty sure that even a little more than 1 year ago when I was doing a lot of YUI dev, it would have been much more challenging and the result would not have been as slick.
It's not too say you shouldn't do it, but my advice to you would be to make some serious research and good prototyping of some of the existing features you have to see if YUI will fit your needs. DON'T just base yourself on the examples and the feel of "Yeah seems that would work".
With the GPLv3, it states that as long as your users are all part of the same legal entity that you do not need to share the source code. The verbiage technically states this as if they are not part of the same legal entity, then you need to provide source. But this doesn't mean Sencha won't change the license later. It also doesn't mean they will either.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Any suggestions on which HTML template library would go well with JQuery? Googling turns up quite a number of libraries but I'm not sure whether there is a well recognized library that would stand the test of time.
Well, to be frank, client-side templating is very hot nowadays, but quite a jungle.
the most popular are, I believe:
pure: It use only js, not his own
"syntax"
mustache: quite stable and nice I
heard.
jqote2: extremely fast
according to jsperfs
jquery templates (deprecated):
there are plenty others, but you have to test them to see what suits you, and your project style, best.
Personally, I have a hard time with adding a new syntax and set of logic (mixing logic and template, hello??), and went pure js. Every single one of my templates is stored in it's own html file (./usersTable.row.html). I use templates only when ajaxing content, and I have few "logic" js files, one for tables, one for div, one for lists. and not even one for select's options (where i use another method).
Each time I tried to do something more complex, I found out the code was less clear and taking me more time to stabilize than doing it the "old" way. Logic in the template is an utter non-sense in my opinion, and adding it's own syntax adds only very-hard-to-trace bugs.
jTemplates
a template engine for JavaScript.
Plugin to jQuery...
Features:
100% in JavaScript
precompilator
Support JSON
Work with Ajax
Allow to use JavaScript code inside template
Allow to build cascading templates
Allow to define parameters in templates
Live Refresh! - automatic update content from server...
There is a reasonable discussion document on this topic here, which covers a range of templating tools. Not specific to jQuery, though.
jQuery Templates Plugin created by Microsoft and accepted as an official jQuery plugin.
But note that it’s now deprecated.
I would check out json2html, it forgoes having to write HTML snippets and relies instead on JSON transforms to convert JSON object array's into unstructured lists. Very fast and uses DOM creation.
A couple years ago i built IBDOM: http://ibdom.sf.net/ | As of december 2009, it supports jQuery binding if you get it straight from the trunk.
$("#foo").injectWith(collectionOfJavaScriptObjects);
or
$("#foo").injectWith(simpleJavaScriptObject);
Also, you can now put all the "data:propName" markers in class="data:propName other classnames" attributes, so you don't have to litter your application's content with those markers.
I've yet to update a bunch of the documentation on there to reflect my recent enhancements, but the i've had various versions of this framework in production since 2007.
To skeptics of this question:
Back when Microsoft invented with IE5 what we now know as XmlHttpRequest and the "ajax" pattern, part of the promise behind this was to purely exchange data between a web browser and the server. That data was to be encapsulated in XML, because in 1999/2000, XML was simply just so very hot. Beyond retrieving an xml document over the network with a call-back mechanism, MS's MSXML ActiveX component also supported a pre-draft implementation of what we now know as XSL-T and XPath.
Combining retrieving HTTP/XML, XPath, and XSL-T, afforded developers tremendous creativity to build rich "documents" which behaved as "applications", purely sending, and more importantly, retrieving data from the server.
Why is this a useful pattern? It depends on how complex your user interface is, and how much you care about its maintainability.
When building a visually very rich semantically marked-up interface with advanced CSS, the last thing you want to do is chunk-out pieces of markup into "mini-controller/views", just so you can .innerHTML a document fragment into the main document, and here's why.
One key tenet of keeping an advanced html/css user interface manageable, is to preserve its validation at least during its active phase of development. If your markup validates, you can focus on your CSS bugs. Now, if fragments of markup end-up getting injected during various stages of user-interaction, it all becomes very unwieldy to manage, and the whole thing gets brittle.
The idea was to have all of your markup UI constructs in a single document, retrieve ONLY DATA over the network, and use a solid framework which will at the very least simply inject your data into your markup constructs, and at the most replicate markup constructs which you flagged as repeatable.
This was possible with XSL-T and XPath in IE5+, but virtually no other browsers. Some F/OSS browser frameworks have been dabbling with XPath but it's not quite something we can rely on just yet.
So what's the next best thing to achieve such pattern? IBDOM. Get data from your server, inject it in your document. effortlessly.
You should get a look on Javascript-Templates, this is a small template engine used within the famous jQuery File Upload plugin, and developed by the same author, Sebastian Tschan (#blueimp)
https://github.com/blueimp/JavaScript-Templates
Follow the usage guide made by Sebastian, just remove this line
document.getElementById("result").innerHTML = tmpl("tmpl-demo", data);
Replace it with this one
$('#result').html(tmpl('tmpl-demo', data));
Don't forget to add the div result tag in you HTML file too
<div id="result"></div>
Enjoy