Should I start learning HTML basics, or go directly into HTML5? - html

I am a designer and my only knowledge with programming is ActionScript 3.0. ActionScript is quite different in different versions — ActionScript 3.0 is a lot diffrent than ActionScript 2.0 or ActionScript 1.0, so it’s no good learning 1.0 or 2.0, the best thing is to learn 3.0 and you're good.
I'm wondering if it is the same with HTML?
I want to start learning about XHTML, HTML & HTML5, and CSS3. Should I start learning about the basics of HTML first, would that be usefull to me? Or should I go straight into HTML5?
Please recommend whatever you think would get me started. (Books, great video tutorials, maybe some guy that is good at teaching in video tutorials, advice, tips, anything you consider relevant is welcome.)
Thank you.

HTML 5 is (essentially) HTML 4 with bits added, so learn "HTML".
5 isn't a rewrite from scratch, and it is still in draft form so large chunks of it are subject to change and have limited browser support.

When you think about html, 4 or 5, you need to primarily see it is a language for describing documents and the data they contain. At its core, html is just that. It is gaining new capabilities, but it's still a markup language for documents. People are trying to look at it as a robust programming language, but even the new dynamic features require javascript to assist its functionality. Don't be tricked into thinking html5 is all that different from html4 - They still do the same things, for the most part.
The key to writing good, useful html (Regardless of the version) is proper use of semantics and clean/efficient code authoring practices. If you're using the proper tags and writing very clean code, you're already doing better than some 'professionals' I work with. This is a big deal.
When you look at a document, you can break it down into parts. There are doctypes, meta data, linked resources, media objects (images, embedded objects), text based data (tabular, paragraphs, headings, quotes, lists, etc), forms, frames, and the elements that hold all of this together, with or without styles.
That is essentially the foundation of an html document. You can output it with php or ruby or whatever you like, but a proper document will always contain some (Or occasionally all) of these things. An ideal document will contain these things in the correct places (clean, consistent coding) to serve the purpose they are intended for (semantics).
What html5 introduces are additional elements to satisfy semantic requirements as well as useful, dynamic elements that align well with growing requirements based on how people use and develop websites. For example, there's canvas, a scriptable rectangular element for presenting visual information. Then there is local storage - the ability to save key pair style data into a user's web client database for later access, which would be extremely useful for saving changes made to contenteditable elements (Another html5 feature) on a site, perhaps, if you knew the same client would always be used. There's quite a bit more, but I guess you get the picture.
The new html5 features are extraneous to writing 'good html'. They're useful, but you can learn to write great html without them. In fact, that's exactly what I've been doing for the last ten years before html5 appeared. I recommend starting with the basics - Learn about semantics, what they mean, why we'd use them, and even include new html5 tags (Outside of canvas - Canvas is a useful element, but using it is not necessarily using html). Learn about browser support for elements, then learn to link resources in the head, such as stylesheets and javascript. Eventually, you'll have a good feel for basic html, and you'll start wanting to use more advanced techniques.
For now, if you aren't a master of new html5 features, you aren't missing out. There's some cool stuff, sure, but the spec may still change and you can spend this valuable time learning the things that won't change - The fundamental things that make html coders genuinely useful.
edit: As for resources, check out these sites:
Generally useful resources
Quirksmode - Good blog, browser compatibility tables
html dog - Very basic, would start you off well
HTML5 Semantics and other information
HTML5 Doctor - Easy reading; To learn a bit about new html5 tags, but mostly, their semantic intention (This is important)
A List Apart - A good look at semantics, again.
Dive into html5 - For when you just feel like doing some reading

HTML5 is just the same old HTML but updated to match today's internet. There is no reason (that I can see) to learn the same language but with outdated information. It will only serve to confuse you - I suggest you instead focus on HTML5 and CSS (XHTML is pretty much HTML4 with some stricter rules) and move on from there to whatever interest you most.

Yes, you should start with the foundation, HTML, before learning about the things that depend on HTML

Related

HTML5, what's that all about then?

