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.
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 9 years ago.
I've started learning and researching HTML5, I only ever studied HTML classic some 6 years ago and I never got quite far with it.
I want to build a website and publish it to the WWW.
Should I stick with HTML4 for now? Or should I just jump straight into HTML5?
I've read & I understand that a lot of the new elements are not supported, but I feel a bit stupid to type outdated tags. Are HTML5 elements more supported in 2013?
Is it better to just start with 5 now, as the future is HTML5?
I've also started doing CSS3 and I think it would benefit me rather than CSS2.
Thank you everyone.
I suggest you give "The truth about html5" a read if you have the time.
Html5 so to speak offers a lot of new stuff. But the reality of the market is a bunch of stuff either just plain works with a handful of browsers, and other stuff has been around for years and simply got included under the so to say html5 branding.
Also keep in mind that ie8 still represents a huge piece of the pie of the ie landscape and will do so for years to come. In the end it all comes down to what your project target audience is and how many percent of users you are willing to sacrifice or allowed to sacrifice.
Caniuse.com should be of good use to you, and understanding when and how too use polyfills too.
Myself I manage a big site which uses a bunch of html5, css3, and responsive design that scales from mobile phones to tablets to desktops, and works just fine in ie7 too.
But it didn't suffice to say hey let's code it in html5, but instead took a lot of reflection and compromises to get there.
So actually my answer would be: use the parts of css3 that degrade gracefully as much as you like. The parts of html5 that you find indispensable ..at the condition you have a fallback polyfill in place. And the rest ..think 20 times before jumping on the buzzword bandwagon.
In the end you don't even have to choose between html4/5 or css2/3. You can mix and match both easily .. as the latter simply build on the previous. As long as you know what you are doing, and why.
But yes learn it !
You should code your website in a language that meets your website's requirements.
What I mean by this is if your proposed website will include features of html 5, then you should write it in html 5.
You could most probably achieve the same or a similar effect using html 4, but why go to the bother when html 5 has built in features to help you.
I personally would use html 5 anyway as you are essentially future proofing your project for some years to come.
Also use CSS3 but just check the availability of rules in browsers.
Hope this helped.
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.
First off, kudos to the amazing apache cordova team for making a platform-independent native-like app-building platform - great stuff.
But as we know that HTML5 is still in the draft mode, and i'm thinking of applying Cordova in that direction, what are the technical limits for Cordova right now?
And what's the pros and cons compared to Sencha Touch 2, as i see ST2 popping up during my Cordova searches.
There are no technical limits on Cordova in the sense you're thinking of.
Cordova provides a means to package JS, HTML and CSS in an app, which is run in a native web view. You may hear an argument that any new features added to native SDKs can't be used because you have to wait for Cordova to implement it. That's false, there's nothing stopping anyone from accessing the new features natively through JS.
The technical limits are actually on the browsers that your web tech runs in.
Before iOS5 there is no position: fixed, so that's a limit for developers who want to support iOS5<. They're forced to use something like iScroll or actually take the hybrid approach by mixing a UINavigationBar with the UIWebView. I've done that and it was difficult.
Another limit is the click event taking 300ms to fire, so responsiveness is bad. This has been solved many times though, most recently by Google
There's plenty of other problems out there, like flickering during transitions and things that Thomas Fuchs has blogged about. Seriously, that guy is a genius.
I once came across a bug which caused the page resolution to decrease by showing and hiding child divs inside a parent div that had a css transform applied. Really strange stuff.
Sencha Touch is a good framework that you can try out for your web apps but it's not related to Cordova on a functional level
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.
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.
I found this W3C proposal for CSS variables and was wondering if any modern browsers (i.e. IE7+, Firefox 5+, Chrome) implement them yet?
As of this week, WebKit -- which is used by Safari and Chrome -- will be working to implement CSS variables.
http://trac.webkit.org/changeset/120154
https://developer.mozilla.org/en/CSS_Reference
This is a reference to MDN - they do a pretty good job of listing known browser compatibility. What is/isn't possible is going to be dependent upon each individual css rule. The world of web development would be a lot easier if everything followed the specs perfectly; but that is rarely the case. The #variables rule you referenced isn't listed there, so I'm guessing you're out of luck. Though there are a lot of mobile browsers coming out as people keep buying newer phones - so you might find somewhere that can use this out in the wild world of mobile browsers.
I don't know of any browser that uses CSS variables like that. The W3C document you linked was only a proposal, not a standard. Even stanards take a while to get full support in browsers, so I'd imagine widespread implementation is a ways off regardless.
If you want that sort of functionality though, you can look into something like LESS or Sass.
Variables are listed as "working draft" in CSS3, or "exploring phase" which means there is no agreement how best to implement it, or even if it should be.
Browser support will be constantly a moving target so the answer "No" is difficult to stake and still be accurate when you read this. Variables aren't even listed on most browser comparison charts (March 2012)
This is not standard in most browser rendering of CSS, it may be part of a working group for the css3 spec though I do not believe I have seen mention of it previously.
It is possible to achieve this kind of effect with the addition of other libraries, the one I am most familiar with is called less CSS which supports some cool stuff like variables and nesting rules but it works by translating that to long form CSS.
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 heard Joel and Jeff talking about sIFR in one of the early podcasts. I've been using it on www.american-data.com and www.chartright.us with some fairly mixed results.
Yesterday I was informed that the first line of text on my website appeared upside down in Internet Explorer 6 without flash player. I'm pretty sure that assessment was wrong, owing to no flash player = no sIFR. But I'm getting some odd behavior on my pages, at least in IE 6, 7 and 8. I only really wanted to use sIFR because my fonts looked crummy on my computer in Firefox.
My question is: if you use sIFR, when do you use sIFR? In which cases do you disable sIFR? When is it better to just use the browser font?
You use sIFR moderately, say for headlines. Try not to use it for links, because links in Flash don't work as well as normal HTML links. It also makes little sense to use sIFR only for text that never changes, an image would work a lot better.
I haven't heard about the upside-down problem in a few years now, but in any case, that's an issue with IE 6 and (an old?) Flash player. In any case, it always makes sense to test thoroughly.
Also, did you look into sIFR 3 lately? It's much improved over v2.
I had plenty of headaches after implementing sIFR on my last website project. Most of the problems were to do with browser inconsistencies like you are describing. Text would appear in odd places, not wrap properly or just not display the way I wanted it to. I found that, as per usual, firefox was displaying nicely while I had to implement several different css hacks in order to get the same code to display properly in IE7 and IE6.
I say stick to standard browser fonts if you can, but if the project / client requires you to use it then make sure you test it thoroughly in all browsers and with various flash blockers etc.
Try to consider up front what kind of headache you're creating for yourself (if you are, which isn't always the case) by implementing sIFR. It's probably advisable to only use it when your site design is relatively straightforward. As soon as you start having to deal with specific browser rendering exceptions (CSS, for instance) due to a complex design, you're going to run into problems related to sIFR. And if you design sites for clients, it's tough to go back and tell them halfway through that sIFR is going to have to be removed. So try to identify issues up front.
One example we ran into was having sIFR titles, and then directly to the right of the title, say about padding-right: 20px (so, dependent on the width of the title text), some kind of icon. That led to a lot of hassle, making us wish we hadn't started using sIFR in the first place.