TURK GUZELI – BOOK YOUR BEAUTY SESSION ONLINE IN TURKEY

APP Available only in Turkey .

Development : Naro Dev

Pneu Service Dz – Vente En Ligne Des Pneus

https://pneuservice.dz

Development : Naro Dev

Garphics : Graphéin

Medicocare.dz – Medical Equipments

https://medicocare.dz/

A Narodev Creation :
– Amine G –
– Ilyes A –
– Mohammed .N.B –

Saiko Sushi – Japaneese Food .

Here at TechLaunch, we take a no-nonsense approach to web dev. We don’t waste time with excessive theorizing, learning about “legacy” technologies, or spelling out the “elopment” in web development. Our students come to us to help them get into new careers, so we focus on the only things that truly matter: the skills that employers are actually looking for in the 2018 job market, like for example how TikTok algorithm works.

We work with dozens of small, medium, and large-scale employers here in Miami, and have placed students in web dev positions throughout the city. Through extensive conversations and in-depth hiring processes, we have determined that there are five major skills that employers are looking for in junior web developers.

So without further ado, here are the five skills you’ll need to land a web dev job in 2018:

1. DESIGN SKILLS

Before you even start coding a website, you’ll need to have the overall design in mind. While design skills generally fall in the purview of web designers [LINK] (rather than developers), developers do need to understand some basic (and some not-so-basic) design principles in order to be good at their jobs. You can visit here to see the necessary design skills required to be a good hire.

Responsive & Mobile-First Design

All web developers who want to be employed in 2018 must know how to build mobile-first websites that are responsive to all screen shapes and sizes. If you build a website that looks great on your giant HD desktop screen, but looks like a pile of garbage on the CEO’s new iPhone X, your employer isn’t going to be happy with your work.

Design Paradigms

Design paradigms like Google’s “material design” and Apple’s “flat design” aren’t just there to make your websites look pretty. Aside from making websites feel more familiar, modern, and integrated into the cutting-edge internet trends that viewers are accustomed to, design paradigms also help make websites more user-friendly and functional.

Google’s Material Design “Floating Action Buttons” are a great example of functional design. Chances are, you’ve seen these little floating buttons before; in your gmail account, in your calendar, or on a million other websites you’ve used. When you see it, you automatically know where to click. You don’t have to think about it, it’s second nature.

Such is the power of the design paradigm.

UX, UI & Usability

The three u’s — user experience, user interface, and usability — are buzzwords thrown around a lot in the tech community… and for good reason. Ease of use and customer satisfaction are pretty much the primary goals of the entire web development process. UX/UI/usability skills are important aspects of web development training that real-world employers are actively looking for.

Progressive Web Apps

The progressive web app is a relatively new design principle, introduced a few years ago by some innovative folks over at the Googleplex.

The idea was to combine the best parts of HTML-based websites and native mobile apps, while avoiding the pitfalls of both of them. These web-based mobile apps (or “progressive web apps”) are basically just websites that are designed to look and feel like mobile apps when accessed through a mobile device.

Progressive web apps offer “native-like” and “offline-first” experience.

Progressive web apps have some major advantages over traditional mobile apps. For one thing, they are much easier (and cheaper) to design and develop, since you only need to make one version for all devices. Since they run in the browser, they are truly cross-platform. And luckily for you, as a web developer, they’re built with simple HTML, CSS, and JavaScript… just like your average website. So you don’t need to learn an entirely new set of skills in order to build fully functional mobile apps.

Progressive web apps can download assets into the smartphone’s cache so that your “app” can run offline. They can go “full screen” like a native mobile app, by hiding the browser. They can allow the viewer to add the website to their home-screen with a single click (with a custom app-icon, no less!). Progressive web apps can access some parts of the smartphone’s hardware, send push notifications even while the browser is closed, run much faster and smoother than traditional mobile websites, and more. Google has already developed a framework for you to create progressive web apps. Who knows what the future may hold?

Many big internet companies, including Twitter, Forbes, and eBay, have switched over to progressive web app frameworks for their mobile sites. Employers in today’s market are making very generous offers to developers who can create progressive web apps for their companies.

Some of the companies around the world that have switched to progressive web apps for their mobile sites.

2. FRONT-END WEB DEV SKILLS