I've got plenty of experience in HTML, CSS, JavaScript, Jquery, etc. but I've yet to make the plunge into HTML5.
In trying to get my head around HTML5, I've become a bit confused. So it's a relatively new standard and my uninformed brain tells me it's not well supported. Is this true?
I've got a vague idea that there are some 3rd party scripts that improve HTML5 compatibility, again am I right?
Any good tutorials on getting to grips with the basics of HTML5 for an experienced developer?
Ok a lot of questions there but:
HTML5 is quite well supported on most modern browsers nowadays and it's generally safe enought to use as is.
Scripts to improve compatibility? you mean Javascript that detects how old your browser is and depending on the answer show you HTML 4.01 or 5? well maybe but again, it's at the point when it is not required anymore.
Yes: w3schools has a cool one.
All of that said bare in mind that HTML 5 is still in development and not a done deal. Some areas are still being implemented but at the speed things are take this is not an issue for starting to develop your pages in HTML 5.
This website - html5 doctor is a very usefull resource that you can browse looking for what's implemented where and how things are generally going.
I also found this link to be particularly useful when figuring out what's available for each browser and what's not.
Another subject that goes well with HTML5 is CSS3. Check them both out and maybe come back with specific questions ;)
the HTML5 buzzword is being used a lot, but people mostly use it to describe different things.
HTML5 is the newest (and as of yet, unfinished) iteration of the HTML standard, as presented by W3.org.
Purely, HTML5 is the markup language, but it is usually referred to as to include CSS3, and JS (in the form of the canvas element).
In the HTML area, HTML5 boasts some new element tags that should help developers add semantic meaning to their markups(e.g. header, footer, aside) , and also some useful functional elements (progress-bar, video, audio)
In the CSS area, there are some new properties that allow you to animate your elements, and orient them more easily.
In the JS area, you can read up on the Canvas element, which is a good competitor to Flash. It allows you to draw both using vectors, and bitmap data.
As for good references to HTML5, you can use http://html5doctor.com/ or http://www.html5rocks.com/en/
Hope this helps.
Please note that w3schools isn't such a good reference anymore. Although for just looking at the possibilities it's fine I guess.
I recommend the tutorial from Lynda, but there are other sites. Just search at google. It's also possible to buy a book, since there have been written a few already.
Fallback/polyfill Scripts & libraries like Modernizr,Javascript Libraries can help you take care of older browsers. (backwards compatible)
As for the browsers. Use chrome, it supports most of the functions. Look at sites like findmebyip for more information about what is supported.
HTML 5 support is not yet fully integrated in all browsers. They are still in development stage. For studying the HTML 5 the best medium would be w3schools
They have introduced new elements in HTML5 which has reduced our overhead for html. New Elements
CodePlayer
Videos for HTML 5

Methodological concerns about HTML5, SEO, and backwards compatibility

I defied all conventional knowledge, and wrote my HTML5 site first. Now I am writing the HTML4 site and adding a script which detects old browsers. The question I have is mainly regarding web safe fonts. I am aware that it is best practice to use HTML instead of images of pretty text, for the benefit of SEO. However, since the HTML5 website exists with the HTML in the headers, I wonder if it is safe to use images to represent those headers in the HTML4 version of the site. Simply put, will my web client's indexing suffer? I feel that the HTML5 version will ensure good ranking, but I wanted to put it to the community and get an opinion.
Second question, should I create the more accessible version in HTML4 or XHTML?
Finally, is there a simpler way to make a new site backwards compatible, and still be able to make use of newer technology?
After a fair amount of research, I found that it is not so unusual to create a site in HTML5, and implement items for the purpose of graceful degradation.
At this site: spacebug.com/gracefully-detect-old-browsers-and-fallback-from-html5/, the authors recommend not using PHP user agent variables to detect browser capability. It says that there are too many user agents and that headers change, etc. Check out the link for their in-depth explanation. It offers that the right way to do it is to use javascript to check for certain capabilities. Since my purpose is to either render it in HTML5 or render it in XHTML, this makes my life pretty simple.
Once I found that javascript was the way to go, a simple Google search led me to this site: diveintohtml5.info/detect.html. This offers a number of methods for detecting browser functionality as it relates to HTML5.
For those who are not as savvy with the code, or for those who are looking for a quick solution, the second website also offers a link to modernizr.com, which is an "open-source MIT licensed javascript library that detects support for many HTML5 and CSS3 features."
So, thank you all for your input. I have learned a great deal from this experience, and I am hoping it will make everything much more user friendly and efficient.
Happy developing!
Kat

Make a html to pdf converter

