I'm working on a large site’s re-write and redesign. I have been reading up on HTML 5 and wanted to know what the cons are before adopting it for this design implementation.
The design needs to work in A-grade browsers (yes including IE6 :( ), so I'm wondering how <footer> / <section> etc will be rendered (inline/block etc.).
I'd also like to know the pros so that I can sell it to any conservatives within the business.
If we disregard the things which are unchanged since HTML 4.01…
Pros? Not a lot. There are a few things which work in a minority of browsers. There are a few things which work in a minority of browsers but with added JavaScript can support most browsers in a relatively sensible way.
As for cons…
The whole spec is still a draft, and subject to change.
Practically nothing in the spec is supported consistently across browsers (and faking it with JS fails when JS isn't around)
QA tools are immature and often lag behind the specification
It's useful as something to experiment with, but I wouldn't build a mainstream website with it.
Pros:
The more sites are using it, the faster we'll have a reliable spec and support across browsers. So just by building your new site with HTML 5, you help speeding up the advancement of web technologies for all of us.
Cons:
Incomplete QA tools
Incomplete native browser support
The argument that the whole spec is still a draft doesn't really count. Just look at CSS. Even the latest changes to the CSS 2.1 recommendation still have draft status.
If you want to use the HTML 5 specific elements, take a look at http://ejohn.org/blog/html5-shiv/. This approach allows you to use the HTML in browsers that don't support them now.
HTML5 isn’t one thing. There are some parts of HTML5 you can use right now.
For instance, you can change your doctype to the HTML5 one (<!doctype html>). Boom. Your document is now HTML5. Because the HTML5 spec was based on a lot of work figuring out what browsers already do, things like this just work. So, if you prefer the HTML5 syntax, feel free to do that now.
As for the new elements, as has been mentioned, they’re lacking support in IE. You can shim quite a lot of support for HTML5 into IE with JavaScript, if you’re happy with that. Note that unknown HTML elements are displayed as inline by all browsers, so you’d need to add display: block; for new block-level elements yourself for older browsers.
Dive into HTML5 is well worth a read to get you up to speed, particularly Chapter 3.
There are no cons - most of the things will work just as they do in XHTML 1.0 or HTML 4.01. Pros will slowly come in next few years, but bring more semantics (and somehow easier understanding of the content by search engine bots from SEO point of view). HTML 5 moreover enables designers to use any web fonts (not just the limiting basic five such as Arial/Helvetica, Verdana, Times New Roman etc.)
see this as well:
http://www.alistapart.com/articles/semanticsinhtml5/
http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/
http://www.zeldman.com/2009/07/20/web-fonts-html-5-roundup/
Related
I am interested in taking up a learning path which would include web application development using Dashboard Admin UI Kits such as these Link to example
What application and or languages are used when implementing such a
UI ?
What databases are to be used in the backend?
For the UI:
Languages are always the same: HTML, CSS, JavaScript. Yet, they have countless libraries.
For CSS, I would check Bootstrap (or Bulma if you want slightly less pain), which is a simpler but richer one compared to many others.
For JS, I would check some animation libraries (there are many), and probably not start with any JS framework such as React, Angular etc. They might come later once you feel comfortable with JavaScript.
For HTML, you already have dashboard kit already. Though a great idea for learning, but as far as I know using templates is not a common practice for bigger companies etc.
For the backend:
It really depends on what you want to focus more on. Programming languages have advantages and disadvantages. You can work with (almost) any language but increasingly more popular ones are Node.js, Django (Python's popular web framework) etc. For beginning, these two are nice options. Node.js is also closely related to JavaScript, so that is a big plus.
For the database:
You might want to check if you need relational data or not, because that might narrow down your options. MongoDB is easy to learn and to get the basics of backend programming, while SQL (PostgreSQL is a nice example) is a widely preferred SQL option one in the industry.
I haven't found a clear and updated answer, even after googling for a few hours, so here it goes:
I am aware of the advantages and disadvantages of both Microdata and JSON-LD. I also know that Microdata was dropped from W3C (and consequently from the browsers' API). What I'm not sure about is that how it will affect any site where Microdata is used specifically for SEO purpose.
Does Google support JSON-LD for SERPs? What format does it recommend to use? I am looking for updated answers - not from 2011 or 2012 (if they are still applicable though, feel free to post it).
What is more appropriate for a dynamic site with lots of contents (think: 50000 videos, images etc): JSON-LD, Microdata or RDFa? Why?
Consumers that support Microdata support Microdata, no matter if or where Microdata is specified.
It’s conceivable that new consumers might decide not to support it, but the syntax is still very popular and still part of WHATWG’s HTML Living Standard, so it’s probably not going to vanish.
About the consumer Google
Some years ago, JSON-LD was not supported for many of their features, and they recommended that authors use Microdata (and they supported RDFa, too). Today it’s different.
See Google’s Markup formats and placement:
JSON-LD is the recommended format. Google is in the process of adding JSON-LD support for all markup-powered features. The table below lists the exceptions to this. We recommend using JSON-LD where possible.
According to the mentioned table, Microdata and RDFa support all of Google’s data types, while JSON-LD supports everything except their Breadcrumbs feature.
I wouldn’t give much weight to their recommendation. They say that "Structured data markup is most easily represented in JSON-LD format", but I think it’s safe to say that this only applies to authors that generate the structured data programmatically (especially from tools that support JSON).
For authors that manually add the structured data markup, it’s typically easier to use Microdata or RDFa, and using these syntaxes minimizes the risk that an author updates the content without updating the structured data, too (see DRY principle).
JSON-LD vs. Microdata vs. RDFa
Unless you know (and care for) consumers that don’t support all three syntaxes, it doesn’t matter. Use what is easier for you and your tools.
If you have no preference, I would say JSON-LD or RDFa, because contrary to Microdata,
both are W3C Recommendations,
both can be used in non-HTML5 contexts,
both allow to (easily) mix several vocabularies.
JSON-LD if you like your structured data not "intermingled" with your markup (= duplicating the content), RDFa if you like to use your existing markup (= not duplicating the content).
I've opted to go for JSON-LD because it is easier to read and compile. Spotting errors is easy for more complicated dictionaries. It is the W3C and Google recommended standard.
One caveat (major if you need to support it), is that as of May 16 2017, Bing STILL doesn't support JSON-LD
Google's Understand how structured data works now says:
Google recommends using JSON-LD for structured data whenever possible.
It seems reasonable to me to still mix in microdata to avoid duplication of long content, such as articleBody, but generally the industry is JSON-LD all the way.
I discovered that JSON-LD does support breadcrumbs. I applied breadcrumbs using the latest version of Yoast on my wordpress site, and it passed muster with google search console in the rich results test of the live page as well as a crawl of the live page after submitting the sitemap.
It should be noted that Google had deprecated the use of data-vocabulary.org. It wants schema.org.
microdata easy to use with angular 8+
but you can do the same thing with json-ld.
Humanly, you can read attributs easiest with json-ld but there is no big difference between both. Just use what you know how to do to win time
I'm familiar with developing webapps and website with Bootstrap (v3 and v4), but now I'd like to start using Semantic UI.
After experimenting a bit I feel like Semantic UI offer less composabilities than Bootstrap, but I'm probably missing some things.
For instance, I'm still unclear on how to I mute a text? Bootstrap has a text-muted class, but I can't find equivalent in Semantic UI
Question
Can you describe the paradigm shift that is necessary? Here are a few questions that might help you frame an answer:
What should I stop doing/using;
What should I start doing/using instead?
Are there any server-side considerations/restrictions?
N.B.: I'm not looking for a detailed comparison between Semantic UI and Bootstrap.
Well, I had some Bootstrap and a lots of Foundation background before using Semantic UI, and the transition was easy. Now, when I'm forced to use Bootstrap, everything seems illogical there.
So, working almost 6 months on Semantic UI, I learned some of the things that helped me:
When you get the hang of the semantics, it will be considerably easier. When Bootstrap forces you to use weird illogical abbreviations, then Semantic UI is natural language based. For example "ui inverted huge equal width form" will come out the way it sounds because you understand how things work together.
The docs. I think Semantic UI has superb docs with examples, so if you don't know how to do something, you find it from the docs. I've only encountered couple of things you cannot find from the docs (e.g. Nag).
There are some restrictions. For example, older Android, iOS and IE browsers are not supported because of the Flexbox. And there ARE bugs, so probably you have to fork and/or do pull requests and some Github issues and wait for a long time to have them fixed in main repo. Or rewrite some of the components (we ended up rewriting Sidebar because it didn't perform on mobile devices). But we didn't really see point in supporting legacy stuff that much anyway.
The box model and positioning is different to what you've used to in Bootstrap, but in a way, it's a lot simpler when you get the hang of it.
Don't expect a lots of helper classes, write them your own.
Learn to use LESS, Gulp etc. from day one - it will save you from lots of headache and will increase your productivity. Also extending/overwriting Semantic UI is a good idea, when you want your own design.
All in all, we had issues, but looking back, we actually won in development time, because Semantic UI has most all the tools available you need to develop modern UI.
I am writing a detailed estimate for a client (project has been accepted but it is now a matter of explaining the different functionalities) to develop a responsive layout website.
It is not my first development of that kind, but this one is a key account and path must be paved.
The layout will adapt from 300px width to 1200+px and thus virtually to "any" device and browser, but i am a little lost on my commitment to that. With desktop websites it is easy to write in your contract that the supported browsers will be "IE7+, up-to-date versions of FF, Safari, Chrome, Opera", but what do you write about a responsive website?
I have a bunch of devices that i know i'll perform tests with (let's say a PC, a Mac, iPad, iPhone, 2 or 3 Android devices) but what do i say to my client?
I can't write that the "website will work on any device", nor can I give an exhaustive list of the combinations of devices/browsers it will work on. And i don't want to be stuck with "my uncle has seen the website on his 2.2 Android old phone and it doesn't work".
There are a lot of desktop tools around to simulate various viewports and perform tests on, but they hardly work as the "real thing" ; or is there one standard we developers can refer to "contractually"? How do you manage that and what are your commitments towards your clients?
Take on a Progressive Enhancement approach for development. It isn't possible to get a website to be pixel perfect and work the same on every single browser.
Take of a tiered approach (Gold/Silver/Bronze). Old and untested browsers will get the content (IE7, older blackberry, older anything). Newish browsers get content and layout nice (IE8/9, Firefox < 4). And Modern browsers get a typical nice modern website.
It's possible to set this up with appropriate thinking. Build it from the bottom up. Bronze to Silver to Gold. Start with the very minimum setup (only colour, font, text. No divs, no layout, nada). This is your bronze. Next get the silver level setup. Include layout. This layout would be for smaller screens. And finally we would have gold. This would include media queries for larger screens and JS for increased usability and niceties.
It is possible to split between Bronze and Silver for the layout by wrapping your layout within #media only screen{} query. Older browsers do not understand it. The content still appears on those browsers. To split between Silver and Gold it's simply put in a min-width media query and you're set.
Also, ensure that the client understands the definition of "website will work on any device". Just because Opera Mini doesn't support line-height doesn't mean the site doesn't work on it. Here is an article that Brad Frost wrote on that subject: Support vs Optimization: http://bradfrostweb.com/blog/mobile/support-vs-optimization/
I hope this helps a bit
What devices/browsers to target with a responsive layout
You should be targeting a minimal resolution and not a device or browser. You should re-size your design and watch for the design to no longer work comfortably and then use media queries to respond and adapt the design.
Clients:
I think ideally you're looking for a way to explain the concept to customers. What you need to do is communicate the goal, which is to provide the best experience possible. I have found that you should be honest with your customer, let them know that you are following industry best practices and the design will be "functional" across the majority of devices and browsers on the market.
Here is a blurb that I like to use:
Compatibility across platforms: Due to the vast number of web
browsers, platforms and devices, the user experience of the website
may change to best fit the viewing platform.
If you would like to explain, or are asked to explain what this means, I would say:
We(I) always use best practices to meet industry standards for web
design. We(I) do our(my) best to insure that the design will be
"functional" on all main stream platforms. Because of the increasingly
vast number of web accessible devices available, I can not guarantee
that the design will look identical from one device to another.
You must also consider that new devices are created all the time. So you don't want to make your statement too concrete or you will be retrofitting you designs to accommodate the next iWatch or iFridge that hits the market.
Remember to communicate what is really important, that the content gets displayed. For the most part text and images should work almost anywhere. It's the fancy stuff like shadows, rounded corners, video (IE7), and media queries that don't always work but shouldn't obscure content.
Also, web applications can be a bit tricker since some form elements don't work across devices & browsers. (ex: File uploads).
Hopefully this helps.
I'm not a contract lawyer, you may want to run this across a paralegal or law savvy friend for further advice.
Having gone through this experience a lot of times these are the key points i tend to show to client to make them understand the concept.
What is cross browser, platform (OS), screen resolution and device screen size. I tend to take latest screenshots or links of W3C stats to show them some trends in past 2 years and where this market is going. it clearly convince them that they need a responsive layout.
If they want further evidence to these i show them twitter bootstrap and jquery UI and jquery mobile sites on at least 2-3 devices using Adobe Edge Inspect. Laptop, Tablet and Phone can be all on same network and just browse through the site to show them how it responds to different sizes.
I have a list of pros and cons collected over time for IE7, IE6, Chromeframe, Android native browser vs Chrome on Android, IPhone4 vs iPhone5 browser. usually i see which way they are more inclined and if its phone i will make them aware of pros and cons of that market. Most of the time they should understand that its not an app but a responsive site.
When you are writing a proposal do not put in "We will cover for all devices". You can never do that. Be realistic. Create virtaul machine and simulators to test at least the framework you are going to use before making these claims in writing. Setting up VM or Virtual Box is free and you can get Linux and eclipse or netbeans to run dummy phone and tablet and browse your framework on it.
For screen resolution and screen size again W3C stats are very realistic and convincing. Use them and use Resolution test kind of plugins in firefox or chrome and take some screenshots of your past work or just the framework so you can at least show the goodness involved or limitation of what can be done and cannot be done.
Most of the answers here are quite right just wanted to add how you can use both W3C and statistics to convince on the route for responsive layout. There are more than million sample sites online to convince people now and for past 6 month i have found that people do get convinced by step 1 alone.
It's quite clear. Your client wants a modern website. However, all browsers don't support all the modern features. Your client wants to spend money wise and have a site that improve through time. Not grow old soon and new bugs emerge as new browsers are released. This is why Graded Browser Support is for: http://jquerymobile.com/gbs/
Site will be usable with all the browsers. Mainstream browsers will get enhanced user experience. Most modern browsers will get the super cool newest goodies.
Let the client know, the more you "hack" the site to get some feature to work with some defect old browser, the more likely it will break on the new ones. It's not worth the time and money.
Here is what I do when designing responsive websites.
When an old or unsupported browser is detected, the website will simply exclude the jQuery elements that make it responsive, so the result is a fixed width site.
Now, what do you tell your client?
Just be frank. Tell them you made your website responsive for the modern devices out there. For the older devices, their website wont be so good-looking. Show them a couple of examples too. Some big companies, simply display a alert telling the user their browser it outdated and the website won't work properly. One example is Google.
So, essentially, your website works with all devices, but looks better and is responsive on the modern devices and browsers out there.
So this question came up today and I didn't have a specific or scientific answer.
What are the costs associated with using jsf (or tomahawk, faclets, etc., etc.) tags in place of traditional html tags. My gut reaction is that you should use jsf tags in situations where you need the additional functionality they provide, and use traditional tags when you don't. Also I feel like jsf tags would require more resources (since the server has to take them and rerender them as html anyways) than html. Does anybody know what the cost actually is (as far as time and memory)? Also useful information is what is the convention that is in use, pure jsf or a mixture of the two?
Sure there is a cost. Whether that is noticeable or negligible depends on the hardware and the load of the server in question. Profile it and upgrade the server if necessary.
You should however realize that on the other hand you save time and cost compared to implementing the same without help of a component based MVC framework. That's going to be a lot of boilerplate code gathering the paramters, doing validations, conversions, updating model values which is possibly not written efficient as compared to existing and widely used MVC frameworks.
The Sun JSF development team puts performance as high priority and Mojarra is already optimized as much as possible.
Our site http://www.skill-guru.com runs on JSF/ Tomahawk / Rich faces on a tomcat server. We do not see any speed issues here.
As Jeff pointed out , it all gets compiled so there is not much noticeable difference until and unless you really use too much rich faces or other fancy stuff.
JSF does help you make your life easy.
A JSF page gets compiled upon first request (or pre-compiled if you specify that in the config). Thus, it's not like the page needs to be parsed every time it's requested. I don't have any specific numbers relating to time/cpu/memory cost, but I'm sure it's negligible.