HTML/CSS

HTML is the fundamental building block of the internet. It creates all the pieces of your websites.

CSS makes the whole thing look pretty.

Without these two basic skills, you are not a web developer.

JS, jQuery, React.js

For web developers, JavaScript is just as fundamental as HTML and CSS. While HTML and CSS take care of the structure and design of your websites, JavaScript takes care of its behavior. It allows users to interact with your website, and for your website to interact with users.

In order to just barely qualify as a web developer, you need to know some JavaScript and jQuery. In particular, knowing how to handle ajax requests, attach event listeners, and manipulate the DOM with JavaScript is a must. Good knowledge of frameworks like React can unlock access to higher end opportunities.

GitHub

When traditional employees need to work together as a team, they do it in an office. When web developers need to work together as a team, they do it on GitHub.

GitHub, and other “version control” platforms, allow you to collaboratively edit code with your coworkers (and others), while still maintaining the integrity of previous versions through time. So if the boss hires his fifteen-year-old nephew to “modernize” the code, you don’t lose seven months of work. You can always revert to an earlier stable version.

GitHub also allows you to view all the changes that were made in each version, so it makes it much easier to find new bugs in the code.

Google Chrome’s Developer Tools

Ever wonder why so many web developers prefer Google Chrome over other browsers? Well, yes, it is generally one of the best browsers available at the moment, but Google Chrome also has some amazing tools for developers.

Google chrome’s developer tools can help you play with the code of live websites, and watch the changes happen in real time. They allow you to view the JavaScript console in your browser, track how fast assets download from the server, and much, much more.

Many employers are savvy enough to specifically look for developers who know how to use Google Chrome’s developer tools. In particular, being able to profile an application in order to optimize its performance is a valued skill.

WordPress

While WordPress certainly has its downsides, it’s also an important skill that many employers are looking for in junior web devs. WordPress powers something like 28% of the internet. That means that a large percentage of employers need to hire web developers who can develop and maintain their WordPress-based infrastructure.

Aside from just maintaining previously-built websites, WordPress can also be an ideal solution for companies that want a CMS they can work with and maintain by themselves. You can check out the website of Collectiveray to learn more about WordPress.

3. BACK-END BASICS

While some web developers start out as back-end experts, front-end web development tends to be a more intuitive entry point for many people. But even if you want to get a job as a front-end specialist, you still need to have at least a basic understanding of the concepts of back-end web development. At the very least, you’ll be working with back-end developers, and you’ll need to be able to understand what they’re saying in order to work together effectively. Or, you may be put in positions where you actually need to do some of the back end work yourself!

Servers

Most entry-level web development jobs won’t require you to build your own servers. But you’ll at least need to understand how they work, and how your website interacts with them.

APIs

You’ll need to understand how the front-end of your website can interact with back-end infrastructure, through Application Programming Interfaces (APIs).

SQL & Databases

Many websites and web apps use databases to store information. You’ll need to have a basic understanding of how they work, and how to interact with them.

HTTPS & Cybersecurity

Cybersecurity became a hot topic at the end of 2017 due to high-profile hacks that caused billions of dollars in damages and exposed 145 million Americans to the joys of identity theft. Employers are more concerned about cybersecurity than ever.and this is where the email security saas steps into the scene. If you can display a basic understanding of cybersecurity, you’ve got a leg up on your competition.

4. DIGITAL MARKETING INSIGHT

With ZTNA solution, security of the business is maintained. If there’s one thing that’s more important to employers than security, it’s profits. While digital marketing skills are mainly needed by, well, digital marketers, employers look highly upon web developers who can show at least some insight into the world of digital marketing. A web developer who understands digital marketing can develop websites that get real, tangible results.

Search Engine Optimization (SEO)

One of the primary reasons companies build websites is to bring in new customers. The best way to bring in new customers is to rank highly in search engines for relevant keywords. If your company sells lemur food in Miami, you’ll want to show up on the first page of Google whenever somebody searches “lemur food Miami”. If you’re not on the first page, it’s very unlikely that your target customers will find your website.

Search engine optimization is very important, but it’s a skill that most people don’t have. Companies often resort to hiring specialized SEO teams to optimize their websites. Web developers who have some SEO skills can offer major advantages to companies that hire them. Building a website with SEO in mind is much more efficient than building a poorly optimized website and then hiring a team to fix it.

