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 reading a lot of stuff about HTML 5 recently. Something still looks very fuzzy to me and I hope somebody can help me understand it better.
Is HTML 5 for the "technology" to create the UI only? If I need to create an application to access bank accounts, how is it possible that HTML 5 will replace all other technologies? I mean there must be some kind of web service that the application has to use to access the data on the server and I can't see how that piece can be done with HTML 5.
As with any new technology there is always a lot of speculation from commentators who don't really understand it... It always made me chuckle when I heard people talking about sites being 'Web 2.0' or 'Ajaxy'
Put simply:
HTML5 is just the same old html which we've been using since the nineties but with some improvements from HTML4&XHTML1. There are a few new tags, some of which aren't even new they've just been standardised.
HTML5 provides native support for many features that used to be possible only with plugins or complex hacks (a native drawing API, native sockets, and so on). Plugins, of course, present problems:
Plugins cannot always be installed.
Plugins can be disabled or blocked (for example, the Apple iPad does not ship with a Flash plugin).
Plugins are a separate attack vector.
Plugins are difficult to integrate with the rest of an HTML document (because of plugin boundaries, clipping, and transparency issues).
Although some plugins have high install rates, they are often blocked in controlled corporate environments. In addition, some users choose to disable these plugins due to the unwelcome advertising displays that they empower. However, if users disable your plugin, they also disable the very program you’re relying on to display your content.
This is where HTML5 comes on the scene, smiles, and waves its magic wand of native functionality. You can style elements with CSS and script with JavaScript. In fact, this is where HTML5 flexes its biggest muscle, showing us a power that just didn’t exist in previous versions of HTML. It’s not just that the new elements provide new functionality. It’s also the added native interaction with scripting and styling that enables us to do much more than we could ever do before.
Take the new canvas element, for example. It enables us to do some pretty fundamental things that were not possible before (try drawing a diagonal line in a web page in HTML4). However, what’s most interesting is the power that we can unlock with the APIs and the styling we can apply with just a few lines of CSS code. Like well-behaved children, the HTML5 elements also play nicely together. For example, you can grab a frame from a video element and display it on a canvas, and the user can just click the canvas to play back the video from the frame you just grabbed. This is just one example of what a native code has to offer over a plugin. In fact, virtually everything becomes easier when you’re not working with a black box. What this all adds up to is a truly powerful new medium.
HTML 5 is indeed markup and JavaScript APIs for the browser. It isn't intended to access data on servers.
But it's rarely used on its own.
CSS adds style to content.
JavaScript makes client side code dynamic.
AJAX allows you to make asynchronous calls to services to get data, keeping your UI responsive.
Yes, you still need services.
HTML 5 replaces earlier versions of HTML, nothing more.
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.
We'll start developing a Web application that uses the following:
Spring MVC Framework
Hibernate
MySql or MongoDB (or maybe both)
HTML5 for a mobile app that will run on the browser (This will be a secondary part of the actual Web app)
I've never used any javascript MVC/ MV* framework before. I've been using plain jQuery and other libraries whenever I needed any.
Requirements for the Web app:
Normal login etc.
Dashboard which will show analytics, graphs etc.
A form design tool - e.g. an editable form where users can enter new lines and a live preview of the changes should reflect on a mobile like screen adjacent to it. See how it looks in a mobile view kinda thing. User can add, edit and delete new lines. So it'll be an interactive form building interface.
(This is where I think an MV* library / framework will help me. What say? Or the jQuery can do the trick?)
Requirement for the HTML5 mobile app:
User will access the app from the browser.
It should look like a native app (but actually it'll be an HTML5 app)
It'll have at the most 2-3 pages (with NEXT buttons) and simple textarea for input (e.g. email, phone number etc) and SUBMIT buttons.
(Would using jQuery mobile be the best solution? Or should I use MV* library or anything that gels well with HTML5 and will make my life easier. What to use?)
I'm a bit confused with the array of frameworks and libraries like Backbone.js, Ember.js, KnockoutJS, AngularJS etc.
Can someone please guide me. I'll be very obliged and thankful. I'm not expecting the best framework, I just need the 'best' framework for my situation above. :)
Half a year ago I was sitting in your shoes. I have been using the same stack, had the same design principles. I went with AngularJs and couldn't be more happy :).
I have been evaluating this set of frameworks:
Knockout JS
Backbone JS
Pub Sub
Batman JS
Sammy JS
Sprout Core
JS MVC
Angular JS
And I was taking those conditions under evaluation:
Multiple models? (can we have few separate controllers handling small chunks of DOM separately running smoothly on the same page)
UI & Data Binding? (change in UI is reflected in objects state, and vice versa)
Automatic content switching? (when you navigate to #dashboard or #posts the content change id supported by framework)
Templating? (no need of using 3rd party library for templating)
Integration with different frameworks? (like jQuery)
Supports HTML 5 Local Storage? (does it support local storage or does it have it integrated in the framework)
Unit Testing support (does the nature of the framework makes stuff easy to test)
Most of the frameworks on my list either supported or fulfilled all these conditions. That was surprising for me, as I was hoping one will prove to be best over another.
It turned out that they all are pretty close, so in my case the only way to go was to try them out one by one. After I followed few tutorials, I decided to go with AngularJs and that was the best decision I've ever made :-)
To be honest, pretty much all of the frameworks will help you out. The most important thing for you will probably be a declarative binding of view and model. Most of the frameworks you have chosen will support it.
I suggest you follow the same approach as mine. Write simple app in 3 of them and see whatever feels most natural for your coding style.
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.
Besides the new Google Docs, all the other WYSIWYG web-based rich text editors (ckeditor, tinymce, old Google Docs) I've seen are based on contenteditable or designMode. I personally hate using these editors. It doesn't take much formatting or copying/pasting before the whole experience turns into an exercise in frustration. Returns suddenly start getting double-spaced, unintended formatting gets introduced via pasting from other HTML sources, undo's/redo's are completely broken, formatting becomes excruciatingly difficult to control, etc.
I believe this is one of the reasons Google Docs introduced its own much more constrained, non-HTML formatting engine. Is there any open-source library out there that provides something similar? Thanks in advance.
You could start with the Ace editor (formerly Bespin and Skywriter). It's aimed at code editing, so it's missing formatting and other features, but you may find a useful core of functionality to base a rich text editor on.
In action: http://ajaxorg.github.com/ace/build/editor.html
Code: https://github.com/ajaxorg/ace
Update: As #theazureshadow points out, the current editor doesn't use canvas as I originally reported. Bespin used canvas before it merged with Ace, which uses the DOM. Peeking briefly under the hood, it doesn't appear they are using contentEditable or designMode, though. (There's a <textarea /> that follows the cursor around and spans and divs to show the text - a bunch of custom JS to wire it all together, methinks.)
From ace.ajax.org > History:
Bespin started as part of Mozilla Labs and was based on the
<canvas> tag, while Ace is the Editor component of the Cloud9 IDE
and is using the DOM for rendering.
You're right: it's much nicer.
Is there an open-source library out there that provides [a document editor that doesn’t use the browser to handle editable text, instead using a custom editing surface and layout engine, entirely in JavaScript].
Doubtful.
First, the editor is dubbed "Kix". It's not non-HTML, but it doesn't use contentEditable because it sucks for what they're doing, as you mention. What it does is tricky and bulky to do right, and I'm sure it took them a good bit of effort to create it.
That said, why would Google open source Kix? It undermines their effort to be your documents hub, and it would mean they have to do a bunch of additional work to separate Kix from the rest of Google Docs in a way that doesn't leave it difficult to integrate. The benefit? Not much, seeing as though open source projects sponsored by Google are unlikely to see support in the form of developer-participation in improving it.
As for someone creating a library to do it, I'm doubtful it'll happen in open source. Usually open source projects that are a significant undertaking are university or company sponsored, and that's not likely in this case for the reasons above. Then again, if a developer has an itch for it, there's no telling where it could go…
There's HTE, unfortunately it is slow and misses a lot of basic selection functionality.
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.
Google shows that there are already few generic HTML5 canvas-based libraries available. But no high-quality editing/charting controls that I used to see from "big" control developers like Infragistics, Rad, etc.
Any recommendations on what should I look at?
First of all, I don't think you'll find solutions from big companies for Javascript libraries. People using Javascript are not used to paying high sums for enterprise-ready js libraries ;).
I'll give you a rundown of the possibilities:
Highcharts is a great out of the box solution you may be after. I've used it with great success in one project. It has looots of documentation and is actively being developed on GitHub. It's easy to use, is pretty to look at (don't underestimate the looks "feature") and is interactive: you can bind / attach to events that fire on the elements like "hover over a bar" or "click a point". It does cost $80 bucks for one site for commercial use (non-commercial use is free).
Ext JS 4. Another out of the box solution is a recently (April 2011) released 4th version of a popular Javascript library Ext JS. This forth version now supports plugin-free charting (i.e. no Flash, just native technologies like SVG and VML so it works cross-browser. If you're used to desktop or enterprise features, that you usually don't find in a Javascript library like windows, layout managers, MVC, drag and drop, toolbars, menus, forms, etc., this is definitely for you. Check out the examples here.
gRaphaël is another great library and is under MIT licence (free for commercial use!). It looks a little more "Flash-y" and is more developer friendly / intensive. So you'll have to code a lot of it yourself (it's not a full-blown solution like Highcharts), but if you're fluent in jQuery, you'll feel right at home :). It's strength is the power to code anything you want and you can do lots of animations with it, like in jQuery. All the elements in a graph are SVG nodes so you can attach events to each of those and do some powerfull stuff. The demos are worth checking out.
Flot. Like alexn said, you can use Flot, but I've used it once and was not very fond of it. I don't know what exactly wasn't for me, it's a subjective thing. I'm not very fond of it's looks, but that's just me. Have a look at it yourself.
Other libraries like RGraph or Zingchart. I've not used any of those so this is purely from what I see: they look like they are in their infancy / not polished. I hope they'll improve, but have a look at them anyway and choose your winner.
But you said you want canvas-based controls. Why is that? Is it because canvas is marketed along HTML5. See, Highcharts and gRaphaël are not canvas-based, but I thought this is what you wanted so I put them in anyway. The way gRaphaël works is this (Highcharts work the same way under the hood but that is hidden to the developer): gRaphaël gives you an API (e.g. piechart()) which then creates lots of SVG elements (think of them as <div>s but with more complex shapes and graphics filters) that are then drawn. You can also set event handlers to those elements. But since IE doesn't support SVG (that's a shocker) the library translates those API calls to create VML for IE.
But canvas is different. There are no "elements" per se, you just draw lines and shapes, but you can't just bind to their events with event handlers. So for me, SVG is better (you should see some of the graphics filters that SVG is capable of, like blurring) and I think the libraries are more mature.
But don't take my word for it ;). Check them out and tell me what you think.
Flot
(source: iola.dk)
It's a nice chart control. Flot is actually used for displaying your reputation here at Stack Overflow.
what about google chart
http://code.google.com/apis/chart/
"Google chart tools are powerful, simple to use and free. Try out our rich gallery of interactive charts and data tools.
Get Started
Pie Chart - view source
"
I'm on the ZingChart Team. We render charts in HTML5 Canvas, SVG and Flash (and VML for old IE fallback).
If you have questions, you can reach our team at support[at]zingchart.com with any questions, or http://twitter.com/zingchart.
-Andrew
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 12 years ago.
It is said that the unreleased HTML 5 and CSS 3 can produce the effects and graphics which can be done in Microsoft Silverlight. It thats true then can I skip learning Silverlight and wait for HTML5 and CSS 3?
Silverlight is a tool for developing web applications (RIA - Rich Internet Applications).
Pure HTML+ CSS (even if it is HTML5 and CSS3) will only produce web sites unless you put some code/framework behind them.
Therefore while visually they might look similar they are two completely separate things behind the scenes.
It's like comparing apples and oranges, but one thing is makes HTML 5 + CSS better then Silverlight: It runs on every modern browser, mobile device, etc...
You don't need to wait for HTML5 and CSS 3, they are here today and can be used right now. Web standards aren't 'released' in the way software is, they are standardisations of existing browser implementations.
What front-end technology you choose very much depends on project requirements, some things that are easy in Flash/Silverlight are just not possible yet or really hard to achieve using web standards (think Canvas and WebGL).
There is no definitive answer for this, and there may never be.
HTML5 + CSS + JavaScript, you mean? The future of RIAs does look bright given the promise of these technologies; however, they do not likely represent a replacement for Silverlight right now. If you need to build a complex web app now, Silverlight can do it, and even though some browsers like Chrome, Safari and Firefox have already implemented parts of HTML5, the support is too jagged to allow you to build a stable cross-browser application.
Silverlight, however, should behave the same way in all browser on all OSes.
if you use silverlight (and/or flash) only for a nice layout and some stuff like animations, yuo don't need it - this can be done with html5/css3 only.
but note that silverlight (and/or flash) give your a lot of possibilities to write applications witch can do a lot more stuff.
The only reason I prefere to use Flash/Silverlight over HTML+JS+CSS is, they run pretty much similarly on all platforms and they are independent of browser's code, although html has some standard but coders dont have any standard, similar functionality needs different javascript in different browser, more over rendering html elements is also different on different browser so does printing.
No matter HTML5 or HTML 10 coming in future will attract developers, but not implementing correct standards by OS and browsers will always make them weak enough.
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 was talking with a colleague about a problem we were having and he suggested that one possible solution was to use an IFrame.
I haven't needed to use an IFrame for he last 5 years and I've done full time web application development, but it made me wonder if the concept of the IFrame and Framesets is something that is supported by browsers for backwards compatibility but really shouldn't be actively used in development any more?
it's one of the major application integration methods for facebook and myspace. and most wysiwyg html editors rely on iframe. thickbox uses iframe. drupal uses iframes. and on and on... so not sure if it's so very simple to just call iframe obsolete. i imagine it'll be actively used for a good long while still...
It's the fastest and easiest way to get any of a number of google services into a web page, where the fuller control of the API integration is not needed.
Like anything else, it is situational. It's far from dead, and there's no reason it should be dead. The web's moving to looser coupling, and IFrame is in line with that.
At best the IFrame isn't ideal for rendering local content, but, like others have said, it is the only way to get external web-content into an application without an API and for that reason it is very important to modern web-development.
No, it shouldn't.
It's a cheap standard way to integrate functionality in a single page. Also allows some useful techniques such as COMET
Not sure if it should be dead. For one of the application I worked on for the manufacturing industry, they wanted multiple tabs to be able to run multiple programs on the same page. Knowing using just regular divs using Ajax would just be a little too much for this intensive app, we used iframes. Of course, it doesn't look like iframes to the end user (using some creative Javascripting and CSS), it looks like just a regular tabbed program.
So, saying it's dead is probably a little too soon unless there are better alternatives.
It's extensively used in ad tracking and conversion tracking; it's one of the easiest ways to put a beacon into a site unobtrusively.
I think that iFrames are not dead yet, they can be used for a lot of things and though they slow the loading speed of a website (with a few miliseconds, depends on the content).
iFrames maybe, Framesets NO. this is what i think. some things can be done only with iframes believe me i searched for another solution for a long time but for eg. a jscript can be used 2 or more times with iframes but when used on a single page it may cause conflicts and sometimes only the first thing that was using the javascript is working.
so sometimes iFrames are the right way to do it, if you can`t do it any other way.
No, its commonly used in junction with AJAX.
For example, on a page where you have ongoing AJAX requests you can't disrupt the response by closing it etc. BUT, you may need to provide a file download on the same page which would normally disrupt the AJAX request. To avoid the conflict, you serve the file download through an IFrame so that the AJAX on the host page isn't disrupted.
That's at least one use case for it =)
Iframes are not dead. They are the only method of fighting several extremely annoying bugs in MSIE (such as div overlapping a <select>), and are widely used in banner exchange networks.
If you consider the fundamental building blocks of the web you will realise that the iframe should never be removed. I have the feeling that many web developers do not properly understand the concepts of data centric systems and prefer to work in a procedural, top-down, application centric manner. There are many things done with async HTTP requests and Javascript that should simply use an iframe.
There are two fundamental concepts when it comes to linking content in a data centric world like the web - cross referencing and embedding. Hyperlinks are used to cross reference data while iframes are used to embed data. URLs are used to reference data in both cases.
A simple example is linking to an image. Cross referencing an image would be done as follows:
Link to the image
While embedding an image would be achieved as follows:
<iframe src="someImageURL" />
Of course you could use the "img" element to embed an image instead, but that is specific to images... I vote that the "img" element be removed in favor of using the more generic and flexible iframe.