Can’t seem to pass test no.4 which says; " Each .main-section should have an id that matches the text of its first child, having any spaces in the child’s text replaced with underscores ( _ ) for the id’s."
Here is my code:
<main id="main-doc">
<section class="main-section" id="Introduction">
<header>Introduction</header>
<article>
<p>
Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.
</P>
</article>
</section>
<section class="main-section" id="Progressive_Web_App_Advantanges">
<header>Progressive Web App Advantages</header>
<article>
<p>Progressive Web Apps should be discoverable, installable, linkable, network independent, progressive, re-engageable, responsive, and safe. To find out more about what these mean, read Progressive web app advantages.
Google uses a helpful acronym for us to understand why PWAs are so effective: FIRE – Fast, Integrated, Reliable, and Engaging. This acronym is itself a perfect explanation of why PWA is in trend amongst developers</p>
</article>
</section>
<section class="main-section" id="What_is_a_Progressive_Web_App?">
<header>What is a Progressive Web App?</header>
<article>
<p>
Progreesive Web Apps are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features.
For example, web apps are more discoverable — it's a lot easier and faster to visit a website than install an application, and you can also share web apps via a link.
On the other hand, native apps are better integrated with the operating system and therefore offer a more seamless experience for the users. You can install a native app so that it works offline, and users love tapping their homescreen icons to easily access their favorite apps, rather than navigating to it using a browser.
PWAs give us the ability to create web apps that can enjoy these same advantages.
It's not a brand new concept — such ideas have been revisited many times on the web platform with various approaches in the past. Progressive Enhancement and responsive design already allow us to build mobile friendly websites. Working offline and installing apps was possible in the Firefox OS ecosystem a few years ago.
PWAs, however, provide all this and more, without getting rid of any of the existing features that make the web great.
</p>
</article>
</section>
<section class="main-section" id="What_makes_an_App_a_PWA?">
<header>What makes an App a PWA?</header>
<article>
<p>As we hinted at above, PWAs are not created with a single technology. They represent a new philosophy for building web apps, involving some specific patterns, APIs, and other features. It's not that obvious if a web app is a PWA or not from first glance. An app could be considered a PWA when it meets certain requirements, or implements a set of given features: works offline, is installable, is easy to synchronize, can send push notifications, etc.
In addition, there are tools to measure the completeness of an app in percentages. (Lighthouse is currently the most popular one.) By implementing various technological advantages, we can make an app more progressive, thus ending up with a higher Lighthouse score. But this is only a rough indicator.</p>
<p>There are some key principles a web app should try to observe to be identified as a PWA. It should be:</p>
<ul>
<li>Discoverable, so the contents can be found through search engines.</li>
<li>Installable, so it's available on the device's home screen.</li>
<li>Linkable, so you can share it by simply sending a URL.</li>
<li>Network independent, so it works offline or with a poor network connection.</li>
<li>Progressive, so it's still usable on a basic level on older browsers, but fully-functional on the latest ones.</li>
<li>Re-engageable, so it's able to send notifications whenever there's new content available.</li>
<li>Responsive, so it's usable on any device with a screen and a browser — mobile phones, tablets, laptops, TVs, fridges, etc.</li>
<li>Safe, so the connection between you and the app is secured against any third parties trying to get access to your sensitive data.</li>
<h2>Is it worth doing all that?</h2>
<p>
Absolutely! With a relatively small amount of effort required to implement the core PWA features, the benefits are huge. For example:
</p>
<ul>
<li>A decrease in loading times after the app has been installed, thanks to caching with Service Workers, along with saving precious bandwidth and time. PWAs have near-instantaneous loading (from the second visit).</li>
<li>The ability to update only the content that has changed when an app update is available. In contrast, with a native app, even the slightest modification can force the user to download the entire application again.</li>
<li>A look and feel that is more integrated with the native platform — app icons on the homescreen, apps that run fullscreen, etc.</li>
<li>Re-engaging with users via system notifications and push messages, leading to more engaged users and better conversion rates.</li>
<p>
There are many success stories of companies trying the PWA route, opting for an enhanced website experience rather than a native app, and seeing significant measurable benefits as a result. The website <a href="https://www.pwastats.com/" target="_blank">PWA Stats</a> shares many case studies that indicate these benefits.
</p>
<p>
The best-known success story is probably <a href="https://stories.flipkart.com/" target="_blank">Flipkart Lite</a> — India's largest e-commerce site rebuilt as a progressive web app in 2015, which resulted in 70% increase in conversions. The AliExpress PWA has also seen much better results than the web or native app, with a 104% increase in conversion rates for new users. Given their profit increase, and the relatively low amount of work required for the conversion to PWAs, the advantage is clear.
</p>
<p>
Early stage emerging startups like <a href="https://www.couponmoto.com/" taeget="_blank">couponmoto</a> have also started using progressive web apps to drive more consumer engagement, showing that they can help small as well as big companies to (re-)engage users more effectively.
</p>
<p>
You can check the list at pwa.rocks for more examples. Particularly worth mentioning is the hnpwa.com page — this lists an example implementation of the Hacker News website (instead of the usual TodoMVC app), in which you can see the use of various front-end frameworks.
</p>
<p>You can even generate PWAs online using the PWABuilder website.</p>
<p>For service worker- and push- specific information, be sure to check the <a href="https://www.mozilla.org/" target="_blank">Service Worker Cookbook</a>, a collection of recipes using service workers in modern sites.</p>
<p>It's well worth trying out a PWA approach, so you can see for yourself if it works for your app.</P>
</ul>
</article>
</section>
<section class="main-section" id="Browser_Support">
<header>Browser Support</header>
<article>
<p>As mentioned before, PWAs don't depend on a single API, but rather using various technologies to achieve the goal of delivering the best web experience possible.</p>
<p>The key ingredient required for PWAs is <a href="https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API#service_worker_concepts_and_usage" target="_blank"></a> support. Thankfully service workers are now supported on all major browsers on desktop and mobile.</p>
<p>Other features such as Web App Manifest, Push, Notifications, and Add to Home Screen functionality have wide support too. Currently, Safari has limited support for Web App Manifest and Add to Home Screen and no support for web push notifications. However, other major browsers support all these features.</p>
<p>Some of these APIs are experimental, with the documentation still in draft, but seeing success stories like those of Flipkart and AliExpress should convince you to try and implement some of the PWA features in your web app already.</p>
<p>Above all you should follow the progressive enhancement rule — use the technologies that provide such enhancements only where they are supported, but still offer the basic functionality of your app if it isn't. This way everybody will be able to use it, but those with modern browsers will benefit from PWA features even more.</P>
</article>
</section>
<section class="main-section" id="An_Example_Application">
<header>An Example Application</header>
<article>
<p>In this series of articles we will examine the source code of a super simple website that lists information about games submitted to the <a href="https://js13kgames.com/" target="_blank"></a> category in the js13kGames 2017 competition. You don't have to think about what the actual content on the website is — the main point is to learn how to use PWA features in your own projects.</p>
<p>You can find the online version at mdn.github.io/pwa-examples/js13kpwa (also see the source code), which we will be carefully explaining in the next few articles.</p>
</article>
</section>
<section class="main-section" id="Architecture_of_an_App">
<header>Architecture of an App</header>
<article>
<p>There are two main, different approaches to rendering a website — on the server or on the client. They both have their advantages and disadvantages, and you can mix the two approaches to some degree.</p>
<ul>
<li>Server-side rendering (SSR) means a website is rendered on the server, so it offers quicker first load, but navigating between pages requires downloading new HTML content. It works great across browsers, but it suffers in terms of time navigating between pages and therefore general perceived performance — loading a page requires a new round trip to the server.</li>
<li>Client-side rendering (CSR) allows the website to be updated in the browser almost instantly when navigating to different pages, but requires more of an initial download hit and extra rendering on the client at the beginning. The website is slower on an initial visit, but can be faster to navigate.</li>
<p>Mixing SSR with CSR can lead to the best results — you can render a website on the server, cache its contents, and then update the rendering on the client-side as and when needed. The first page load is quick because of the SSR, and the navigation between pages is smooth because the client can re-render the page with only the parts that have changed.</p>
<p>PWAs can be built using any approach you like, but some will work better than the others. The most popular approach is the "app shell" concept, which mixes SSR and CSR in exactly the way described above, and in addition follows the "offline first" methodology which we will explain in detail in upcoming articles and use in our example application.</p>
</article>
</section>
<section class="main-section" id="App_Shell">
<header>App Shell</header>
<article>
<p>
The App shell concept is concerned with loading a minimal user interface as soon as possible and then caching it so it is available offline for subsequent visits before then loading all the contents of the app. That way, the next time someone visits the app from the device, the UI loads from the cache immediately and any new content is requested from the server (if it isn’t available in the cache already).
</p>
<p>
This structure is fast, and also feels fast as the user sees "something" instantly, instead of a loading spinner or a blank page. It also allows the website to be accessible offline if the network connection is not available.
<p>
We can control what is requested from the server and what is retrieved from the cache with a service worker, which will be explained in detail in the next article — for now let's focus on the structure itself.
</P>
<h3>Why should I use it?</h3>
<p>
This architecture allows a website to benefit the most from all the PWA features — it caches the app shell and manages the dynamic content in a way that greatly improves the performance. In addition to the basic shell, you can add other features such as add to home screen or push notifications, safe in the knowledge that the app will still work OK if they are not supported by the user's browser — this is the beauty of progressive enhancement.
</p>
<p>
The website feels like a native app with instant interaction and solid performance while keeping all the benefits of the web.
</p>
<h4>Being linkable, progressive and responsive by design</h4>
<p>
It's important to remember the PWA advantages and keep them in mind when designing the application. The app shell approach allows websites to be:
</p>
<ul>
<li>Linkable: Even though it behaves like a native app, it is still a website — you can click on the links within the page and send a URL to someone if you want to share it.</li>
<li>Progressive: Start with the "good, old basic website” and progressively add new features while remembering to detect if they are available in the browser and gracefully handle any errors that crop up if support is not available. For example, an offline mode with the help of service workers is just an extra trait that makes the website experience better, but it's still perfectly usable without it.</li>
<li>Responsive: Responsive web design also applies to progressive web apps, as both are mainly for mobile devices. There are so many varied devices with browsers — it's important to prepare your website so it works on different screen sizes, viewports or pixel densities, using technologies like viewport meta tag, CSS media queries, Flexbox, and CSS Grid.</li>
</ul>
</article>
</section>
<section class="main-section" id="Structure_of_our_Example_Application">
<header>Structure of our Example Application</header>
<article>
<p>
The is <a href="https://mdn.github.io/pwa-examples/js13kpwa/" target="_blank">js13kPWA</a> website structure is quite simple: it consists of a single HTML file (index.html) with basic CSS styling (style.css), and a few images, scripts, and fonts.
</p>
<h4>The HTML</h4>
<p>
From the HTML point of view, the app shell is everything outside the content section. The <head> section contains some basic info like title, description and links to CSS, web manifest, games content JS file, and app.js — that's where our JavaScript application is initialized. The <body> is split into the<code><header></code> (containing linked image), <main> page (with title, description and place for a content), and<code><footer></code> (copy and links).
</p>
<p>
The scope rules for constants are the same as those for let block scope
variables. If the const keyword is omitted, the identifier is assumed to
represent a variable.
</p>
<h5>The CSS</h5>
<p>
The CSS is also as plain as possible: it uses<code>@font-face</code> to load and use a custom font, and it applies some simple styling of the HTML elements. The overall approach is to have the design look good on both mobile (with a responsive web design approach) and desktop devices.
</p>
<h6>The main app JavaScript</h6>
<p>
The app.js first of all it generates the content based on this template:
</p>
<p>
Next, it registers a service worker:
</p>
<p>
<code>
if('serviceWorker' in navigator) {
navigator.serviceWorker.register
('/pwa-examples/js13kpwa/sw.js'); };
</code>
</p>
<p>
The next code block requests permission for notifications when a button is clicked:
<code>
var button = document.getElementById
("notifications"); button.addEventListener('click', function(e) {
Notification.requestPermission()
.then(function(result) {
if(result === 'granted') {
randomNotification();
}
});
});
</code>
</p>
<p>
The last block creates notifications that display a randomly-selected item from the games list:
<code>
function randomNotification() {
var randomItem = Math.floor(Math.random()
*games.length);
var notifTitle = games[randomItem].name;
var notifBody = 'Created by '+games[randomItem].author+'.';
var notifImg = 'data/img/'+games[randomItem].slug+'.jpg';
var options = {
body: notifBody,
icon: notifImg
}
var notif = new Notification(notifTitle, options);
setTimeout(randomNotification, 30000);
}
</code>
</p>
</article>
</section>
<section class="main-section" id="Reference">
<header>Reference</header>
<article>
<p>
All the documentation in this page is taken from <a href="https://developer.mozilla.org/en-US/" target="_blank">MDN</a>
</p>
</article>
</section>