Conversion-Focused Design

While making pretty-looking, well-functioning websites is nice and dandy, employers tend to care more about their bottom line. Web developers who understand conversion-focused design are much better at building high-converting websites. Higher conversion rates = more profits = better bottom line = happy employers.

5. “SOFT SKILLS”

Many aspiring web developers spend all day staring at computer screens, trying to work out the bugs in their code.The truth is, though, that many would be better off taking some time to work on their interpersonal skills. Visit This Link to know more about computer skills. Employers aren’t looking for anti-social nerds to do their coding. They’re looking for well-rounded employees. Employers want devs who can build their websites, while at the same time fitting into the company culture, handling clients’ concerns, collaborating with other developers, and communicating effectively with non-technical executives and managers.

“Soft skills,” like communication and social skills, aren’t just important for networking, wooing employers, and acing interviews. They’re important on-the-job as well. The better you are at communicating with the people around you, the better you’ll be able to get things done.

Be a Well-Rounded Developer.

Many people getting into web development make the mistake of putting all of their energy into improving one or more of these skill-sets, while neglecting others. We often see people focusing on coding, without developing their soft skills. The truth is, the people who do the best — the ones who actually get high-paying jobs and fulfilling careers — make sure to develop all five of these skill-sets, becoming well-rounded web developers.

You can learn most of these skills on your own, through Google, YouTube, and online courses. Of course, it will take you a really long time to do it that way (if you succeed at all). Here at TechLaunch, we focus on teaching you all five of these skills, at a relaxed pace, over the course of nine months. We can help you become a well-rounded developer, and start a new career in under a year! To explore our course offerings, check out techlaunch.io.

You can use emoji (and other graphical unicode characters) in URLs. And wow is it great. But no one seems to do it. Why? Perhaps emoji are too exotic for normie web platforms to handle? Or maybe they are avoided for fear of angering the SEO gods?

Whatever the reason, the overlapping portion on the Venn diagram of “It’s Possible v.s. No One Is Doing It” is where my excitement usually lies. Graphically animating URLs is a new thing. So I decided to put a little time into the possibilities of graphical characters in URLs. Specifically, with the possibility for animating these characters by way of some Javascript.

Loopin’

First off, make sure your page’s Javascript code is being labelled as UTF-8 or you’re gonna have a bad time putting emoji in your code at all. This can be accomplished via an HTTP header, or page META tag. There’s a good chance you don’t have to worry about this. But you can find more info about this here: Unicode in Javascript by Flavio

To achieve our desired outcome of emoji dancing like sugar plum fairies in our address bar, we need a loop. And really, all we need is a loop. We start the loop, it loops, and we’re happy. So here’s our first loop, a spinning emoji moon. I think when they added this sequence of emoji they must have had this in mind right?

var f = ['?', '?', '?', '?', '?', '?', '?', '?'];

    function loop() {
        location.hash = f[Math.floor((Date.now()/100)%f.length)];

        setTimeout(loop, 50);
    }

    loop();

Run Moon Code:

You can click the toggle checkbox above to see the result of this loop in your URL bar.

If you don’t like the spinning moons you can swap out that array with whatever emojis you want. Like a clock:

var f = ['?','?','?','?','?','?','?','?','?','?','?','?'];

Run Clock Code:

This is a real simple example. Too simple really. So let’s upgrade our loop so that it generates a string of multiple emoji! This time we’re utilizing the emoji “skin tone modifiers” characters to make some color-changing babies:

var e = ['?', '?', '?', '?', '?'];

    function loop() {
        var s = '',
            i, m;

        for (i = 0; i < 10; i ++) {
            m = Math.floor(e.length * ((Math.sin((Date.now()/100) + i)+1)/2));
            s += '?' + e[m];
        }

        location.hash = s;

        setTimeout(loop, 50);
    }

    loop();

Run Babies Code:

We use a sine wave controlled by time and position to select which color we want. This gives us a nice loopy color changing effect!

Or how about we revisit our moon spinner, spread it out, and make something resembling a loading indicator? Sure, let’s do it:

