B2B marketing has been constantly evolving in order to match with the latest technologies, trend and customer preference....
Now, you can make web faster than before with a new picture HTML element.
To get how this element can make web faster, you can continue reading this blog and get huge information on HTML element.
flickr user:Ognian Setchanov
In the near future, the web will be much faster than now. Unfortunately, it is uncommon to be news. However, the speed bump won’t be as devices are getting much faster than before, but they are.
Because some popular and biggest companies have developed something very exceptional, so it won’t be. Well, the web will be faster in very less time as a small group of experienced developers have noticed a problem and decided to solve it as soon as possible for all of us.
One of the major problems is images. When it comes to consider the average size of the page, as of August 2014 it is 1.7 MB in the top 1000 websites. For almost 1MB of the 1.7MB, images account. Check here.
However, if you have a good and fast fiber connection, there is not a big deal of image payload.
But if you are on a mobile network, big and huge images will not just slow you down, but it is also using up your limited bandwidth. It may also cost you money as it depends on your mobile data plan.
But which thing makes that image payload doubly annoying when you are making use of a mobile device? The thing is that you are getting pictures that planned for big monitors loaded on a screen litter bigger than your palm. We can say that it is a waste of bandwidth, allowing pixels most simply that do not require.
Very early, web developers came to know this issue in the growth of what was called the mobile web back. Recently, some of them banded together in order to do something developers have never done before develop a new HTML element.
Initially was the Mobile Web
We all know that browsing the web was not as good as it is today even browsing on the first iPhone was quite horrible. Previously, browsing on a small screen back, required constant tapping to zoom in on content optimized for much bigger screens.
Pictures were taking forever to load over the iPhone’s slow edge network connection. And at that time, there was all that Flash content. And that did not load ever. And it was the iPhone and browsing the Web with the help of Blackberry or other OSes crippled mobile browsers. Clearly, it was worst.
Unavoidably, it was not the devices’ mistake even if mobile browsers did. However in many cases still do. The common problem was the fault of web developers. However, the web is basically flexible, but developers confined it by optimizing websites for large desktop monitors.
There are lots of websites that started developing a second website to address this and it sounds quite funny, but the going solution for handling new devices like the BlackBerry, the then-new iPhone and some of the first Android phones was to use server-side device discovery scripts and redirects users to a dedicated website.
When it comes to these dedicated mobile URLs, often they referred as M-dot websites – usually required a lot of features found on real desktop equivalent. Often websites did not even redirect correctly, leaving you on the homepage while requiring a specific article.
However, M-dot websites considered as a fine example of developers, meeting a problem and figuring out a way to make it more badly. Various web developers did not even jump on the M-dot bandwagon as it is expected that something better will came along.
Responsive Design Killed the M-Dot Star
You may know that Ethan Marcotte (@beep), a web developer, wrote a little article on Responsive Web Design in 2010. In it, he suggested that with the explosion of mobile devices as well as the pain of developing keen M-dot websites, it might make more sense to hold the innately fluid nature of the Web.
Rather than that, he suggested that we should develop websites that were flexible. He also imagined websites that utilized relative widths to fit any screen and worked well it doesn’t matter what type of device was accessing it.
His new vision suggested developers a completely new way of developing sites that flex and rearrange their content based on the size and uniqueness of the device in your hand. However, responsive web design was not taken as a cure, but it was close enough.
When some of the well-known developers made their personal websites responsive, responsive design started grabbing the attention, but unfortunately, it instantly took off when Marcotte and the developers at the Filament Group redesigned the Boston Globe website to make it responsive.
The Globe redesign also exposed that responsive design worked for a lot of developer portfolios and blogs. For most of the part, it is still happening on various websites that you visit on a small screen.
We developers know that it is a problem, but solving this problem is not as simple as it sounds. To solve this image issue, there is need of adding a brand new element to HTML.
Unveiling The Picture Element
The picture element story starts with the developers, who are working on the Boston Globe like Mat Marquis, who would co-author the HTML requirement. Initially, no one was working on the project as was thinking about developing new HTML elements.
But Marquis and other developers just wanted to develop one such website that loaded instantly on mobile devices. Marquis explains,
The browser first downloads all HTML on the page when server sends a page to your browser. Moreover, some modern web browsers are trying to speed-up page load times by downloading images before parsing the page’s body. Long before, it knows where that image will be in the page layout the browser stats downloading the image.
“We started trying to hash out some solution that we could use going forward… but nothing really materialized.” Marquis also says, “we have 10 or 15 developers, and nobody has come up with anything.”
Welcome to the Standards Jungle
It is a thing to decide that whether a new HTML element is needed or not. To navigate the stratified, labyrinthine world of Web standards if no one on your team has ever done such type of thing.
However, the best thing about being naive is that you tend to plow forward without the uncertainty that focuses on someone, who knows how difficult the road will be.
Primarily, the WHATWG is made-up of browser vendors that make it a great place to measure how probable it is that browsers will ship your ideas. Currently, the W3C is where the second group oversees HTML, the HTML WG is based – launched a new idea called “community groups.”
Community groups are the W3C’s attempt to get outsiders involved in the standards process, a place to propose problems and work on solutions. Browser makers and standards bodies are favoring the far more limited and very confusing set proposal.
Someone recommended that the developers start a community group after being shot down by the WHATWG. RICG (The Responsive Images Community Group) was born.
However, the problem with the community groups is that no one in the real working groups pays any kind of attention to community groups. No aware about this, Marquis as well as various other developers hashed out a responsive image solution in the community group.
After efforts of months, the RICG brought its innovative ideas to the WHATWG IRC. As Caceres puts it, “standards bodies like to say ‘oh, we want a lot of input for developers,’ but then when developers come it ends in tears. Or it used to.”
As Paul Irish put it in the WHATWG IRC channel, “[Marquis] corralled and led a group of the best mobile Web developers, created a CG, isolated a solution (from many), fought for and won consensus within the group, wrote a draft spec, and proposed it.
Basically he’s done the thing standards folks really want ‘authors’ to do. Which is why this feels so defeating.”
Great Theory, but show me the browser
If browsers support a proposed standard, the Web only wins. There is not a single browser on the Web supported picture this time last year.
Both the browsers Firefox as well as Chrome committed to support it as possibly years ago; it became a priority for either. Picture was little more than a nice theory.
You can enter Yoav Weiss, a rare developer, who spans the worlds of Web development and C++ development. He was the independent contractor, who wanted picture to become a part of the Web.
He was well-known with C++, a language that most browsers are written in, but he never worked on a Web Browser earlier.
We know that implementing picture was not a small task. Weiss says,
“Getting Picture into Blink required some infrastructure that wasn’t there.” He also added “I had two options: either wait for the infrastructure to happen naturally over the course of the next two years, or make it happen myself.”
The future of the Web
When it comes to the story of the picture element, it is not just an interesting story of web developers, who work together to make the web a great place. It is a quick look at the future. Slowly, the separation among people, who develop the Web and those who develop Web standards is dying.
Moreover, groups like W3C’s community are expanding and websites like Move the Web Forward aim to help fill the gap between developer ideas and standards bodies.
We can also say that picture is about to complete, but the RICG is not going away. It is renaming itself and taking a new project that called Element Queries.
Keep visiting our blog for more information on HTML and its elements as here we cover top stories related to HTML and its elements.