I am pretty new to developing softwares and am intrigued by the huge world out there!! I have working knowledge of C/C++ and Java.. I was thinking of making an application that would convert a webpage to a pdf document.. I know there are many solutions available -- both online and offline..But I want to develop my own.. I googled but couldn't find anything that would help me get started..
I want to know how do we go about a conversion process?? How to get started?? What languages and technologies are pre-requisites for making a converter like this??
Thank You
So at least you need to get to the bottom to following specifications:
HTML specification
CSS specification
JavaScript specification
PDF specification
Moreover here are a lot of minor stuff such as Fonts, Decription/Encription algorithms and many many other minor but still necessary things.
I think you can imagine that this is quite a long way to get all this working. In fact, the complexity of such software is the reason why so many companies make money in this field.
Anyway, I'd suggest you to start from the simple things and grow your software gradually. Start with converting HTML to Image, because it is a bit simpler. Take and parse HTML, its CSS, its JavaScript. Clean HTML. Build DOM of the HTML document. Apply styles. Go thru the DOM and draw elements to the image.
Good luck!

Complete list of HTML5 features?

There are some really good resources on HTML5 on the web such as Dive Into HTML5 and http://slides.html5rocks.com and I have used many of the features mentioned in my own applications, so I'm not new to using HTML5.
But as I get further along in my study of HTML5 features, I keep uncovering more and more things that are classified under the heading of "HTML5". The most recent one I've heard about is the keygen tag which allows you to generate public private keypairs on the client side with ease. I'm pleased that this tag exists and also slightly disturbed that I had no idea about its existence till a few hours ago.
So is there a complete list of HTML5 features anywhere on the web? I am aware of the working draft at http://www.w3.org/TR/html5/ but I'm looking for something to the point and easy to understand without having to sift through reams of technical jargon.
I highly recommend the specification for developers.
Basically its what it says on the tin. But to clarify, this is from the press release at the time:
It features find-as-you-type search,
offline access, beautiful typography,
technical references pulled inline,
and alternate styles for handheld
devices or low resolution displays.
The aim? To produce a companion
specification for web developers to
use on a regular basis. All details
that are considered “for browser
vendors” are omitted.
W3C: HTML5 Differences from HTML4

JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY? [closed]

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.
Recently my company has decided to rebuild an enterprise portal, which will be used by people across the globe to resister there product for extended warranty. They have come up with J2EE ( spring MVC ) and Oracle as technology stack for the Business layer, and have decided to use JSF (java server faces) to design the front-end stuff ( User Interface) I am, being Frontend Engineer, want appose JSF since it will give less control over the generated markup to me, also JSF will inject/generate unnecessary markup in to the page, which will act as unhealthy food for the browser. Also it will become difficult to achieve the Browser Compatibility, since I don’t have any control over the markup generated It is hard to apply correct CSS behavior. Also it not possible to use concept like fluid layout , table less layouts.
All this will result in poor User Experience. My idea is developed UI with hand coded HTML then convert those .html files in to JSP’s and plug those JSP’s in Spring MVC architecture.
Having said all this, I need to present a proposal which will justify the replacement of JSF by HTML for UI layer, your inputs/thoughts and suggestions will valuable, please write back.
Also, I don’t believe XHTML as other option, it has to be HTML? Let me know what do you think and what makes you think that way?
Thanks, for stopping by. I do apologies if reading all this has taken a lot of your time.
What you are stating is true when you're using vintage JSF 1.0/1.1 API with "pure" JSF components. There was no builtin component with which you can represent a HTML <div> element (so that you can accomplish the general page layout on a semantic manner). Also, embedding "plain" HTML in a JSF page was a pain because it got rendered outside and before the JSF component tree. You have to put plain HTML in <f:verbatim> tags over all place. The purists and the unawareness are less or more forced to use <h:panelGrid> (which renders a <table>) to position the elements in the page.
Apart from that, during the early JSF ages, Netbeans shipped with a builtin visual JSF editor which enables you drag'n'drop and bind JSF components visually without the need to write any line of code. This obviously generates a lot of at first sight unnecessary and unmaintainable code and the pixel-precise positioning of the elements were "behind the scenes" achieved with a <h:panelGrid>. Those kind of JSF applications are in view of maintainability and web semanticity a complete disaster.
Most of the negative stories you'll hear about JSF with regard to front end development is related to this. Most of the JSF users/observers/ranters from then are currently still blindly focusing on this because of the bad experience they had and/or they think that JSF is nowadays still the same and/or they see the visual editor as part of JSF while it's "just" another (bad) tool. Also most of the ones who says "JSF sucks" are usually ones who started using it with a visual / drag'n'drop editor without having any solid background knowledge of what's happening under the hoods (especially Servlet API!).
Since JSF 1.2 (which is already over 4 years ago released btw), the <h:panelGroup> component got an extra attribute: layout="block" which will let it (finally) render a fullworthy HTML <div> element so that you can bring a more semantic layout using JSF components only. But it's not only that, JSF 1.2 also comes with an improved view handler which enables embedding plain HTML in line among other JSF components without hassling with <f:verbatim> tags. You could nicely put <div> elements around where you want without adding more verbosity.
Even though this was a major improvement, there were still two other major (however not directly UI related) problems with the standard JSF implementation: 1) state management among requests is hard without grabbing the session scope (think of preserving the same data in tables and dropdowns and the conditions of e.g. rendered attribute); 2) everything goes through POST and you can't nicely invoke JSFish actions through GET.
Since JSF 2.0, which is almost already 1 year old, those problems were covered with a new scope, the view scope, and a new set of components for GET actions. Plus, JSP is replaced by Facelets as default view technology. Facelets greatly eases templating and creating composite components without having to resort with raw Java code and/or custom components/renderers. Even though it's XHTML based, it can perfectly render a HTML5 valid respone with just <!DOCTYPE html>. The XHTML is just there because Facelets is under the hoods using a XML based tool to generate the (X)HTML output. The XHTML based templating does in no way imply that it can only emit XHTML/XML.
All with all, your markup concerns are a non-issue when you're using JSF 1.2 or newer and also XHTML (Facelets) shouldn't be an issue since it can perfectly render HTML5 valid markup.
JSF gives you lot of predefined, rich controls that offer functionality would have to implement manually otherwise. The price for it is giving up control to certain degree in how user interact with the application and about HTML generated. It can also stand in the way of integration with JS libraries.
Debugging and testing is considerably simpler with JSP and specially with Spring.
It really depends on feature set of your web site, skills in the implementation team (and support team), time to deliver constraints, etc.
I personally prefer simpler technologies that give more control to the developer (JSP with Spring MVC) just for the internal elegance of the framework but that is never deciding factor ....
I did a stint as a UI Engineer for Barclays, a global bank. Now, I'll be the first to say that the financial industry has a long way to go when it comes to User Interface anything, and Barclays in particular is behind on their technology. That being said, they do know how to build things that effectively and reliably work, and the UI Lead is one of the most amazing minds I've ever had the opportunity to work with. Also, being a bank they are sticklers for compliance.
We were using exactly the alternative you proposed, and it worked well for us. Sites reliably handled millions of users daily with no negative outcomes. UI work was simple, and as a bonus when the Federal Card act came along, the company could hire basic web folks to come in and do the cutup/html work which engineers could then bolt into the system.
As for your XHTML question, ultimately we chose to go HTML 4.01 strict, and here's why: First, w3 has decided not to advance the XHTML working group...in essence, it's on its way to a slow death. Secondly, 4.01 strict is the closest to the HTML5 standard, and can fairly easily be adapted once 5 support becomes more widespread. A hard requirement for us was full compatibility on IE6, and this allowed us to achieve that goal.
In your negotiations, I would personally argue that it's vital that the final product meet current web standards (W3) because that makes it most possible to achieve a site that is compatible with browsers out there (I say most possible because I'm convinced that Microsoft with find a way, somehow, to break everything that I build eventually...it's how they roll) Secondary for your site might be SEO concerns with non-compliant code, and hindrances to accessibility such as screen reader support. You might also try outputting two similar (simple) sites using either technology and do an analysis of performance. In the case of one website I worked on that was served 1 million times per day, a 5k file size savings translated to 5gb of data daily.
Good luck! This is just one of many reason I got away from big corporate jobs using Java and Oracle....
I think jQuery based components coupled with an action based framework are the way to go. You get complete control over the page, very few surprises, fast development, and ultimately faster page performance.
I've built apps with both JSF, and MS ASPX + DevExpress components. In the end I just want more control over what ends up on my page. jQuery is HUGELY popular, so there is no lack of JS talent in the market. Ajax is almost a no-brainer with jQuery too.
Also, for building database driven wep apps in Java nothing beats the speed of the Tagger Cat framework. It may be old school MVC, but it is seriously database focused, and nice to work with.