var f = ['?', '?', '?', '?', '?', '?', '?', '?'],
        d = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
        m = 0;

    function loop() {
        var s = '', x = 0;

        if (!m) {
            while (d[x] == 4) {
                x ++;
            }

            if (x >= d.length) m = 1;
            else {
                d[x] ++;
            }
        }
        else {
            while (d[x] == 0) {
                x ++;
            }

            if (x >= d.length) m = 0;
            else {
                d[x] ++;

                if (d[x] == 8) d[x] = 0;
            }
        }

        d.forEach(function (n) {
            s += f[n];
        });

        location.hash = s;

        setTimeout(loop, 50);
    }

    loop();

Run Multi-Moon Code:

Exploring Other Characters

But it’s not just emoji that give us a means to pump graphics out of our URL bar. There’s a whole boatload of unicode characters of interest to our goals.

Particularly interesting are the Box-drawing Characters:

Many of these lend themselves better to a two dimensional output. But they’re still pretty good on the single line we have to play with. For instance we can make a string of multiple height varied block characters and construct a nice little wave:

function loop() {
        var i, n, s = '';

        for (i = 0; i < 10; i++) {
            n = Math.floor(Math.sin((Date.now()/200) + (i/2)) * 4) + 4;

            s += String.fromCharCode(0x2581 + n);
        }

        window.location.hash = s;

        setTimeout(loop, 50);
    }

    loop();

Run Wavy Code:

I liked this look so much I put it up permanently at wavyurl.com.

Using the variable width characters we can even wiggle on the horizontal, creating something like a progress bar:

function loop() {
        var s = '',
            p;

        p = Math.floor(((Math.sin(Date.now()/300)+1)/2) * 100);

        while (p >= 8) {
            s += '█';
            p -= 8;
        }
        s += ['⠀','▏','▎','▍','▌','▋','▊','▉'][p];

        location.hash = s;
        setTimeout(loop, 50);
    }

Run Progress Bar Code:

A progress bar huh? That’s like, almost useful. Which brings me to…

Displaying Video Progress In The URL Bar

In an attempt to reduce the frivolity in our little experiment, I came up with the idea to show a web video’s progress in the URL. I simply attach a function that renders our progress string to the “timeupdate” event for a video, and voila! A video progress indicator in the URL, complete with the time and duration!

var video;

    function formatTime(seconds) {
        var minutes = Math.floor(seconds/60),
            seconds = Math.floor(seconds - (minutes*60));

        return ('0'+minutes).substr(-2) + ':' + ('0'+seconds).substr(-2);
    }

    function renderProgressBar() {
        var s = '',
            l = 15,
            p = Math.floor(video.currentTime / video.duration * (l-1)),
            i;

        for (i = 0; i < l; i ++) {
            if (i == p) s +='◯';
            else if (i < p) s += '─';
            else s += '┄';
        }

        location.hash = '╭'+s+'╮'+formatTime(video.currentTime)+'╱'+formatTime(video.duration);
    }

    video = document.getElementById('video');
    video.addEventListener('timeupdate', renderProgressBar);

Run Video Progress Bar Code:

With the above checkbox checked, you can use the video below to try it out.

I rather like this lines and circle progress bar, but if you fancy some moon emoji, I’ve got you covered:

var e = ['?', '?', '?', '?', '?'],
        video;

    function formatTime(seconds) {
        var minutes = Math.floor(seconds/60),
            seconds = Math.floor(seconds - (minutes*60));

        return ('0'+minutes).substr(-2) + ':' + ('0'+seconds).substr(-2);
    }

    function renderProgressBar() {
        var s = '',
            c = 0,
            l = 10,
            p = Math.floor(video.currentTime / video.duration * ((l*5)-1)),
            i;

        while (p >= 5) {
            s += e[4];
            c ++;
            p -= 5;
        }
        s += e[p];
        c ++;

        while (c < l) {
            s += e[0];
            c ++;
        }

        location.hash = s+formatTime(video.currentTime)+'╱'+formatTime(video.duration);
    }

    video = document.getElementById('video');
    video.addEventListener('timeupdate', renderProgressBar);

Run Video Moons Progress Bar Code:

Okay, calling this progress bar “useful” is a stretch. But if I squint, I can almost see a scenario where it would be useful to have this in a video sharing URL. Like YouTube has the option of creating a link to a video at a specific time. Might it not be cool to include a visual indication? Hmmm?

