Now that Html5Boilerplate has reached version 2.0 and is oriented around mobile-first design, should Html5Boilerplate Mobile still be used for mobile-first sites? Just wanted to ask b/f I dig through the code of each.
It appears one of the obvious differences is that Html5Boilerplate has switched from CSS reset to normalize, and added mobile-first aspects like respond.js and mobile media query sections. Standard boilerplate appears more active on Github as well. Anyone have any opinion about these two?
Stealing this answer mostly from our mailing list thread on the subject...
HTML5Boilerplate is the one you should use if you are getting started
on websites. It is optimized to work and adapt on mobile browsers.
Mobile HTML5 Boilerplate is optimized for web apps that are explicitly
written to have different UX while on devices other than the desktop.
This means they might want to imitate the UI of native applications
or be close to it.
They may make heavy use of touch-based UI paradigms and other
interactions that are not possible on a desktop browser.
They explictly use media queries and other ways to detect a
non-desktop browser and serve an experience that is different.
When I say web apps, I mean websites that are used intensively to
accomplish certain tasks (like twitter.com / gmail.com / facebook.com
/ admin interface of wordpress.com ). These sites are required to take
advantage of the space available and help users accomplish their tasks
with minimal effort no matter what device.
On the other hand, we do have websites that users visit occasionally
because they found it on some friend's email or on reddit which has
content but users rarely interact with it (other than just visiting it
or at most leaving a comment), in which case html5 boilerplate would
be a good template to use. This would be a good option for most sites
that are content-rich and require minimal user interaction.
Unfortunately for us, mobile platforms are also creating silos by
specifying custom meta tags to use to optimize for their platform.
E.g. Apple recommends using apple-touch-icon meta tag to specify
things specific to webkit mobile browsers. Nokia has its own. We did
not want html5boilerplate to add such cruft to the defaults, but this
would be necessary for someone writing an application tailored to take
advantage of non-desktop devices. There is already a lot of
consistency, but we wish there was more standardization of mobile
optimizations.
We are planning an update to the mobile version with the newer files
as well, but there is no significant disadvantage to using it today. We do not yet have a meeting point where we could just have one project, but we are hoping in the future it does
merge into one :)
No, Html5Boilerplate Mobile should not be used for new projects; it is deprecated.
A deprecation notice was added in July 2015 to the project's GitHub repo (as of this answering -- Aug 2016 -- that was the most recent commit):
The H5BP team decided to no longer maintain Mobile Boilerplate since
HTML5 Boilerplate seems to be a good starting point for any kind of
project.
It depends on approach. Use HTML5 BP if you are going to have same mark-up for you mobile and desktop website. but if you are making separate website for mobile then go for Mobile Boiler Plate
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.
My team is working on a new site which should be cross browser compatible (IE 8+, Chrome, Safari, Firefox, Opera) and cross platform compatible (Desktop, Tablet, Smartphone).
We've been looking at a lot of the new methodologies for achieving this such as HTML 5, responsive design, using JS libraries that abstract a lot of the browser mess away from the user but since the browsers and even MVVM, but the one major issue that I've been facing is how fast the browsers are changing. With both Chrome and Firefox using a model of continuous delivery it becomes harder and harder to test. And from the looks of it other sites have the same problem (it seems like it's hit or miss these days as to whether a site will work in a particular browser)
What suggestions do you or your team have for testing new browsers as they come out?
What things do you do during development to decrease possibility of having code break when a browser update comes out?
And how do you decide when you will or will drop support for a browser version?
NOTE: I've altered the order of your questions to leave the longer answer at the end.
Your questions
What suggestions do you or your team have for testing new browsers as they come out?
Actually, as you said, Chrome and Firefox are continuosly delivering so it eases the process. The last version you have is mostly always the version the user has.
For any other browser (and Chrome and Firefox old versions) just select a version of each and act as a "high pass filter", testing any version up from the one you selected.
How do you decide when you will or will drop support for a browser version?
Take a look at the statistics of browser use. There are many resources such as statcounter, w3counter, w3cschools, or wikimedia. If possible, add an analytics tracker to your page and you will have data about what devices, platforms, browsers, and versions of them the visitors use to access the site.
What things do you do during development to decrease possibility of having code break when a browser update comes out?
The key is to use a well defined methodology, based on the existing standards. Continue reading for a personal recommendation.
Workflow to ease cross-browsing
Step 1: Bootstrapping
At first decide: Graceful degredation versus progressive enhancement. Both are valid techniques, but makes sense using the first to fix existing projects and the second for newly created projects.
Then select libraries to avoid typing existing code, focusing on the 3 languages: JavaScript, CSS, and HTML. HTML5 (+CSS3) is the better choice today but support for older browsers must be provided. The following libraries ease supporting them:
modernizr for feature detection and conditional loading of js or css.
jQuery for ajax and dom related tasks.
normalize.css for normalize default browser styles, rather than just "resetting" them.
Notice that all of the js libraries listed above allow custom builds, an important thing when performance matters.
Html5 Boilerplate provides a strong template from which start the layout. It includes modernizr, jQuery, and normalize.css. Its github repository is a good resource to learn a lot about cross-browsing techniques. This article on its wiki has a nice set of links to start learning.
Step 2: Do the work
Designs should be mobile-first and responsive. This article on html5rocks introduces well why and how.
While "doing the work":
Follow the w3c standards. Avoids using hacks, specially CSS hacks, when possible. Review often the HTML5 specification as it is pretty unstable.
Take care of ECMAScript 5 features when writing javascript. Rely on libraries to avoid code breaks caused by deficient browser implementations. Do not extend the DOM.
Automate tests when possible. Layout and specially layout polishing, including animations, are manually tested cause it's quicker but UI functionalities like form submision can be perfectly tested with automated tests.
Use tools to ease tasks. Chrome + devtools or Firefox + firebug are the very basic must-use, but there are a bunch of tools to ease cross-browsing tests, even automating those tests.
Annex: Tools and resources
Cross-browser testing
Browserstack is just awesome. Allows testing on all devices, platforms, browsers, and versions.
Browserling is an alternative to browserstack. It is developed and maintained by Peteris Krumins and James Halliday, both recognized members of the node.js community and well-known developers. They also published a tool to automate the process called testling-ci, but this is only relevant if using node.js on the back-end.
modern.ie provides tools to ease testing on internet explorer. Developed by Microsoft, the site provides live testing through browserstack and downloadable virtual machine images with pre installed software.
adaptability testing for "responsive design"
respon.si is an online tool meant to test the visually appearance of layouts. It allows selecting a resolution so it's useful for responsive layouts testing. Notice that any other tool to select a resolution can easily do the same.
What suggestions do you or your team have for testing new browsers as they come out?
As part of our definition of done we support the following desktop browsers:
IE8+
Firefox 3.6
Firefox (latest)
Chrome (latest)
Safari 6
The support of the latest versions of Firefox/Chrome is fine because they both provide automatic updates, and so if anybody has a problem on an older version of the browser, it's out of our hands and they should update.
The majority of Firefox/Chrome testing can be done on our machines, but there are obviously discrepancies with how the different OS' handle fonts, and some quirks with native form elements that may or may not carry over to versions on Windows.
To test Firefox versions on OS X I use the "Install all Firefoxes" script that I created, to allow me to run multiple versions of Firefox side-by-side.
Our development team uses Ubuntu and Mac OS as their environments, so we have a dedicated machine with virtual machines for each version of IE, and Chrome/Firefox on Windows, and Safari 6 on OS X.
These virtual machines were setup using the images provided by modern.ie. We're remotely accessing the machine with the virtual machines on so that we don't need to break our workflow and go to another machine.
What things do you do during development to decrease possibility of having code break when a browser update comes out?
The obvious things are avoiding CSS hacks, and making sure that the HTML/CSS/JavaScript that is written meets our code standards, and our definition of done.
If we're using experimental CSS features, we ensure that we're providing vendor prefixed and lastly w3 definitions of properties:
-moz-foo: bar;
-ms-foo: bar;
-o-foo: bar;
-webkit-foo: bar;
foo: bar;
Obviously this introduces some technical debt, but if you're using a preprocessor for your CSS, the overhead of this can be reduced.
We keep a separate stylesheet for IE and load it using conditional comments, so that we can fix problems in IE without affecting the integrity of the rest of the front-end for other browsers. There's a movement lately to moving this in to a shame.css though, which you can read about here: http://csswizardry.com/2013/04/shame-css/
And how do you decide when you will or will drop support for a browser version?
Google Analytics. Segmenting by browser type in Google Analytics is very useful. When usage for a particular browser drops below 10% it's a good time to stop developing new features for it.
You could do something as radical as throwing away all of your hacks/styles for that browser too, but for a smoother transition (and to encourage people to upgrade) it's better to simply stop developing for the older browser, and maybe conditionally display a message.
We dropped support for IE7 recently, and now visitors using IE7 will get a message telling them to upgrade, and they don't get any more fixes or additional features.
Mobile is a whole other kettle of fish, and if your site is completely responsive it's an extra layer of pain.
We've got a bunch of different size/version Android devices, a couple of old iPhones and an iPad kicking around the office that we use for testing the majority of mobile browsers on.
Obviously there are differences with screen size, DPI, browser version etc. The best you can do in this regard is cater for the most common case, and fix any issues as they surface.
design and develop with web standards. validate the web platform. all of the libs/solutions/etc., already listed are phenomenal and quite useful, but if you stick to standards, you'll find you need those libs less and less...at least for gracefully degrading user agent support. i find i use them more and more for progressive enhancement.
i was reading an article about smartphones and features phones, and i was surprised to see that smartphones share only the 28% of the global MArket. In Africa, Asia, South American and so on there are still plenty of featured phones.....Than thanks to Java platform and Brew can run just a few third part made applications.
Now i was also reading another article about native app vs Web applications. Web application are crossplatform and thaks to html5 the gap between them and native apps is gonna be smaller.
My question is, Can features phone (or at least a part of them) run Web applications? SO Web applications are actually targeting also features phone........You just need a browser to run web app, do they have it? And are they gonna support html5 or only html4?
First off, the phrase "Feature phones" has no exact definition. All it really means is that they have less capabilities than "smart phones", but more capabilities than a "simple phone".
One of the capabilities that a smart phone is usually better at is the quality of the browser. Feature phones usually have a less full-featured browser that will likely not support much of HTML5 and usually be somewhat behind the capabilities of a recent smartphone as they are usually trying to work with smaller memory and a slower processor.
Plus, you can generally expect smaller screens and more limited user interaction making it more difficult to interact with a web app.
If you are going to build web applications for feature phone browsers, they would have to be incredibly basic. In my experience, feature phone browsers don't even fully support HTML4. Maybe they've changed since I last had a feature phone, but web browsing in general was almost pointless on my old feature phone. Web pages looked horrible, connection speeds were horrible (less than 3G), and the screen was way too small. Any web applications built for feature phones would have to pretty much be text-only to be usable.
Nokia Asha series support web app. Though they are not smartphone but can work like them except some features.
Is there any single framework with which I can build a css3, html5 website that is compatible for all browsers including IE7 and later? Can http://html5boilerplate.com/ boilerplate help me in this?
You will never get the IE7 or IE8 rendering engine to achieve full compatibility with HTML5, CSS3, and other modern technologies. They are simply not capable of it.
However there are some hacks, tools and plugins which can get you part of the way.
Tools like Modernizr will help you by allowing you to detect which features are supported, to give your site a chance to work around it.
jQuery is a great library anyway, but is particularly good in this context because it abstracts a lot of browser differences away from the developer. Some things are easy in most browsers but a real pain in IE; jQuery takes a lot of that kind of stuff and makes it easy regardless.
Dean Edwards' IE7.js and Selectivzr are both Javascript libraries that give IE support for lots of the CSS selectors which were missing in older versions. This allows you to write your stylesheets without worrying so much about what IE supports. (IE7.js also fixes a number of IE's other glitches and missing features too)
CSS3Pie is a hack for IE that adds support for CSS border-radius, gradients and box-shadow.
There are in fact a whole load of hacks along these lines, all aimed at adding features to older versions of IE which it is missing. Modernizr's website has a big list of them here: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
However there is one big caveat to all of this. Speed. IE<=8 is a slow browser. It has a slow Javascript engine. Virtually all of these hacks are javascript based. You might get away with running a few of them on any given site, but trying to use enough of them to give IE anything like full support for HTML5 and CSS3 will slow the browser down to the point of being unusable.
There is one other angle to approach this question though, and that's Google's Frame plugin for IE. This basically installs the entire Google Chrome browser engine into IE. The user is still running the IE shell, but the web page is rendered as it would be in an up-to-date version of Chrome.
This sounds great, but of course it isn't perfect. The main down-side of it is that the end user has to install it manually onto their computer, which means that you as a web developer have no real control over whether it's there or not. So its not something you can just add to your site and expect everything to magically work.
Finally, you may also be interested in CanIUse.com, which gives browser support tables for various features, allowing you to see at a glance what is and what isn't supported in various versions of each browser.
HTML 5 is more an umbrella term for a variety of technologies than any one thing or framework. Really, any implementation you do should degrade gracefully-- and that is what makes the site browser compatible. Detect what the browser supports, and then have alternatives that are legacy friendly.
Check out: http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/
And: http://diveintohtml5.ep.io/detect.html
Good luck.
Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.
MS is including it in the ASP.net MVC template projects
html5boilerplate won't help you.
As others have said html5 and css3 are very broad terms, there's no framework that implements all of the features provided by both of these. In fact they are not equally supported in browsers that say that they support them. And more, even W3C guys (who write the specs for html5 and css3) are not yet established on what features they will include or what steps will be required to implement them. You get the idea...
But.. if you narrow your requirements to some specific features, like video, audio tags, canvas drawing, nifty css effects, File API, or others, you CAN find frameworks that implement (or try to mimic) them with available technologies in cross-browser manner (more or less).
Is it safe now to develop web application with HTML 5 specifications? or should we wait longer for final standards?
I want to start developing a new project. I want it to be up to date in every aspects. should I wait more for html 5 or I can start programming based on it?
It all depends on your audience.
If most of your audience is going to be fairly hip web developers that know to use a decent browser, you are probably going to be fine using HTML5.
However, if your audience is any government institution (school, etc), business place, etc, you might not want to use it yet. My school currently runs on Internet Explorer 6/7, and one of my teacher constantly complains about that "Your browser is not supported" message at the top of Youtube. These people probably don't have any control over the browser they use, and might be a bit behind due to the IT guys.
Find your audience, and use what you are comfortable using with them.
It depends what you which features you want to implement. HTML 5 is a very broad standard covering video, dynamic bitmaps, geolocation, more semantic tags etc.
No browser has implemented all HTML5 features, all have implemented some
This will tell you most of what you need to know about and which browsers support it.
http://diveintohtml5.ep.io/
Which part were you particularly interested in? Many people want to use canvas which is the dynamic graphics tag (simulates svg in an element). Canvas works on all major browsers except IE, though support for canvas is predicted in IE9
It depends on your audience. If they have the latest browsers then you can start using parts of HTML 5. If you don't have a good understanding of your user base then you might want to use web analytics to understand the capabilities of their browsers. Developers tend to have newer browsers but corporations or schools may not. You should also do some research on HTML 5 and understand if you can get up to speed with it quickly if deployment time is a concern.
Use progressive enhancement. A lot of the HTML5 features (application cache, the custom form fields, the extra semantic tags) will do no harm in unsupported browsers (though you might need the HTML5 shiv from Remy Sharp), but give a bonus to users and spiders who can use them. Other features (video tag, database storage, web workers, geolocation) can use workarounds for compatibility with older browsers - the Modernizer library linked by Mark Pilgrim makes this very easy. If your app is usese Geodata, for example, you could use the browser-based geolocation where available and fallback to something IP-based.
If you had some social networking applications and you wanted your users to interact with them using a mobile device would you use WAP or a slimmed down version of your regular website with HTML?
My train of thought is that WAP is dead or at least starting to bleed to death because of all the mobile web browsers available (Iphone, Opera Mini). Is this a good assumption?
Also, what kind of audience considerations should you take into account when choosing what kind of mobile access you wanted to develop?
I'm ot sure about my target devices. I'm pretty sure my users will be more "modern" so we can assume Windows Mobile, iPhone, and Blackberry devices.
WAP 2.0 = XHTML Mobile Profile. I'm assuming by WAP you mean WAP 1.0 and WML. Pretty much all mobile browsers these days support XHTML MP (or some close cousin).
For best practices on mobile development, refer to the dotMobi Mobile Web Developer's Guide.
I suggest you use something like WURFL to auto-detect mobile browsers, and serve them XHTML MP with Wireless CSS. I've built a mobile front-end for an application in this way, and it works well across lots of mobile browsers (mobile ie, opera, openwave, ...).
You shoud use standard XHTML 1.0 Strict or XHTML Mobile Profile. WAP is going to die very, very soon (if it hasn´t already).
http://en.wikipedia.org/wiki/XHTML_Mobile_Profile
Slimmed down HTML.
WAP sites are universally ugly, in my view, and with mobile browsers becoming more capable, Ajax applications are increasingly possible (and can work well with the limited bandwidth/data plans that people may have.
But if you need to support every mobile device on the planet, you may have to do something with WAP anyway.
What are your target devices? Everything, modern-ish phones, smartphones only....?
Having developed a few mobile applications I would say that the majority of clients support HTML. It is of course safe to serve these clients a slimmed down version of HTML in order to design your application for the common denominator. However, there is still a significant number of clients which only accept WML as their content type and thus HTML cannot satisfy all your users.
If you read the HTTP_ACCEPT header you can determine what the client is able to understand. In my experience it is safer to serve HTML whenever you can and fall back on WML when you have to.
The bottom line is that if you are reluctant to supporting two versions of your site, use slimmed down HTML (preferably XHTML). If you can support WAP in addition to HTML it makes a nice fallback for the clients which do not understand HTML.
Do remember that WAP has strengths of it's own that normal HTTP sites browsed from mobile handsets do not posess.
A major one is that you can get access to WAP billing, where you can charge small amounts of money from customers that may not have credit cards available.
Also you can use the MSISDN (mobile phone number) to uniquely identify and track visitors to you WAP site.