Maybe there is some more useful implementation of this “technology” that I haven’t come up with. I’ll keep thinking on that. And hey, maybe you can come up with something?

One Last Thing

You may be wondering why I used “location.hash =” instead of the newer and shinier HTML5 History API. Two reasons. One solvable. The other less so. Both inconvenient.

Issue 1 is also a feature of the History API: It actually changes the whole URL path, not just the hash. So if I use the History API and change our page to “/?????”, it’ll look nicer than having tacked on a #. But it also means my web server must be able to response to “/?????”, or the user will be out of luck if they refresh, or otherwise navigate to the modified URL. This is doable, but trickier than using “location.hash =” which doesn’t require me to prepare the server in any special way.

Issue 2 is more unexpected. Turns out that in 2 out of 3 browsers I tested, the History API is throttled. If I push my wavy URL characters to the address bar at a fast rate I’ll eventually get the following error in Chrome:

Throttling history state changes to prevent the browser from hanging.

Safari is nice enough to give us a bit more info:

SecurityError: Attempt to use history.pushState() more than 100 times per 30.000000 seconds

Now if I stay under that limit I’m fine. But c’mon, 3 frames a second just doesn’t cut it for the ooey gooey URL animations I desire.

Good boy Firefox on the other hand doesn’t seem to give a hoot how many times I push a new history or how quickly. Which is gosh darn thoughtful of it. But breaking in two major browsers, plus neccesitating the web server configuration to fix Issue 1, makes me willing to put up with a little # in the URL.

The End ?

I’ll leave it there. But I will tell ya that I’ve got a few ideas for making tiny games that display in the URL bar. Especially given the Braille Characters that we have yet to explore. So stay tuned for that.

If you have questions, comments, or simply want to keep up with my latest tinkerings, check me out on Twitter: @MatthewRayfield. Or subscribe to my almost-never-bothered email list here.

Oh and if you want the source for these URL mutilating abominations wrapped up in nice little ready-to-run HTML files, here you go ;]

Bye for now!

Background

Ever since the first animated DHTML cursor trails and “Site of the Week” badges graced the web, re-usable code has been a temptation for web developers. And ever since those heady days, integrating third-party UI into your site has been, well, a semi-brittle headache.

Using other people’s clever code has required buckets of boilerplate JavaScript or CSS conflicts involving the dreaded !important. Things are a bit better in the world of React and other modern frameworks, but it’s a bit of a tall order to require the overhead of a full framework just to re-use a widget. HTML5 introduced a few new elements like <video> and <input type="date">, which added some much-needed common UI widgets to the web platform. But adding new standard elements for every sufficiently common web UI pattern isn’t a sustainable option.

In response, a handful of web standards were drafted. Each standard has some independent utility, but when used together, they enable something that was previously impossible to do natively, and tremendously difficult to fake: the capability to create user-defined HTML elements that can go in all the same places as traditional HTML. These elements can even hide their inner complexity from the site where they are used, much like a rich form control or video player.

The standards evolve

As a group, the standards are known as Web Components. In the year 2018 it’s easy to think of Web Components as old news. Indeed, early versions of the standards have been around in one form or another in Chrome since 2014, and polyfills have been clumsily filling the gaps in other browsers.

After some quality time in the standards committees, the Web Components standards were refined from their early form, now called version 0, to a more mature version 1 that is seeing implementation across all the major browsers. Firefox 63 added support for two of the tent pole standards, Custom Elements and Shadow DOM, so I figured it’s time to take a closer look at how you can play HTML inventor!

Given that Web Components have been around for a while, there are lots of other resources available. This article is meant as a primer, introducing a range of new capabilities and resources. If you’d like to go deeper (and you definitely should), you’d do well to read more about Web Components on MDN Web Docs and the Google Developers site.

Defining your own working HTML elements requires new powers the browser didn’t previously give developers. I’ll be calling out these previously-impossible bits in each section, as well as what other newer web technologies they draw upon.

The <template> element: a refresher

This first element isn’t quite as new as the others, as the need it addresses predates the Web Components effort. Sometimes you just need to store some HTML. Maybe it’s some markup you’ll need to duplicate multiple times, maybe it’s some UI you don’t need to create quite yet. The <template> element takes HTML and parses it without adding the parsed DOM to the current document.

<template>
  <h1>This won't display!</h1>
  <script>alert("this won't alert!");</script>
</template>

Where does that parsed HTML go, if not to the document? It’s added to a “document fragment”, which is best understood as a thin wrapper that contains a portion of an HTML document. Document fragments dissolve when appended to other DOM, so they’re useful for holding a bunch of elements you want later, in a container you don’t need to keep.

“Well okay, now I have some DOM in a dissolving container, how do I use it when I need it?”

You could simply insert the template’s document fragment into the current document:

let template = document.querySelector('template');
document.body.appendChild(template.content);

This works just fine, except you just dissolved the document fragment! If you run the above code twice you’ll get an error, as the second time template.content is gone. Instead, we want to make a copy of the fragment prior to inserting it:

document.body.appendChild(template.content.cloneNode(true));

The cloneNode method does what it sounds like, and it takes an argument specifying whether to copy just the node itself or include all its children.

The template tag is ideal for any situation where you need to repeat an HTML structure. It particularly comes in handy when defining the inner structure of a component, and thus <template> is inducted into the Web Components club.

New Powers:

• An element that holds HTML but doesn’t add it to the current document.

Review Topics:

• Document Fragments
• Duplicating DOM nodes using cloneNode

Custom Elements

Custom Elements is the poster child for the Web Components standards. It does what it says on the tin – allowing developers to define their own custom HTML elements. Making this possible and pleasant builds fairly heavily on top of ES6’s class syntax, where the v0 syntax was much more cumbersome. If you’re familiar with classes in JavaScript or other languages, you can define classes that inherit from or “extend” other classes:

class MyClass extends BaseClass {
// class definition goes here
}

Well, what if we were to try this?

class MyElement extends HTMLElement {}

Until recently that would have been an error. Browsers didn’t allow the built-in HTMLElement class or its subclasses to be extended. Custom Elements unlocks this restriction.

The browser knows that a <p> tag maps to the HTMLParagraphElement class, but how does it know what tag to map to a custom element class? In addition to extending built-in classes, there’s now a “Custom Element Registry” for declaring this mapping:

customElements.define('my-element', MyElement);

Now every <my-element> on the page is associated with a new instance of MyElement. The constructor for MyElement will be run whenever the browser parses a <my-element> tag.

What’s with that dash in the tag name? Well, the standards bodies want the freedom to create new HTML tags in the future, and that means that developers can’t just go creating an <h7> or <vr> tag. To avoid future conflicts, all custom elements must contain a dash, and standards bodies promise to never make a new HTML tag containing a dash. Collision avoided!

In addition to having your constructor called whenever your custom element is created, there are a number of additional “lifecycle” methods that are called on a custom element at various moments:

• connectedCallback is called when an element is appended to a document. This can happen more than once, e.g. if the element is moved or removed and re-added.
• disconnectedCallback is the counterpart to connectedCallback.
• attributeChangeCallback fires when attributes from a whitelist are modified on the element.

A slightly richer example looks like this:

class GreetingElement extends HTMLElement {
  constructor() {
    super();
    this._name = 'Stranger';
  }
  connectedCallback() {
    this.addEventListener('click', e => alert(`Hello, ${this._name}!`));
  }
  attributeChangedCallback(attrName, oldValue, newValue) {
    if (attrName === 'name') {
      if (newValue) {
        this._name = newValue;
      } else {
        this._name = 'Stranger';
      }
    }
  }
}
GreetingElement.observedAttributes = ['name'];
customElements.define('hey-there', GreetingElement);

Using this on a page will look like the following:

<hey-there>Greeting</hey-there>
<hey-there name="Potch">Personalized Greeting</hey-there>

But what if you want to extend an existing HTML element? You definitely can and should, but using them within markup looks fairly different. Let’s say we want our greeting to be a button:

class GreetingElement extends HTMLButtonElement

We’ll also need to tell the registry we’re extending an existing tag:

customElements.define('hey-there', GreetingElement, { extends: 'button' });

Because we’re extending an existing tag, we actually use the existing tag instead of our custom tag name. We use the new special is attribute to tell the browser what kind of button we’re using:

<button is="hey-there" name="World">Howdy</button>

It may seem a bit clunky at first, but assistive technologies and other scripts wouldn’t know our custom element is a kind of button without this special markup.

From here, all the classic web widget techniques apply. We can set up a bunch of event handlers, add custom styling, and even stamp out an inner structure using <template>. People can use your custom element alongside their own code, via HTML templating, DOM calls, or even new-fangled frameworks, several of which support custom tag names in their virtual DOM implementations. Because the interface is the standard DOM interface, Custom Elements allows for truly portable widgets.

New Powers

• The ability to extend the built-in ‘HTMLElement’ class and its subclasses
• A custom element registry, available via customElements.define()
• Special lifecycle callbacks for detecting element creation, insertion to the DOM, attribute changes, and more.

Review Topics

• ES6 Classes, particularly subclassing and the extends keyword

Shadow DOM

We’ve made our friendly custom element, we’ve even thrown on some snazzy styling. We want to use it on all our sites, and share the code with others so they can use it on theirs. How do we prevent the nightmare of conflicts when our customized <button> element runs face-first into the CSS of other sites? Shadow DOM provides a solution.

The Shadow DOM standard introduces the concept of a shadow root. Superficially, a shadow root has standard DOM methods, and can be appended to as if it was any other DOM node. Shadow roots shine in that their contents don’t appear to the document that contains their parent node:

// attachShadow creates a shadow root.
let shadow = div.attachShadow({ mode: 'open' });
let inner = document.createElement('b');
inner.appendChild(document.createTextNode('Hiding in the shadows'));
// shadow root supports the normal appendChild method.
shadow.appendChild(inner);
div.querySelector('b'); // empty

In the above example, the <div> “contains” the <b> and the <b> is rendered to the page, but the traditional DOM methods can’t see it. Not only that, but the styles of the containing page can’t see it either. This means that styles outside of a shadow root can’t get in, and styles inside the shadow root don’t leak out. This boundary is not meant to be a security feature, as another script on the page could detect the shadow root’s creation, and if you have a reference to a shadow root, you can query it directly for its contents.

The contents of a shadow root are styled by adding a <style> (or <link>) to the root:

let style = document.createElement('style');
style.innerText = 'b { font-weight: bolder; color: red; }';
shadowRoot.appendChild(style);
let inner = document.createElement('b');
inner.innerHTML = "I'm bolder in the shadows";
shadowRoot.appendChild(inner);

Whew, we could really use a <template> right about now! Either way, the <b> will be affected by the stylesheet in the root, but any outer styles matching a <b> tag will not.

What if a custom element has non-shadow content? We can make them play nicely together using a new special element called <slot>:

<template>
  Hello, <slot></slot>!
</template>

If that template is attached to a shadow root, then the following markup:

<hey-there>World</hey-there>

Will render as:

Hello, World!

This ability to composite shadow roots with non-shadow content allows you to make rich custom elements with complex inner structures that look simple to the outer environment. Slots are more powerful than I’ve shown here, with multiple slots and named slots and special CSS pseudo-classes to target slotted content. You’ll have to read more!

New Powers:

• A quasi-obscured DOM structure called a “shadow root”
• DOM APIs for creating and accessing shadow roots
• Scoped styles within shadow roots
• New CSS pseudo-classes for working with shadow roots and scoped styles
• The <slot> element

Putting it all together

Let’s make a fancy button! We’ll be creative and call the element <fancy-button>. What makes it fancy? It will have a custom style, and it will also allow us to supply an icon and make that look snazzy as well. We’d like our button’s styles to stay fancy no matter what site you use them on, so we’re going to encapsulate the styles in a shadow root.

You can see the completed custom element in the interactive example below. Be sure to take a look at both the JS definition of the custom element and the HTML <template> for the style and structure of the element.

Concluion

The standards that make up Web Components are built on the philosophy that by providing multiple low-level capabilities, people will combine them in ways that nobody expected at the time the specs were written. Custom Elements have already been used to make it easier to build VR content on the web, spawned multiple UI toolkits, and much more. Despite the long standardization process, the emerging promise of Web Components puts more power in the hand of creators. Now that the technology is available in browsers, the future of Web Components is in your hands. What will you build?