Download the Full Ebook and Access More Features - ebooknice.

com

(Ebook) Fullstack Web Components: Complete Guide

to Building UI Libraries with Web Components by
Steve Belovarich; (edited by) Nate Murray ISBN
B0BGYPWQVR
https://ebooknice.com/product/fullstack-web-components-
complete-guide-to-building-ui-libraries-with-web-
components-46387690

OR CLICK HERE

DOWLOAD EBOOK

Download more ebook instantly today at https://ebooknice.com

 Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Start reading on any device today!

(Ebook) Fullstack Web Components: Complete Guide to

Building UI Libraries with Web Components by Steve
Belovarich; (edited by) Nate Murray ISBN B0BGYPWQVR
https://ebooknice.com/product/fullstack-web-components-complete-guide-
to-building-ui-libraries-with-web-components-46387706

ebooknice.com

(Ebook) Fullstack Web Components: Complete Guide to

Building UI Libraries with Web Components by Steve
Belovarich; (edited by) Nate Murray ISBN B0BGYPWQVR
https://ebooknice.com/product/fullstack-web-components-complete-guide-
to-building-ui-libraries-with-web-components-46387712

ebooknice.com

(Ebook) Developing Web Components with Svelte: Building a

Library of Reusable UI Components by Alex Libby ISBN
9781484290385, 1484290380
https://ebooknice.com/product/developing-web-components-with-svelte-
building-a-library-of-reusable-ui-components-47898820

ebooknice.com

(Ebook) Developing Web Components with Svelte: Building a

Library of Reusable UI Components by Alex Libby ISBN
9781484290392, 1484290399
https://ebooknice.com/product/developing-web-components-with-svelte-
building-a-library-of-reusable-ui-components-54929064

ebooknice.com
(Ebook) Fullstack Node.js: The Complete Guide to Building
Production Apps with Node.js by Davit Guttman; Nate Murray
(ed) ISBN 08671X
https://ebooknice.com/product/fullstack-node-js-the-complete-guide-to-
building-production-apps-with-node-js-11798290

ebooknice.com

(Ebook) Developing Web Components with TypeScript: Native

Web Development Using Thin Libraries by Jorg Krause
[Krause, Jörg] ISBN 9781484268391, 1484268393
https://ebooknice.com/product/developing-web-components-with-
typescript-native-web-development-using-thin-libraries-23948638

ebooknice.com

(Ebook) Developing Web Components: UI from jQuery to

Polymer by Jarrod Overson, Jason Strimpel ISBN
9781491949023, 1491949023
https://ebooknice.com/product/developing-web-components-ui-from-
jquery-to-polymer-5035788

ebooknice.com

(Ebook) Developing Web Components with TypeScript: Native

Web Development Using Thin Libraries by Jorg Krause
[Krause, Jörg] ISBN 9781484268391, 9781484268407,
1484268393, 1484268407
https://ebooknice.com/product/developing-web-components-with-
typescript-native-web-development-using-thin-libraries-24047404

ebooknice.com

(Ebook) Fullstack GraphQL: The Complete Guide to Writing

GraphQL Servers and Clients with TypeScript by Gaetano
Checinskil; Roy Derks; (ed) Nate Murray
https://ebooknice.com/product/fullstack-graphql-the-complete-guide-to-
writing-graphql-servers-and-clients-with-typescript-23430186

ebooknice.com
 Fullstack Web Components
The Complete Guide to Building UI Libraries and Web Applications with
Web Components

Wri en by Steve Belovarich

Edited by Nate Murray

© 2020 Fullstack.io

All rights reserved. No portion of the book manuscript may be

reproduced, stored in a retrieval system, or transmi ed in any form or by
any means beyond the number of purchased copies, except for a single
backup or archival copy. e code may be used freely in your projects,
commercial or otherwise.

e authors and publisher have taken care in preparation of this book,

but make no expressed or implied warranty of any kind and assume no
responsibility for errors or omissions. No liability is assumed for
incidental or consequential damagers in connection with or arising out
of the use of the information or programs container herein.

Published by \newline
Th
tt
Th
tt
Contents

Book Revision . . . . . . . . . . . . . . . . . . . . . . . . . 1
Join Our Discord . . . . . . . . . . . . . . . . . . . . . . . 1
Bug Reports . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Be notified of updates via Twitter . . . . . . . . . . . . . 1
We’d love to hear from you! . . . . . . . . . . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
About the author . . . . . . . . . . . . . . . . . . . . . . . 3
Web Components . . . . . . . . . . . . . . . . . . . . . . . 4
About this book . . . . . . . . . . . . . . . . . . . . . . . . 5
Who is this book for . . . . . . . . . . . . . . . . . . . . . 5
Introduction to Web Components . . . . . . . . . . . . . 6
What are Web Components? . . . . . . . . . . . . . . . . 11
The many uses of Web Components . . . . . . . . . . . . 17
Implementing a design system with Web Components . 19
Conventions used in this Book . . . . . . . . . . . . . . . 20
Storybook . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Application . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Cypress . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Storyshots . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Monorepo . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Setting up the development environment . . . . . . . . . 25
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CONTENTS

Part One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Part One . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Specification . . . . . . . . . . . . . . . . . . . . . . . . . 32
What you will learn . . . . . . . . . . . . . . . . . . . . . 33
Developing in Part One . . . . . . . . . . . . . . . . . . . 34

Getting to Know Web Components . . . . . . . . . . . . . . 35

Chapter One . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 35
What you will build . . . . . . . . . . . . . . . . . . . . . 35
What you will learn . . . . . . . . . . . . . . . . . . . . . 38
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 38
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 39
Scaffolding CardComponent . . . . . . . . . . . . . . . . 39
Structure content with template slots . . . . . . . . . . . 45
Create controls for the story . . . . . . . . . . . . . . . . 49
Styling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Testing the card . . . . . . . . . . . . . . . . . . . . . . . . 60
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Form-associated custom elements . . . . . . . . . . . . . . 74

Chapter Two . . . . . . . . . . . . . . . . . . . . . . . . . 74
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 74
What you will build . . . . . . . . . . . . . . . . . . . . . 76
What you will learn . . . . . . . . . . . . . . . . . . . . . 79
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 79
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 80
Scaffolding TextInputComponent . . . . . . . . . . . . . 80
Structure the content . . . . . . . . . . . . . . . . . . . . . 82
Define the story . . . . . . . . . . . . . . . . . . . . . . . . 84
Form Associated and ElementInternals . . . . . . . . . . 86
Handling Validation . . . . . . . . . . . . . . . . . . . . . 89
Listening for attribute changes . . . . . . . . . . . . . . . 98
User feedback . . . . . . . . . . . . . . . . . . . . . . . . . 112
Handling Disabled State . . . . . . . . . . . . . . . . . . . 115
CONTENTS

Make stories . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Styling with CSS variables . . . . . . . . . . . . . . . . . 119
Emulating HTMLInputElement . . . . . . . . . . . . . . . 123
Making a form . . . . . . . . . . . . . . . . . . . . . . . . 129
Handling FormData . . . . . . . . . . . . . . . . . . . . . 137
Testing TextInputComponent . . . . . . . . . . . . . . . . 139
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Customized built-in elements . . . . . . . . . . . . . . . . . 146

Chapter Three . . . . . . . . . . . . . . . . . . . . . . . . . 146
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 146
What you will build . . . . . . . . . . . . . . . . . . . . . 149
What you will learn . . . . . . . . . . . . . . . . . . . . . 150
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 151
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 151
Scaffolding ButtonComponent . . . . . . . . . . . . . . . 151
Styling ButtonComponent . . . . . . . . . . . . . . . . . . 155
Making the form accessible . . . . . . . . . . . . . . . . . 167
Testing ButtonComponent . . . . . . . . . . . . . . . . . 179
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Part Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Part Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
UI Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
What you will learn . . . . . . . . . . . . . . . . . . . . . 184
Developing in Part Two . . . . . . . . . . . . . . . . . . . 184

Micro-library . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Chapter Four . . . . . . . . . . . . . . . . . . . . . . . . . 186
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 186
What is a micro-library? . . . . . . . . . . . . . . . . . . . 190
Coding in a monorepo . . . . . . . . . . . . . . . . . . . . 190
What you will build . . . . . . . . . . . . . . . . . . . . . 192
What you will learn . . . . . . . . . . . . . . . . . . . . . 192
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 192
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 193
CONTENTS

Class Decorator . . . . . . . . . . . . . . . . . . . . . . . . 193

Method Decorator . . . . . . . . . . . . . . . . . . . . . . 227
Define the Listen decorator . . . . . . . . . . . . . . . . . 231
Refactor TextInputComponent . . . . . . . . . . . . . . . 238
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Compound Custom Elements . . . . . . . . . . . . . . . . . 243

Chapter Five . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Component Communication . . . . . . . . . . . . . . . . 243
What you will build . . . . . . . . . . . . . . . . . . . . . 247
What you will learn . . . . . . . . . . . . . . . . . . . . . 247
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 247
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 248
Mocking Table Data in Storybook . . . . . . . . . . . . . 248
Coding Compound Components . . . . . . . . . . . . . . 260
Attribute Drilling . . . . . . . . . . . . . . . . . . . . . . . 260
BroadcastChannel . . . . . . . . . . . . . . . . . . . . . . 264
Rendering Columns and Rows . . . . . . . . . . . . . . . 266
Styling TableComponent . . . . . . . . . . . . . . . . . . 272
Handling CRUD Events with BroadcastChannel . . . . . 275
Making the Table Editable . . . . . . . . . . . . . . . . . . 280
Testing the Table . . . . . . . . . . . . . . . . . . . . . . . 313
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Powering Dialogs with HTML Templates . . . . . . . . . . 324

Chapter Six . . . . . . . . . . . . . . . . . . . . . . . . . . 324
HTML Templates . . . . . . . . . . . . . . . . . . . . . . . 324
What you will build . . . . . . . . . . . . . . . . . . . . . 328
What you will learn . . . . . . . . . . . . . . . . . . . . . 328
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 328
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 329
Mocking the Dialog in Storybook . . . . . . . . . . . . . 329
DialogComponent . . . . . . . . . . . . . . . . . . . . . . 337
Modal and Tooltip . . . . . . . . . . . . . . . . . . . . . . 343
Querying DOM Across Shadow Boundaries . . . . . . . 350
CONTENTS

DialogStack . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Testing Dialogs . . . . . . . . . . . . . . . . . . . . . . . . 372
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Distributing Custom Element Libraries . . . . . . . . . . . 380

Chapter Seven . . . . . . . . . . . . . . . . . . . . . . . . . 380
UI Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 380
What you will build . . . . . . . . . . . . . . . . . . . . . 384
What you will learn . . . . . . . . . . . . . . . . . . . . . 384
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 385
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 385
Distributing Custom Element UI Libraries . . . . . . . . 386
Providing Documentation with Custom Elements Mani-
fest and Storybook . . . . . . . . . . . . . . . . . . 398
Set up Continuous Integration with Github Actions . . . 412
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Part Three . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Part Three . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Application . . . . . . . . . . . . . . . . . . . . . . . . . . 425
What you will learn . . . . . . . . . . . . . . . . . . . . . 425
Developing in Part Three . . . . . . . . . . . . . . . . . . 426

Application Development with Custom Elements . . . . . 428

Chapter Eight . . . . . . . . . . . . . . . . . . . . . . . . . 428
Application Development with Custom Elements . . . . 428
What you will build . . . . . . . . . . . . . . . . . . . . . 430
What you will learn . . . . . . . . . . . . . . . . . . . . . 431
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 431
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 432
Landing Page . . . . . . . . . . . . . . . . . . . . . . . . . 432
App Header . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Cookie Footer . . . . . . . . . . . . . . . . . . . . . . . . . 447
Landing Page Content . . . . . . . . . . . . . . . . . . . . 460
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
CONTENTS

Routing Custom Elements in a SPA . . . . . . . . . . . . . . 469

Chapter Nine . . . . . . . . . . . . . . . . . . . . . . . . . 469
Routing Custom Elements in a SPA . . . . . . . . . . . . 469
What you will build . . . . . . . . . . . . . . . . . . . . . 472
What you will learn . . . . . . . . . . . . . . . . . . . . . 472
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 472
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 472
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Login View . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Dashboard View . . . . . . . . . . . . . . . . . . . . . . . 498
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

Server-side Rendering with Declarative Shadow DOM . . 508

Chapter Ten . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Server-Side Rendering Custom Elements . . . . . . . . . 508
What you will build . . . . . . . . . . . . . . . . . . . . . 516
What you will learn . . . . . . . . . . . . . . . . . . . . . 517
Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . 517
Getting started . . . . . . . . . . . . . . . . . . . . . . . . 517
Declarative Shadow DOM Templates . . . . . . . . . . . 517
Shim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Ponyfill . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Express Middleware . . . . . . . . . . . . . . . . . . . . . 537
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Fullstack Web Components . . . . . . . . . . . . . . . . . . 553

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Specification . . . . . . . . . . . . . . . . . . . . . . . . . 554
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
The future is bright . . . . . . . . . . . . . . . . . . . . . . 558

Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Revision 1 (04-04-2022) . . . . . . . . . . . . . . . . . . . . 560
Revision 2 (12-06-2022) . . . . . . . . . . . . . . . . . . . . 560
CONTENTS 1

Book Revision
Revision 1 - Initial pre-release of the book - 04-04-2022
Revision 2 - Change book cover - 12-06-2022

Join Our Discord

Come chat with other readers of the book in the official newline
Discord channel:
Join here: https://newline.co/discord/webcomponents¹

Bug Reports
If you’d like to report any bugs, typos, or suggestions just email us
at: [email protected].

Be notified of updates via Twitter

If you’d like to be notified of updates to the book on Twitter, follow
us at @fullstackio².

We’d love to hear from you!

Did you like the book? Did you find it helpful? We’d love to add
your face to our list of testimonials on the website! Email us at:
[email protected]³.
¹https://newline.co/discord/webcomponents
²https://twitter.com/fullstackio
³mailto:[email protected]
 Introduction
Acknowledgements
For my wife Susanne.

Foreword
This is a book about Web Components. UI components are a
common pattern in many front end web development frameworks
like Angular, React or Vue, but coding user interfaces in the context
of a framework usually makes sharing those components difficult.
Angular components can’t be easily loaded in the context of React,
for instance. The framework is a closed system.
If you can move past the framework, and possibly enjoy the
simplification and standardization offered by web specifications,
coding with Web Components can be quite rewarding. Working
directly with specifications opens up a world once obscured by
the framework. The web platform is yours to explore and find
interesting ways to utilize parts of HTML, CSS, and JavaScript. By
using web specifications to code UI components you can achieve
extraordinary results. When used responsibly, adopting Web Com-
ponents as your UI component pattern can lead to stellar perfor-
mance, compliance with accessibility standards, and reusability.
At enterprise corporations it can be rather costly to support several
development teams. One way to reduce operational overhead is
to standardize UI components and reuse them across a software
product. This cuts down on teams “reinventing the wheel”. I’ve
witnessed teams struggle with user interface development at sev-
eral companies. It can be quite difficult to coordinate the use
Introduction 3

of a UI library, particularly when it’s coded with a JavaScript

framework. User interfaces built with the Web Components are in-
teroperable with any JavaScript framework. Dependencies become
hard to maintain over a distributed software ecosystem, teams
have conflicting priorities making it difficult to not just upgrade
components, but also framework dependencies. When companies
adopt Web Components as the solution for a UI component library,
it can reduce the churn associated with framework dependencies.
I wrote this guide for developing user interfaces using only web
specifications because I believe it’s in the best interests of soft-
ware engineers at enterprise corporations to code in a way that
allows user interfaces to be used over a long lifespan. Corporations
shouldn’t have the reinvest in user interfaces at the rate JavaScript
frameworks go in and out of fashion.
It’s one thing to help by providing examples or peer programming,
but I didn’t think that was enough. While coding a micro-library for
developing Web Components, I found it difficult to find resources.
This book is designed to take on a journey with Web Components
as if you were developing a UI library at an enterprise corporation.
You won’t just get hands-on experience coding UI with Web Com-
ponents, but also learn how to test and maintain those components
in the context of a distributed UI library. This book will make you
proficient enough to develop a UI library, web application or some
other fantastical flights of fancy with Web Components.

About the author

Stephen Belovarich is a web engineer who started tinkering with
web development in the 90s. After developing his first website,
Stephen became enamored with the extraordinary potential of the
web. For several years after attending college at Rensselaer Poly-
technic Institute, he coded e-commerce solutions and marketing
portals for freelance clients while creating net art for display in
Introduction 4

fine art galleries. Specializing in user interface library and web

application architecture, Stephen has developed interactive user ex-
periences for Lexus, Ubiquiti Networks, NBC Universal, Nike, and
Symantec. Stephen Belovarich is a Principal Software Development
Engineer at Workday. Stephen is passionate about teaching the next
generation of web engineers how to navigate the ever-expanding
web platform. He taught computer science and engineering at
General Assembly and Syracuse University, has presented at ng-
conf, ACT-W, and meetups around Portland, Oregon where he
currently resides.

Web Components
Before the set of technologies known as Web Components were
available engineers had to select an opinionated JavaScript frame-
work to abstract user interfaces into “components”. Web Com-
ponents are interoperable with virtually any JavaScript library
or framework because they are developed using only browser
specifications. The lifespan of a user interface component built with
Web Components can be much greater than a component built with
a library since browser specifications exist for a very long time.
Web Components can have dynamic templates, handle complex
form behaviors, even inherit characteristics of familiar HTML
elements like <button> or <table>. By coding a UI library with
Web Components, you can ensure the components have a farther
reach than components only compatible with a specific library
or framework. Depending on implementation, components coded
with Web Components specifications can out perform framework-
based components as well, due to the lack of dependencies and
overhead inherit in JavaScript frameworks.
Introduction 5

About this book

In this book, we’re going to learn how to develop a user interface
library and web application with Web Components. We’ll start by
coding UI components using the set of specifications that comprise
Web Components, increasing in complexity while covering real
world problems: forms, custom templates, editable tables, and
dialogs. In a lerna⁴ monorepo, we’ll code almost exclusively with
Storybook⁵ as our development environment and write tests for
each component using Cypress. After configuring the UI library
for distribution, we’ll import the components into a fullstack web
application built entirely with Web Components. In each chapter,
you’ll find step-by-step instructions for coding each component
and developing a web application with Web Components. By the
end of this book, you’ll have developed a user interface library
from a design system in Figma⁶ and used those components in the
context of a web application.

Who is this book for

This book is for anyone who wants to learn how to architect and
develop a user interface library with Web Components. By learning
how to architect reusable components, you’ll be able to make
better decisions when developing user interfaces in the future. Web
Components are a fundamental building block of front end web
development. Anyone with some prior knowledge of JavaScript,
HTML, and CSS should be able to make sense of this book.
In the next section we’re going to provide an in-depth introduction
to Web Components and how they are used in the real world. This
will get much of the theory and vocabulary out of the way and allow
⁴https://lerna.js.org
⁵https://storybook.js.org
⁶https://www.figma.com
Introduction 6

us to buckle down and develop Web Components in the chapters

that follow.

Introduction to Web Components

In the nineties web development was egalitarian. HTML provided
a syntax anyone could learn. A <p> element displays a paragraph.
An <img> element displays an image, provided a src attribute has
a valid address for an image file. The HTML standard evolved over
time, however the elements used in development in the nineties still
work today.
What it takes to develop a website has dramatically changed
over the years. Web development became even more sophisticated
when corporations discovered an advantage web had over native:
anyone can access software in a web browser and updates can be
pushed server-side, without the need for the end-user to trigger a
software update. JavaScript frameworks like React, Angular, and
Vue filled in the gaps of the ECMAScript standard, giving web
engineers sophisticated tools and patterns for coding feature-rich
web applications. React, in particular, popularized the notion of
classes with React.createClass before ECMAScript delivered the
standards-based class with the ES2015 standard, otherwise known
as ES6. While JavaScript frameworks created fragmentation with
incompatible component models, JavaScript frameworks have one
thing in common. React, Angular, and Vue all feature a discrete
unit of functionality that encapsulates template, styling, and user
interface behaviors called the “component”.
Framework-based UI components solved a distinct problem in
web development by providing a component model, but the web
platform lagged behind. There was no way to create a custom
HTML element. Web developers could only use the HTML elements
provided by the HTML standard, and extending the prototype of
a native HTML element was considered a bad practice. In web
Introduction 7

application templates, each of the frameworks allow framework

components to be declared alongside HTML elements, although
components from two different frameworks don’t necessarily work
together in the same template. The opinionated implementation of
one framework component clashes with another. Rendering mul-
tiple framework components in a single architecture can become
extremely brittle. It’s amazing how much JavaScript frameworks
provide out of-the-box, but they don’t really play nice together.
The fragmentation caused by JavaScript frameworks pose a prob-
lem at scale in corporations. Maintaining a consistent look and feel
across a portfolio of many web applications is seemingly impossible
when several engineering teams develop with different JavaScript
frameworks. The same UI component could be duplicated many
times over as the component is developed specifically for each
framework. Pushing out changes to design and UX behavior be-
comes a herculean task, dealing the dependency chain of each
JavaScript framework along the way.
Supporting accessible behaviors in framework-based UI compo-
nents is challenging because when developing custom UI you es-
sentially have to reinvent the wheel. Engineers may create a button
component with a framework, but mistakingly use the template
of a <div>, losing the accessibility behaviors of <button> in the
process. The engineer would have to implement event listeners on
keydown to listen for the spacebar and return keys being pressed,
adding to the complexity of the codebase they maintain. Custom
elements can extend from native HTML elements, retaining the
accessibility behaviors of the element they extend from. This isn’t
to say Web Components aren’t without challenges when it comes to
accessibility. Shadow DOM can block screen readers from analyz-
ing WAI-ARIA attributes when ids are deeply nested across Shadow
boundaries, so developer intervention maybe needed to coax screen
readers to obtain the desired results for accessibility.
Other problems with framework-based UI component development
occur over time. Breaking changes in major versions of frameworks
 Introduction 8

can cause churn. As frameworks optimize over time, breaking

changes to syntax or different ways of working force engineers
to relearn how UI components are developed. Rarely nowadays
would you see React.createClass in a modern React application,
instead engineers would use the class-based React.Component or
a functional implementation with React hooks. A standards-based
Web Component has a longer lifespan than framework components.
Like those HTML elements <p> and <img>, Web Components are
part of the HTML specification. A custom element registered with
the CustomElementRegistry will work in browsers for several years
to come.

1 export class CardComponent extends HTMLElement {

2 constructor() {
3 super();
4 const shadowRoot = this.attachShadow({ mode: 'open' }\
5 );
6 const template = document.createElement('template');
7 template.innerHTML = `
8 <style>
9 :host {
10 display: block;
11 background: white;
12 border-radius: 12px;
13 border: 4px solid black;
14 overflow: hidden;
15 max-width: 320px;
16 min-height: 120px;
17 }
18 </style>
19 <header>
20 <slot name="header"></slot>
21 </header>
22 <section>
23 <slot name="body"></slot>
 Introduction 9

24 </section>
25 <footer>
26 <slot name="footer"></slot>
27 </footer>
28 `;
29 shadowRoot.appendChild(template.content.cloneNode(tru\
30 e));
31 }
32 }
33 customElements.define('in-card', CardComponent);

Web Components are interoperable, meaning custom elements can

be used in the context JavaScript frameworks like any other HTML
element.

1 export {CardComponent} from "./custom-element";

2
3 export const App = () => {
4 return (
5 <div>
6 <in-card></in-card>
7 </div>
8 )
9 }
10
11 ReactDOM.render(<App />, document.querySelector("#root"));

Custom elements created with the Web Components standard

can retain the accessibility behaviors of the HTML elements
they extend. A customized built-in element that extends from
HTMLButtonElement includes all the traits of a typical HTML
<button> element. When the user presses Enter or Space, the
button is activated without any custom logic. This isn’t to say
sometimes accessibility behaviors are not necessary to implement
in autonomous custom elements or form-associated custom
elements.
 Introduction 10

1 export class ButtonComponent extends HTMLButtonElement {

2 constructor() {
3 super();
4 }
5 connectedCallback() {
6 this.addEventListener('click', this.onClick);
7 }
8 onClick() {
9 this.dispatchEvent(new CustomEvent('buttonClicked'));
10 }
11 }
12
13 customElements.define('in-button', ButtonComponent, {exte\
14 nds: 'button'});

Somehow we find ourselves at a place where web development is

no longer egalitarian. The learning curve for web development is
absurd for anyone who just wants to put a custom element on a
page. Not only does someone have to learn the component model
for a particular JavaScript framework, but how to test, maintain,
and deploy complex framework code. Then another framework
becomes popular and engineers have to relearn everything. We call
this JavaScript fatigue. Part of the problem is the fragmentation,
but in my opinion, it’s mostly a problem with education. If people
new to web development are skipping web standards in favor of
learning frameworks, they are adding complexity, without learning
about how things work. HTML elements are the most primitive
Object we have to deal with in web development. Anyone can start
developing UI with Web Components right in the browser.
Introduction 11

While it’s not practical to develop custom elements this way in

the browser, the example above is useful to demonstrate that Web
Components require zero dependencies to work.

What are Web Components?

Front end web development usually requires handling templates,
styling, and logic that defines the behavior of discrete functional
units, commonly referred to as UI components. Web Components
are a set of browser specifications that provides encapsulation
and organization for user-interface logic in a standard component
model. The term “custom elements” is often used interchangeably
with “web components”, although custom elements are just one of
the specifications that comprise Web Components.
Web Components is a marketing term that refers to several browser
standards maintained by the Web Hypertext Application Tech-
nology Working Group (WHATWG) and the World Wide Web
Consortium (W3C) in the HTML Living Standard and DOM
Standard, documents that establish the ongoing state of Hyper
Introduction 12

Text Markup Language (HTML) and Document Object Model

(DOM). WHATWG is comprised of web engineers from Apple,
Google, Microsoft, Mozilla, Opera and the broader web develop-
ment community. In 2019, W3C and WHATWG agreed to work
together to maintain the HTML standard as a living document that
constantly evolves over time.
In contrast to open source JavaScript frameworks that are main-
tained by corporate teams or the broader community, Web Com-
ponents are developed through a rigorous standardization pro-
cess. Once a particular Web Component standard is finalized,
browser vendors prioritize and implement the specification. As
of January 2020, all major web browsers including Apple Safari,
Google Chrome, Microsoft Edge, Mozilla Firefox, and Opera imple-
mented the major feature of Custom Elements v1 specification:
autonomous custom elements. Other specifications under the Web
Components umbrella, such as Shadow DOM and HTML templates,
have been part of the HTML standard for quite some time, while
some like Declarative Shadow DOM or Constructable Stylesheets
have yet to be included in all major web browsers. As HTML is
a living document, support changes over time and any feature
that lacks support in some browsers can be polyfilled. We’ll look
into this in more detail later. For now, let’s define the various
specifications that make up Web Components.

Custom elements

The cornerstone of the Web Components featureset, custom el-

ements allow new HTML tags to be defined in a web browser.
Custom Elements v1 is the stable implementation of the custom
elements specification. This standard allows you to define a new
HTML element and the HTML element’s JavaScript API. Other
specifications like ElementInternals extend the functionality of
custom elements beyond the set of specifications known as Custom
Elements v1. Custom elements allow you to observe changes to
Introduction 13

element attributes and manage content and styling for the new
element’s template. Custom elements behave like any other HTML
element, with some syntactical sugar that promotes standardization
across any custom element behavior.
There are three different types of custom elements: autonomous
custom elements, customized built-in elements, and form-associ-
ated custom elements.

Autonomous custom elements

Autonomous custom elements allow you to define customized

functionality for a new HTML element. Autonomous custom
elements extend from the HTMLElement class. The most compatible
custom element type, autonomous custom elements are available
in all evergreen browsers. This specification is what people are
typically referring to when describing Web Components or Custom
Elements v1.

Customized built-in elements

Customized built-in elements extend from known HTML ele-

ments, retaining the behaviors of those elements. Customized built-
in elements behave differently than autonomous custom elements,
although this specification retains many of the features of au-
tonomous custom elements. Customized built-in elements can be
used in several evergreen browsers, except Apple Safari which
requires a polyfill.

Form-associated custom elements

HTMLFormElementcannot access form controls like

HTMLInputElement and HTMLSelectElement that are within a
custom element’s Shadow DOM tree. This means form validation
is precarious at best. Form-associated custom elements provide an
extended API from autonomous custom elements that gives you
Introduction 14

hooks into form validation. This means you can still encapsulate a
form control’s template, while exposing the validity of the control
to the parent HTMLFormElement. Form-associated custom elements
open the door for the creation of truly customized user experiences
that participate in HTML forms. Instead of merely relying on
traditional form elements, it’s now possible to make your own.
In the first part of this book, we’ll investigate the similarities and
differences between the different types of custom elements and see
how they work together to provide complex, reusable components.

CustomElementRegistry
This interface on the window.customElements property provides
methods for registering custom elements and querying registered
elements. Every custom element must be registered with the
CustomElementRegistry through a declarative syntax.

Shadow DOM
Shadow DOM is a browser technology that provides encapsulation
for a HTML element, isolating the HTML element’s template from
the rest of DOM. When using Shadow DOM with custom elements,
you can isolate <style> and <script> within the ShadowRoot⁷:
the root node of a DOM substructure rendered outside the scope
of DOM. The top level element that employs Shadow DOM is
considered the host element. The ShadowRoot is attached to the
host element. In contrast to Shadow DOM, anything outside of the
shadow boundary in the global scope of the document is considered
Light DOM.
When you query for an element on the document using
document.querySelector or similar method, you are essentially
querying the entire document because the Document Object Model
⁷https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot
Introduction 15

(DOM) has a global scope. If you wanted to style an element or

enhance an element with some logic via JavaScript, you would
have to inject a <style> or <script> tag into the document, usually
the <head> or before the closing <body> tag in the case of JavaScript
that relies on querying for DOM that is fully loaded. Because of the
global nature of DOM, CSS or JavaScript intended for one HTML
element could collide with another the styling or logic wasn’t
intended for. When developing UI components it’s extremely
helpful to rely on an isolated scope for the component, so CSS and
JavaScript collisions can’t happen.

HTML Template

The <template> tag, first introduced in HTML5, allows HTML

to be predefined and reused throughout DOM. HTML templates
are parsed but not rendered until cloned. This behavior allows
for custom element templates to be rendered performantly when
HTML templates are used in conjunction with Shadow DOM.

HTML, CSS, and JSON Modules

Replacing the deprecated specification for JSON, CSS and HTML

modules allow for custom elements to request resources asyn-
chronously. Yet to be finalized the JSON, CSS and HTML modules
specifications are currently in development by WHATWG and
W3C.

CSS Shadow Parts

When Shadow DOM was introduced, the only way to style a

custom element’s ShadowRoot from the context of Light DOM was
to use CSS variables. CSS variables were the only method that
pierced the Shadow boundary.
Introduction 16

CSS Shadow Parts is a CSS pseudo selector ::part that allows

styling of any elements within a Shadow DOM tree that has
a matching part attribute. ::part is available in all evergreen
browsers. WHATWG is currently working on new specifications
that enable greater flexibility when styling Shadow DOM including
a specification known as Constructable Stylesheets.

Declarative Shadow DOM

Declarative Shadow DOM allows you declare Shadow DOM di-

rectly in HTML, without the need for JavaScript. This specifi-
cation opens the doors for server-side rendering Shadow DOM
and reduces the complexity when testing Web Components. With
Declarative Shadow DOM, a custom element’s Shadow Root tree
can be statically generated and analyzed.
Typically there are limitations when server-side rendering custom
elements. With the available tools, you may only be able to render a
Shadow Root that is directly exposed to Light DOM, but not render
any templates deeper in that Shadow Root’s tree. Even though
you’ve the ability for web crawlers to analyze Shadow DOM that’s
server-side rendered, there could be an unsettling flash of unstyled
content or layout shifting while loading a Shadow Root stylesheet
in the browser.
Declarative Shadow DOM negates prior limitations to server-side
rendering custom elements by providing a way to declare Shadow
DOM via HTML, without JavaScript. Declarative Shadow DOM
is available in Google Chrome and Microsoft Edge. A simple
polyfill brings Declarative Shadow DOM to browsers that have not
implemented the specification.
Introduction 17

The many uses of Web Components

Web Components have been growing in popularity since the main
specification that drives the standard, Custom Elements v1, became
available in all evergreen browsers in January 2020 with the release
of the Chromium-based Microsoft Edge browser. In 2022, Google
reported Web Component usage had almost quadrupled since 2019:
18% of websites include a custom element on the page⁸.

Single page applications

Web Components don’t replace all the functionality provided by
a JavaScript framework. Frameworks provide abstraction around
common web development tasks: routing, state management, data
binding, and coding UI components. Web Components overlap only
this last feature of JavaScript frameworks: the UI component.
You probably wouldn’t develop a complex single page application
solely with Web Components, opting to integrate custom elements
with a JavaScript framework instead. If the desire is to code a single
page application with minimal to zero external dependencies, Web
Components require, at the very least, a routing mechanism that
can instantiate and destroy custom elements. In Part Three of this
book, we’re going to cover how to use Web Components in the
context of a single page application.

Standalone widgets
Sometimes you need to code a standalone user interface that
shouldn’t interact with the rest of the page and needs to work on
several different sites. It doesn’t make sense to use a JavaScript
framework because you incur the cost of loading a dependency that
may be larger in filesize than your implementation.
⁸https://chromestatus.com/metrics/feature/popularity#CustomElementRegistryDefine
Introduction 18

Web Components work out extremely well in this scenario because

you’re coding with “vanilla” JavaScript. You can encapsulate the
template of a custom element with Shadow DOM so your compo-
nent can’t easily interact with the surrounding page. If your task is
to develop a standalone widget, you’ll learn most of what you need
in the first chunk of this book. Part One features several hands-on
exercises where you’ll explore the custom elements specification.

Static websites

Given the portability of custom elements, you can bundle custom

elements and include them in a <script> tag. When the browser
parses DOM, the custom element will be instantiated. If you want to
avoid a flash of unstyled content, it’s possible to server-side render
custom elements. In Part Three, we’re going to talk about server-
side rendering Web Components using Declarative Shadow DOM.
So far I’ve talked about how Web Components behave and where
you might find custom elements. In the next sections, I further
define Web Components through the HTML specification, then talk
about how custom elements can be viewed through the lens of a
design system, followed by a guide for getting started developing
with the repository that accompanies this book.

UI Library

The main appeal of Web Components is due to how custom

elements are interoperable and portable. UI libraries built with Web
Components make a lot of sense at large corporations that need
to scale. If you want UI components to as compatible as possible
with any framework, Web Components are well suited for that
task. Don’t take my word for it! Large corporations like Salesforce,
Microsoft, and Google have adopted Web Components for their
open source UI libraries.
Introduction 19

Developing a UI library with Web Components is intuitive because

the goals of the library align with the behavior of Web Components.
UI libraries can gain greater adoption when they are portable, inter-
operable, and have a long lifespan. In Part Two of this book, we’re
going to focus on developing a UI library with Web Components.

Implementing a design system with

Web Components
When developing user interfaces you’ll most likely reference a
mockup provided by a Designer. The UI component you’re de-
veloping is part of a design system. The definition of “design
system” is tricky, as different people have proposed vastly different
definitions, but I’m going to try anyways.
A design system is a set of guidelines for the look and feel of a
product or project. Design systems can feature a mission statement,
design ethos, vocabulary, values and measurements often referred
to as “tokens”, components, layouts, and possibly more. The design
system is a living document that defines reusable patterns engineers
can reference when developing user interfaces.
The main touchpoints for a design system web developers should
be concerned with are the following:

Tokens

Constants that define common reusable design patterns including

color, size, spacing, typography, and more.

Components

Discrete units of user interface functionality that have a distinct

purpose and behavior.
Introduction 20

Layouts

Organization of components in a web site.

Conventions used in this Book

Each chapter of this book presents a problem statement and ori-
entation, followed by acceptance criteria then a step-by-step walk-
through of the implementation, ending with a summary.

Figma

It’s practical to look at Web Components through the lens of a

design system. Web Components uses tokens as building blocks for
developing a reuseable user interface. Web Components can display
in different orientations or states: a layout. Web Components
can also be part of another layout compromised of one or many
components.
Design systems offer guidance for developing user interfaces.
Throughout this book you’ll reference the Fullstack Web
Components Design System in Figma⁹.
⁹https://www.figma.com/file/QXGa6qN6AqgeerCtS28I8z/Web-Components-Book-
Design-Library
Introduction 21

In Figma, you can reference different values of design tokens and

inspect and measure parts of UI components and layouts. Take
a moment and familiarize yourself with the Figma interface. On
the left sidebar is a navigation menu that lists different layers in
the focused artboard. When you click on elements in the artwork,
various properties of the selected element are displayed in the right
sidebar.
Whenever an element is selected, the color of that element is
displayed in the right sidebar by token name followed by the
hexidecimal value of the color.

A global CSS stylesheet provided in the development environment

for this book contains CSS variables that map to each design token.
To use the Red/300 token, you’d reference the --color-red-300 CSS
 Introduction 22

variable:

1 color: var(--color-red-300);

Similarly, CSS variables for sizing, border radius, font, icons and
box shadow are provided on the global stylesheet found in sr-
c/style/style.css. You may reference these CSS variables when
styling each UI component.

Storybook
The main development environment for a considerable portion of
this book is Storybook¹⁰, “an open source tool for building UI
components and pages in isolation.”

Storybook is run locally on your computer. In several chapters,

you’ll define Stories for the UI component you’re coding. A Story
¹⁰https://storybook.js.org
Introduction 23

is a configurable template that hosts your component. Through

the Storybook user interface, you can define different controls that
change UI component behavior. By the end of this book you should
have a good understanding of how to develop and maintain UI
components in Storybook.

Development lifecycle of a UI component in

Storybook

1. Reference the mockup in Figma

2. Define the story in Storybook
3. Style the component with design tokens
4. Develop behaviors with JavaScript / TypeScript
5. Write tests

Application
In the third part of this book, you transition from developing user
interface components to developing with those components in the
context of a web application. When developing the application,
you’ll change up the local environment to a custom Webpack server
and only use Storybook when necessary.

The application you’re going to develop is called “In”, a web app

used to store a user’s contact list. After the user authenticates with
a login form, a user interface displays a table filled with contacts.
Introduction 24

The user can view or edit the contact list. User interfaces found in
the application are developed in Storybook first, exported from a
UI library package, then imported into the application source code.

Cypress
Cypress¹¹ is a test runner you’ll use to write end-to-end tests for
each UI component.

Storyshots
Storyshots¹² is a Storybook addon you’ll use to generate automatic
visual snapshots for each UI component.

Monorepo
When developing against the content in this book, you’ll be work-
ing in a monorepo built with lerna¹³. Lerna allows you to manage
multiple projects in the same repository. Those projects are defined
as:

• client web application front end

• common reusable functions, utilities
• component UI library
• server web application back end
• style resources exported from the design system such as CSS
styles, icons, fonts
¹¹https://www.cypress.io
¹²https://storybook.js.org/addons/@storybook/addon-storyshots
¹³https://lerna.js.org
Introduction 25

Throughout the book, you’ll switch between different projects in

the repository depending on what you’re currently working on.
When developing UI components, you’ll work in the component
directory. If you’re developing the web application, you’ll code in
files found in the client or server directories.

Naming
• Class names are prefixed to avoid collisions with other UI
component libraries.
• File names are in kebab-case.

Setting up the development

environment
Getting started is easy. Great care was taken to setup a development
environment that can be used throughout the book, allowing you
to focus on the content of each chapter. To start development, clone
the repository from Github, install project dependencies, and run a
script that runs a local Webpack development server. Each of these
steps are outlined below.

Prerequisites
The following tools should be installed prior to starting develop-
ment.

Terminal application
Which Terminal you use depends on your system. MacOS and
Linux systems come with the Terminal application. For Windows
Introduction 26

10 and above, all Terminal commands featured in this book should

be run with PowerShell and Windows Subsystem for Linux¹⁴.
Follow these instructions to install Windows Subsystem for Linux¹⁵.
Running node scripts in Windows Subsystem for Linux ensures the
commands will work.

git

Changes to the codebase are tracked via git. git is a version control
system that allows projects like this one to track changes across the
codebase effectively. If you have little or no experience with git,
don’t worry. Each chapter clearly demonstrates the git commands
you’ll need to run to navigate between changes. git is installed
differently depending on your system.

• Mac¹⁶
• Windows¹⁷
• Linux¹⁸

NodeJS

node¹⁹ is a JavaScript runtime built from V8 JavaScript engine²⁰.

Whereas JavaScript is usually run in a web browser, node runs
server-side. node is traditionally used for back-end services, but it’s
also used to code tooling for JavaScript projects. npm is a package
manager for node. npm packages can be installed in any node
project, allowing you to reuse code published on the npm registry
in a local development environment.
¹⁴https://docs.microsoft.com/en-us/windows/wsl/about
¹⁵https://docs.microsoft.com/en-us/windows/wsl/install
¹⁶https://osxdaily.com/2014/02/12/install-command-line-tools-mac-os-x/
¹⁷https://gitforwindows.org/
¹⁸https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
¹⁹https://nodejs.org/
²⁰https://v8.dev/
Introduction 27

This book requires node 16 and above installed on your machine.

It is highly recommended to install node and npm with nvm²¹, the
Node Version Manager. nvm allows you to install multiple versions
of node locally, switching between them for each project on your
system. Installation instructions for nvm can be found here²².

JavaScript IDE
To actually code the various components and application in this
book you’ll need an IDE (integrated development environment).
There are many free IDE, so don’t feel like you need to spend a ton
of money on one. A few popular IDE are listed below. Download
and install your preferred application for JavaScript development.

• Visual Studio Code²³ (MacOS, Windows, Linux)

• Nova²⁴ (MacOS)
• WebStorm²⁵ (MacOS, Windows, Linux)
• Atom²⁶ (MacOS, Windows, Linux)

Once you have all of the above tools installed on your system,
you’re ready to clone the git repository, install project dependen-
cies, and run the development server.

GitHub
The repository for this book is found on GitHub. If you don’t
already have a GitHub account, signup for a new account²⁷. If
you’ve never used GitHub before on your machine, you’ll need to
²¹https://github.com/nvm-sh/nvm
²²https://github.com/nvm-sh/nvm#installing-and-updating
²³https://code.visualstudio.com/
²⁴https://nova.app/
²⁵https://www.jetbrains.com/webstorm/
²⁶https://atom.io/
²⁷https://github.com/signup
 Introduction 28

setup your username locally²⁸. More information about setting up

GitHub locally is found in the Set up Git Guide²⁹.
After you’ve properly setup git locally, fork the repository on
Github³⁰, then clone your fork of the repository via the Terminal,
making sure you run the command in a directory where code is
usually stored on your system. If you don’t already have any code
projects on your computer, make a new directory to store this
book’s codebase, then run the following command, inserting your
Github username in lieu of {username}.

1 git clone https://github.com/{username}/fullstack-web-com\

2 ponents.git

Change directory into the project root directory.

1 cd fullstack-web-components

There are times you may need to update your local repository from
the upstream repository, mainly to uptake dependency upgrades or
new content. Further instructions for maintaining your local fork
of the repository are found in the README.md³¹.

Yarn

This repository uses yarn³² to install npm dependencies and run

node scripts.

²⁸https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-
in-git
²⁹https://docs.github.com/en/get-started/quickstart/set-up-git
³⁰https://github.com/readymade-ui/fullstack-web-components
³¹https://github.com/readymade-ui/fullstack-web-components
³²https://yarnpkg.com/
 Introduction 29

1 npm install --global yarn

Once yarn is installed you can install project dependencies with the
yarn command.

1 yarn

Storybook
After project dependencies are installed with yarn, run the
storybook script to start up the local Storybook development
environment.

1 yarn storybook

If Storybook appears in the default browser on your computer, you

have correctly setup the development environment for this book.

Summary
Through the practical exercises in this book, you’ll learn how to
code user interfaces that are interoperable, reusable, accessible,
portable and require zero dependencies. The goal is to mirror best
practices at enterprise corporations that you can bring into your
own professional development.

Part One Specification

In the first part of this book, you’re going to take a deep dive into the
Web Components specification by developing the UI components
that comprise a login form. Through developing with the different
types of custom elements and several other parts of the Web
Components specification, you’ll learn:
Introduction 30

• How to encapsulate template and styling with Shadow DOM

• How to provide dynamic templates for a UI component
• The lifecycle of a custom element
• Event handling and delegation
• How to make custom elements accessible
• How to architect complex form validations

Part Two UI library

In the second part of this book, we focus on developing Web
Components in a UI library.

• We’ll use TypeScript to bring a Decorator pattern to enhance

component development, simplifying common tasks with a
standardized, opinionated interface.
• Event handling is taken to a whole new level when we
develop a table component with custom elements.
• We’ll focus on the benefit of reusable HTML templates when
developing a panel component.
• Later, we’ll implement a theme across the UI library using
CSS Shadow Parts.
• Finally, we’ll optimize the UI library for distribution by
bundling every component with Rollup.

Part Three Application

In the third part of the book, we take a look at how Web Compo-
nents are used in the context of a web application. Lerna is intro-
duced to the development environment to coordinate development
of several packages in a monorepo.

• First we’ll code an application shell with custom elements

• Then we’ll handle routing different views in our application
Introduction 31

• We will follow that with a lesson about server-side rendering

custom elements with Declarative Shadow DOM.

In the final chapter of this book, we’ll summarize what was learned
and look to the future of Web Component development.
In the next chapter Getting To Know Custom Elements, you will
learn the complete development lifecycle of an autonomous custom
element.
 Part One
Part One

Specification
In Part One of this book we’ll explore several Web Components
specifications by developing the UI components that make up a
login form. This login user interface will be used in Part Three so
users can authenticate with the application.
Part One 33

What you will learn

While developing the login use interface with Web Components,
you’ll explore the following concepts:

• How to encapsulate template and styling with Shadow DOM

• How to provide dynamic templates for a UI component
• The lifecycle of a custom element
• Event handling and delegation
• How to make custom elements accessible
Part One 34

• How to architect complex form validations

• The differences between autonomous, customized built-in,
and form-associated custom elements

Developing in Part One

You’ll use Storybook as the primary development environment
throughout Part One. For each chapter, run yarn storybook in the
Terminal. Every change made to the codebase will be reflected in
the Storybook UI while Storybook is running in Terminal. When
you are finished developing, cancel the server by holding down Ctrl
on the keyboard and pressing C.
 Getting to Know Web
Components
Chapter One

Introduction
You can make completely customized HTML elements with au-
tonomous custom elements, so it can be daunting to know where to
start. In this exercise, autonomous custom elements are highlighted
for what they do best: provide a means to bind template encapsula-
tion provided by Shadow DOM with a unique HTML tag and then
reuse the custom element throughout DOM.
Autonomous custom elements are the most ubiquitous of the three
types of custom elements due to their compatibility in all major
evergreen browsers including Apple Safari, Google Chrome, Mi-
crosoft Edge, and Mozilla Firefox. When building out a UI library,
you’ll possibly find yourself coding with autonomous custom ele-
ments the most because of their utility.
In addition to autonomous custom elements and Shadow DOM,
we’ll make use of HTML templates and CSS variables in this
chapter.

What you will build

In this chapter, you’ll code a reusable container called the Card
component. This component can contain a lot of different tem-
plates, from user profile metadata to a sign-up form, so the template
Getting to Know Web Components 36

has to be flexible enough to accept virtually any content, but rigid

enough so that layouts adhere to design guidelines found in the
design system.
Getting to Know Web Components 37
Discovering Diverse Content Through
Random Scribd Documents
 Leimfestigkeit.
Von einem Schreibpapier verlangt man, daß es leimfest ist, d. h.
daß Tintenschrift weder ausläuft noch durchschlägt. Die Forderung,
daß die Schriftzüge nicht auslaufen, ist ohne jede Einschränkung zu
stellen; ob das Papier dick oder dünn ist, die Schriftzeichen müssen
scharfe Ränder zeigen, wenn es als leimfest gelten soll.
Bei der Beurteilung des Widerstandes des Papiers gegen das
Durchdringen der Tinte muß man seine Ansprüche mit der Dicke des
Materials in Einklang bringen, da naturgemäß unter sonst gleichen
Umständen dickeres Papier stärkere Schrift zu halten im stande ist
als dünneres.
Zur Beurteilung der Leimfestigkeit von Papier hat L e o n h a r d i,
gestützt auf grundlegende, von S c h l u t t i g ausgeführte Versuche,
die Behandlung mit neutraler Eisenchloridlösung, deren Eisengehalt
1,531% beträgt, vorgeschlagen.[57] Nach seinen Beobachtungen soll
diese Lösung in ihrer Fähigkeit, Papiere zu durchdringen, mit den
besseren Schreib- und Kopiertinten übereinstimmen.
Mittels einer Ziehfeder werden auf dem zu untersuchenden
Papier Striche mit der erwähnten Eisenchloridlösung gezogen; die
Spitzen der Feder stehen hierbei 1 mm auseinander.
Nach dem Eintrocknen wird auf die Rückseite des Papiers eine
geringe Menge ätherischer Tanninlösung gegossen.
Ist das Papier schlecht geleimt, so ist Eisenlösung durch das
Papier gedrungen und diese Stelle färbt sich dann bei dem
Aufgießen der Tanninlösung mehr oder weniger schwarz.
 P o s t hat diesem Verfahren eine andere Ausführungsform
gegeben, wobei er zugleich in gewissem Maße auf die Dicke des
Papiers Rücksicht nimmt.
Die Eisenchloridlösung wird in einer Flasche aufbewahrt, wie sie
Fig. 59 zeigt. Der bis auf den Boden gehende Stopfen ist eine
Pipette, welche oben mit einer feinen Gummimembran verschlossen
ist. Die Pipette läßt bei einem Druck auf die Gummischeibe stets
Tropfen von 0,03 g fallen.
Man hängt die gefüllte Pipette so auf (Fig. 60), daß ihre Spitze
von der Tischplatte 10 cm entfernt ist, legt ein Stück des zu
untersuchenden Papiers darunter und läßt durch Drücken auf die
Gummimembran einen Tropfen der Eisenlösung fallen. Den Tropfen
läßt man nun so viel Sekunden auf dem Papier, wie dieses Gramm
pro Quadratmeter schwer ist. Nach Verlauf dieser Zeit nimmt man
den Rest des Tropfens mit Filtrierpapier auf.

Fig. 59. Fig. 60.

 Hat man auf diese Weise 4–5 Flecke erzeugt, so behandelt man
nach völligem Trocknen die Rückseite des Papiers mit Tanninlösung
wie vorher angegeben.
Von der Anwendung der ä t h e r i s c h e n Tanninlösung sollte man
indessen Abstand nehmen und statt dessen eine w ä s s e r i g e
Auflösung benützen, weil der Äther ein Lösungsmittel für Harz ist
und deshalb trotz seiner schnellen Verdunstung in das Papier
eindringen und so das Tannin in das Innere des Blattes führen kann;
man hat deshalb, wenn ein schwarzer Niederschlag entsteht, nicht
die Gewißheit, daß er auf der Rückseite entstanden ist; er kann sich
auch im Innern des Papierblattes gebildet haben.
Um dem vorzubeugen, befeuchtet man einen Flock Baumwolle
mit wässeriger Tanninlösung und fährt hiermit über die Rückseite
des zu prüfenden Papiers; das auf diese Weise schwach
angefeuchtete Papier wird sofort mit Fließpapier nachgetrocknet, so
daß Eindringen von Feuchtigkeit in das Papier von der Rückseite her
nicht zu befürchten ist.
O s w . S c h l u t t i g und Dr. G . S . N e u m a n n haben die
Ausführung der Prüfung mit Eisenchlorid noch anders gestaltet.[58]
Veranlassung hierzu gaben die Arbeiten S c h u b e r t s über das
P o s tsche Verfahren[59] und der Wunsch einen Weg zu finden, um
auch Über den G r a d der Leimung ein Urteil abgeben zu können.
 Fig. 61a. Fig. 61b.

S c h l u t t i g und N e u m a n n schlagen die Prüfung in folgender

Weise vor:
Das Papier p wird auf einem hierfür hergerichteten dachartigen
Gestell (Fig. 61a–b) befestigt, dessen Seitenwände mit der
Tischplatte einen Winkel von 60° bilden. Ein Aufsatz trägt eine
Blechrinne f, die gegen p um 45° geneigt ist. In ein Glasröhrchen
von bestimmten Abmessungen wird eine stets gleiche Menge
Eisenchloridlösung gesaugt, die in 100 Gewichtsteilen 1 g Eisen (als
Eisenchlorid), 1 g Gummi arabicum und 0,2 g Phenol enthält. Das
Röhrchen wird oben mit dem Finger verschlossen und so gegen f
gelegt, daß das untere Ende das Papier berührt. Wird nun die obere
Öffnung freigegeben, so fließt die Lösung auf dem Papier herunter.
In dieser Weise erzeugt man nach jedesmaligem Verschieben des
Aufsatzes um 3 cm noch zwei Streifen (Fig. 62). 15 Minuten nach
Bildung des dritten Streifens wird das Blatt umgedreht und auf der
Rückseite in gleicher Weise mit wässeriger Tanninlösung
(1prozentige Lösung mit 0,2 g Phenol) so behandelt, daß sich die
Streifen in der aus Fig. 63 ersichtlichen Weise kreuzen.
Bei n i c h t l e i m f e s t e n Papieren färben sich die neun
Kreuzungspunkte der Streifen wenige Sekunden nach dem
Herunterlaufen der Tanninlösung schwarz. Ein Papier gilt als
l e i m f e s t, wenn erst nach Verlauf einiger Minuten Farbreaktionen
auftreten, beginnend bei 1⁄6, so daß die inneren Kreuzungspunkte
1⁄ , 2⁄ , 1⁄ und 2⁄ deutlich grau bis schwarz, wohl auch einige der
6 6 5 5
äußeren grau gefärbt sind.

Fig. 62.

Fig. 63.

Zeigen die inneren Kreuzungspunkte nach 24 Stunden nur eine

ganz schwache graue Färbung, so gilt das Papier als s e h r
l e i m f e s t; zeigt sich nach dieser Zeit an keinem der
Kreuzungspunkte eine Färbung, so ist das Papier
a u ß e r o r d e n t l i c h l e i m f e s t.
Bei zahlreichen vergleichenden Prüfungen auf Leimfestigkeit
unter Benutzung der beiden zuletzt geschilderten Verfahren
einerseits und unter Ausführung von Schreibversuchen mit
verschiedenen Tinten andererseits zeigte sich in den meisten Fällen
Übereinstimmung in den Ergebnissen. Vereinzelt kamen aber
Abweichungen, teilweise recht auffallender Art, vor, die zeigten, daß
das Eindringen der Eisenlösung nicht immer in gleicher Weise erfolgt
wie das der Tinte.
So wurden beim Arbeiten nach P o s t, namentlich bei der
Untersuchung von blauen Aktendeckeln und Packpapieren, Fälle
beobachtet, in denen die Eisenchloridtropfen das Material völlig
durchdrangen, starke Tintenschrift aber weder auslief noch
durchdrang.
Bei Anwendung des S c h l u t t i g - N e u m a n nschen Verfahrens
wurden u. a. Fälle beobachtet, in denen Papiere nach der
Farbbildung an den Kreuzungspunkten als sehr leimfest hätten
bezeichnet werden müssen, während Tintenschrift durchschlug. Hier
spielte wohl die Oberflächenbeschaffenheit der Papiere eine Rolle,
denn bei stark geglätteten Papieren wird das Eindringen der
Prüfungsflüssigkeit bei horizontaler Lage des Papierblattes leichter
und stärker erfolgen als bei schräg liegendem Blatt.
Auf die Einzelheiten der gemachten Beobachtungen kann hier
nicht weiter eingegangen werden; sie haben aber gezeigt, daß zur
Beurteilung der Leimfestigkeit von Papier unbedingt auch Versuche
unter Verwendung von Tinte ausgeführt werden müssen. Man wählt
hierzu zweckmäßig 2–3 gute Handelsmarken verschiedener
Zusammensetzung aus, die man gut verschlossen aufbewahrt. Für
den Versuch entnimmt man jedesmal kleine Mengen aus den
Vorratsflaschen.
Der Versuch selbst wird am besten mit einer Ziehfeder
ausgeführt. Man zieht Striche von verschiedener Dicke und achtet
auf möglichst gleichmäßige Ausführung. Zunächst werden die
Spitzen der Feder für die gewünschte Strichdicke eingestellt, dann
Tinte bis zu einer gewissen Marke eingefüllt und schließlich die Feder
an einem Lineal entlang geführt, so weit es angeht, stets mit
gleicher Geschwindigkeit und in derselben Neigung zum Papierblatt.
Vor jedem neuen Strich wird die Feder wieder gefüllt.[60] Die Striche
werden untereinander gezogen und Kreuzungen vermieden.
Will man Über den Grad der Leimfestigkeit ein Urteil abgeben, so
steigert man die Strichdicke, etwa von ½ mm anfangend, von
Versuch zu Versuch um ¼ mm, bis die Tinte durchschlägt. Man kann
dann sein Urteil dahin zusammenfassen, daß das Papier leimfest ist
für Strichdicken bis zu... mm. Dieses Urteil gibt ein klares Bild über
die Beschreibbarkeit des vorliegenden Materials, klarer als die
Angaben leimfest, sehr leimfest u. s. w.
Gewöhnliche Schreibpapiere, wie Kanzlei- und Konzeptpapiere
von etwa 80–100 g Quadratmetergewicht, wird man als genügend
geleimt ansehen können, wenn ¾ mm dicke Striche weder
auslaufen noch durchschlagen.
Hat man das Papier mit der Ziehfeder behandelt, so beschreibt
man es auch in gewöhnlicher Weise, wobei man gut tut, stets den
gleichen Wortlaut, z. B. Namen und Wohnort anzuwenden, da
hierdurch eine größere Gleichmäßigkeit in der Ausführung gesichert
wird als bei stets wechselnden Worten.
Bei Papieren, die nur auf einer Seite beschrieben werden, wie
Briefumschlagpapier, kann man sich mit der Forderung begnügen,
daß die Schriftzüge scharfe Ränder aufweisen; ob sie Neigung zum
Durchschlagen zeigen, kommt praktisch nicht in Betracht. Bei
Wechselpapieren kann schwache Leimung sogar von besonderem
Wert sein, da durch das tiefe Eindringen der Tinte Fälschungen
erschwert werden.
Gegen die Ausführung der Versuche mit Tinte lassen sich
naturgemäß eine Reihe von Einwänden erheben. Einmal ist man
abhängig von der Beschaffenheit der Tinte, die auch in den besten
Fabriken nicht immer von gleicher Zusammensetzung hergestellt
werden kann, ferner ist die Art und Weise des Auftragens nicht
immer gleich, es wird nicht immer die gleiche Menge Tinte auf eine
bestimmte Strichlänge kommen u. a. m.
Ähnliche Einwände sind aber auch gegen die beiden
geschilderten Eisenchlorid-Verfahren zu machen.
Man kann aber die Versuche mit Tinte, wie schon erwähnt, nicht
entbehren und man muß sich mit den Mängeln, so gut es geht,
abfinden, bis das Verfahren weiter ausgearbeitet ist. Vielleicht
gelingt es, eine Vorrichtung zu schaffen, mit Hilfe deren man die
Tinte in stets gleicher Weise auf das Papier bringen kann (gleiche
Geschwindigkeit beim Ziehen mit der Feder, gleiche Neigung der
Feder zum Blatt, gleiche Tintenmenge für eine Längeneinheit,
gleicher Druck der Feder u. s. w.).

[57] Papierzeitung 1884, S. 625.

[58] Papierzeitung 1891, S. 1532.
[59] Papierzeitung 1885, S. 1102.
[60] Nach beendigtem Versuche reinige man die Feder gründlich,
damit sie so wenig wie möglich von der Tinte angegriffen wird.
Werden die Spitzen der Feder im Laufe des Gebrauches rauh, so
müssen sie neu eingeschliffen werden.
 Nachweis von freiem Chlor und
freier Säure.
Papiere, die freies Chlor und freie Säure enthalten, gehören zu
den Seltenheiten. Die ganzen Verhältnisse, unter denen das
Papierblatt entsteht, machen schon das Hineingelangen von Chlor
und Säure in das Papier außerordentlich schwierig. Überschüssiges
Chlor aus dem Halbstoff wird durch Hinzufügen von
Entchlorungsmitteln und durch die großen Wassermengen, mit
denen die Faser in Berührung kommt, unschädlich gemacht. Die in
dem Stoff etwa vorhandene Säure, sei sie nun direkt zugesetzt oder
durch den Alaun hineingelangt, wird teils gebunden, teils durch den
Waschprozeß entfernt.
Findet man daher ab und zu ein Papier, in dem man freies Chlor
und freie Säure nachweisen kann, so dürfte deren Anwesenheit auf
besondere Umstände bei der Fabrikation zurückzuführen sein. So
kann ein Papier, wenn beim Bleichen Chlorkalkschlamm in den Stoff
gelangt ist, Chlorkalkreste enthalten und noch eine Zeit lang die
Chlorreaktion geben.
Der Nachweis des freien Chlors im Papier geschieht in ähnlicher
Weise wie bei Prüfung des Halbzeuges; man nimmt hierbei
bekanntlich eine geringe Menge des zu prüfenden Stoffes aus dem
Holländer, preßt mit der Hand aus und läßt wenige Tropfen einer
Kaliumjodidstärkelösung darauf fallen; ist noch freies Chlor
vorhanden, so färbt sich das Halbzeug infolge der Bildung von
Jodstärke mehr oder weniger blau.
 Bei der Prüfung des fertigen Papiers verfährt man am besten in
der Weise, daß man es in Stücke zerschneidet, diese durch
destilliertes Wasser zieht und sie dann abwechselnd mit
Kaliumjodidstärkepapier übereinanderschichtet; das Ganze
beschwert man mit einer Glasplatte.
Das Wasser zieht etwa vorhandenes Chlor allmählich aus, das
Chlorwasser wirkt auf das Reagenspapier und erzeugt mehr oder
weniger blaue Streifen und Flecken.
Das Kaliumjodidstärkepapier stellt man sich her, indem man
gewöhnliche Stärke mit kaltem Wasser zu einem Brei anrührt und
diesen unter Umrühren in siedendes Wasser gießt, in welchem man
eine geringe Menge Jodkalium aufgelöst hat; durch die erkaltete
Lösung zieht man Filtrierpapier.
Wenn es so ziemlich einfach ist, sich von dem Vorhandensein
freien Chlors zu überzeugen, so ist der Nachweis freier Säure
schwieriger. Eine möglichst große Menge des zerkleinerten Papiers
übergießt man in einem Becherglase mit einer möglichst geringen
Menge destillierten Wassers; das Ganze erwärmt man etwa eine
Stunde lang mäßig, wobei ein häufiges Umrühren der Masse von
Vorteil ist. Man darf dann wohl mit Sicherheit annehmen, daß der
weitaus größte Teil aller im Papier enthaltenen, durch Wasser
ausziehbaren Stoffe, also auch die freie Säure, in Lösung gegangen
ist; man gießt den Auszug ab und arbeitet nun bei der weiteren
Untersuchung allein mit diesem. Dasjenige Mittel, dessen man sich
in der Chemie gewöhnlich zum Nachweis der freien Säuren bedient,
das blaue Lackmuspapier, läßt sich im vorliegenden Falle nicht
anwenden, da in dem Auszug in den meisten Fällen Tonerdesalze
vorhanden sind, welche ebenfalls blaues Lackmuspapier rot färben.
Ein Farbstoff, der nicht durch Tonerdesalze, wohl aber durch freie
Säure verändert wird, ist das Kongorot, und dieses kann man im
vorliegenden Fall verwenden. Man bringt in einen Teil des erhaltenen
Auszuges ein Stück Kongopapier,[61] das sich dann bei Gegenwart
freier Säure mehr oder weniger blau färbt. Die Empfindlichkeit des
Kongofarbstoffes ist erheblich geringer als die des Lackmus, und
man wird sich nicht immer mit der Kongoreaktion zufrieden geben
können. In solchen Fällen wird der wässerige Auszug aus dem Papier
mit Normalkalilauge unter Anwendung von Tropäolin als Indikator
titriert.
Von den Papieren, welche zum Umhüllen von Metallen
Verwendung finden, also zum Verpacken von Nähnadeln, Messern,
Blattmetallen u. s. w., verlangt der Verbraucher mit Recht, daß sie
frei von Stoffen sind, die das in Frage kommende Metall angreifen.
Von diesem Gesichtspunkt ausgehend wird bei Bestellung derartiger
Papiere dem Fabrikanten gewöhnlich vorgeschrieben, das Papier
„chlor- und säurefrei“ zu liefern. Mit dieser Bestimmung im Vertrag
glaubt der Bezieher alles getan zu haben, um seine Metallwaren
gegen schädliche Einflüsse durch das Papier geschützt zu wissen. Es
herrscht eben weit verbreitet die Ansicht, daß Papier, welches frei
von Chlor und Säure ist, sich ohne weiteres zum Einschlagen
jedweder Metallwaren eignet. Obwohl schon wiederholt, so
insbesondere von Dr. S t o c k m e i e r in Nürnberg, der auf diesem
Gebiet besonders erfahren ist, auf das Irrtümliche dieser Auffassung
hingewiesen worden ist, taucht sie immer wieder auf. Beschwerden
über Korrosion von Metallen durch chlor- und säurehaltige Papiere
kehren immer wieder.
Zu fest scheint die Annahme gewurzelt, daß es bei der
Beurteilung eines Papiers zu dem erwähnten Zweck lediglich darauf
ankommt, zu wissen, ob es „chlor- und säurefrei“ ist.
Gemeint ist hiermit natürlich freies Chlor und freie Säure, denn
Chlor und Säure in gebundenem Zustand sind wohl in jedem Papier
vorhanden, das als Einschlagpapier für Metalle in den Handel
kommt.
Der Lieferant eines Papiers, das zum Umhüllen von Metallwaren
bestimmt ist, kann die Bedingung „chlor- und säurefrei“ leicht
eingehen,[62] denn selbst wenn ein Papier unmittelbar nach der
Herstellung Spuren von freiem Chlor und freier Säure enthalten
sollte, nach kurzer Zeit werden beide in den gebundenen Zustand
übergeführt sein; daher wird die Prüfung auf freies Chlor und freie
Säure wohl meist zu einem negativen Ergebnis führen. Auf dieses
Ergebnis fußt dann der Verbraucher, hält das Papier für geeignet und
ist erstaunt, wenn es dennoch Metallgegenstände angreift.
Es erscheint daher angebracht, auch an dieser Stelle darauf
hinzuweisen, daß die Ursache der Einwirkung auf Metalle ganz
verschiedenartig sein kann und daß die Gewährleistung für die Güte
des Papiers von einem anderen Gesichtspunkt aus gefordert und
gegeben werden sollte, als es jetzt meist geschieht.
Wird Blattsilber von dem zum Verpacken benutzten Papier
angegriffen, so werden meist Schwefel oder Schwefelverbindungen
die Ursache sein; dasselbe Papier zum Umhüllen blanker Stahlwaren
benutzt, könnte sich vorzüglich bewähren, weil eine Einwirkung von
Schwefel oder Sulfiden auf Stahl nicht so leicht vorkommen dürfte.
Enthält ein Papier gleichzeitig Chloride und Alaun, so sind, worauf Dr.
W u r s t e r schon 1888 in der Papierzeitung hingewiesen hat, bei
feuchter Luft die Bedingungen für die Bildung von Salzsäure
gegeben; in einem solchen Papier würden Stahlwaren Rost ansetzen,
und Dr. S t o c k m e i e r hat einzelne solcher Fälle in der
„Papierzeitung“ 1893, S. 2584 bekannt gegeben und durch
Analysenergebnisse belegt. Beim Verpacken von Blattsilber in einem
solchen Papier hätte man schädliche Einflüsse viel weniger zu
befürchten.
Man wird also gut tun, dem Fabrikanten bei Bestellung von
Papieren zum Umhüllen von Metallen stets anzugeben, um welche
Metalle es sich handelt; er kann dann bei der Herstellung auf
diejenigen Verbindungen besonders Rücksicht nehmen, die dem
Metall schädlich werden können. Die Verbraucher solcher Papiere
sollten sich aber die Frage vorlegen, ob die Papiersorten, die man
infolge jahrelanger Gewohnheit zum Verpacken von Metallen
verwendet, für diesen Zweck auch besonders geeignet sind. So
kommen Stahlnadeln fast ausschließlich in dem bekannten
schwarzen Nadelpapier verpackt zum Verkauf; der Käufer ist an
diese Verpackung gewöhnt, der Verkäufer ist daher bestrebt, sie
beizubehalten, hält sie auch wohl für besonders geeignet. Dies
scheint aber nicht der Fall zu sein. Bei einer Reihe von
Vergleichsversuchen über das Verhalten blank polierter Stahlwaren in
schwarzem Nadelpapier einerseits und gewöhnlichem Schreib- und
Filtrierpapier andererseits zeigte sich in den meisten Fällen, daß das
Nadelpapier zum Verpacken am wenigsten geeignet war. Die bisher
ausgeführten Versuche sind allerdings zu einem abschließenden
Urteil nicht ausreichend, da sich die Erfahrungen aber stets in der
gleichen Richtung bewegten, so läge es wohl im Interesse der
Erzeuger und Verbraucher derartiger Papiere, wenn die Frage auf
breiter Grundlage gründlich studiert würde. Wie schon vorhin
erwähnt, gehören Alaun und Chloride zu denjenigen Stoffen, die
unter Umständen Stahlwaren angreifen können; man sollte also bei
der Herstellung von Nadelpapier hinsichtlich der Verwendung von
Alaun sehr vorsichtig sein und außerdem nur ungebleichte Stoffe
verarbeiten; auch das Färben sollte unterbleiben, wenigstens die
jetzt übliche Färbung mit Blauholz, bei der die Fasern vorher gebeizt
werden. Von der Beize bleibt ein Teil im Stoff zurück, der unter
geeigneten äußeren Bedingungen schädlich wirken kann.
Gegenständen aus Silber, leonischen Fabrikaten u. s. w. sind, wie
schon erwähnt, Papiere, die Schwefel oder Schwefelverbindungen
enthalten, besonders gefährlich; bei der Auswahl der Rohstoffe für
die Erzeugung der Papiere sollte man hierauf gebührend Rücksicht
nehmen. Schwefelhaltige Farbstoffe, wie z. B. Ultramarin, sollte man
natürlich ganz ausschließen.
Die reine Faser greift Metalle nicht an; man sollte also dahin
streben, Einschlagpapiere für Metalle lediglich aus reinem
Fasermaterial herzustellen und alle sonstigen Zusätze nach
Möglichkeit vermeiden oder doch so weit es angeht beschränken.

[61] Hergestellt durch Eintauchen von Filtrierpapier in eine

kochende Lösung von wenig Kongorot in Wasser.
[62] Namentlich wenn, wie dies sehr oft der Fall, die Papiere
ausschließlich aus ungebleichtem Natronzellstoff hergestellt
wurden.
 Vergilbung.
Als Vergilbung bezeichnet man die Änderung des Farbtones eines
Papiers beim Lagern; sie ist in mehr oder minder hohem Maße und
in mehr oder weniger langen Zeiträumen bei allen Papieren zu
beobachten[63] und ist vorzugsweise auf die Einwirkung von Licht,
Luft und Wärme zurückzuführen. Am schnellsten geht die Vergilbung
bei Einwirkung von Licht oder Wärme von statten; werden diese
beiden Faktoren ausgeschlossen, wird das Papier also unter
Abschluß von Licht in ungeheizten Räumen aufbewahrt, so hält es
sich lange unverändert.
Am leichtesten vergilben, wie bekannt, Papiere mit verholzten
Fasern, also in erster Linie holzschliffhaltige Erzeugnisse; bei diesen
bemerkt man schon, wenn sie nur kurze Zeit von der Sonne
beschienen wurden, den Beginn der Vergilbung. Je mehr verholzte
Fasern sie enthalten, um so stärker vergilben sie. Das gleiche
Verhalten zeigen Papiere, die mit Farbstoffen getönt sind, die nicht
lichtecht sind.
Aber auch holzfreie Papiere, ohne Zusatz derartiger Farben
hergestellt, vergilben oft ziemlich stark, und nach den
Untersuchungen von Dr. K l e m m sind hier vorzugsweise seifenartige
Verbindungen des Eisens mit Harz- und Fettkörpern die Ursache.
Die Menge dieser Verbindungen gibt ein Maß für die Beurteilung
der Vergilbungsneigung.
Als bestes Mittel, diese Seifen aus dem Papier herauszulösen,
empfiehlt K l e m m eine Mischung von 2 Teilen Äther und 1 Teil
Alkohol.[64]
 Mit diesen Anhaltspunkten ist der Weg zur Ermittelung der
Vergilbungsneigung eines Papiers gegeben.
Aus einer abgewogenen Menge Papier (3 g) werden die
Eisenseifen in einem Extraktionsapparat (z. B. T h o r n, S o x h l e t)
mit Hilfe des Äther-Alkoholgemisches ausgezogen, und dann wird
der Gehalt an Eisen bestimmt. Hierzu wird der Auszug zur Trockne
verdampft, geglüht und der Rückstand mit Säure aufgenommen.
Für die Eisenbestimmung leistet in den meisten Fällen das auf
Farbvergleich beruhende Verfahren mit Hilfe von Rhodanammonium
und einer titrierten Lösung von Eisenchlorid oder
Ammoniakeisenalaun in der von L u n g e und v. K é l e r[65]
ausgearbeiteten Form gute Dienste. Es erlaubt die Bestimmung auf
eine Genauigkeit von ±0,000001 g Eisen, wenn 5 ccm des Auszuges
zur Untersuchung benutzt werden. Die Gesamtmenge des
vorhandenen Eisens darf aber nicht mehr als 0,00002 g betragen. Ist
mehr Eisen vorhanden und hat man den Auszug zunächst so
hergestellt, daß 5 ccm 1 g Papier entsprechen, so muß man
entweder den Auszug entsprechend verdünnen oder aber das Eisen
in anderer Weise bestimmen.
Der in Form von Eisenseifen in Papieren vorhandene Gehalt an
Eisen schwankt nach den bisherigen Erfahrungen zwischen 0,0002 g
und 0,01 g in 100 g Papier oder 0,2 g bis 10 g in 100 kg Papier.
In einfacher, wenn auch nicht so einwandfreier Weise, kann man
den Versuch ausführen, wenn man die Eisenseifen mit Natronlauge
auszieht. Hierbei treten vielfach Zersetzungen ein, und man wird
daher dieses Verfahren nur wählen, wenn es sich lediglich um eine
möglichst schnelle Orientierung und annähernde Schätzung handelt.
Man kocht 1 g Papier im Reagensglas mit 5 ccm einer
1prozentigen alkoholischen Natronlauge aus, gießt die mehr oder
weniger stark gelb gefärbte Flüssigkeit, welche nunmehr die
organischen Eisenverbindungen enthält, in ein anderes, zuvor mit
Salzsäure sorgfältig gereinigtes Glas und fügt Salpetersäure bis zur
deutlich sauren Reaktion hinzu; dabei fällt das zur Leimung
verwendete Harz aus. Hierauf versetzt man die Lösung mit ungefähr
2 ccm einer 10prozentigen Rhodanammoniumlösung, wodurch sie
sich bei Gegenwart von Eisen mehr oder weniger rot färbt. Zum
Schluß setzt man noch 5 ccm Äther hinzu und schüttelt tüchtig
durch.
Der sich an der Oberfläche ansammelnde Äther nimmt den roten
Farbstoff auf und zeigt nun eine der Farbabstufungen von blaßrot bis
blutrot. Je dunkler die Farbe, um so mehr ist das Papier des
Vergilbens fähig.
K l e m m hat nach seinem Verfahren eine große Anzahl holzfreier
Papiere geprüft und sie gleichzeitig der Einwirkung des Lichtes
ausgesetzt. Hierbei zeigte sich, daß sie durch die infolge der
Belichtung erzielte Farbänderung einerseits und durch die
Eisenreaktion andererseits in gleicher Weise abgestuft wurden.
Man hat also in dem Verfahren ein Mittel, sich durch einen
verhältnismäßig einfachen Versuch ein Bild von dem
voraussichtlichen Vergilben des Papiers zu machen.

[63] Vergl. Dr. P. K l e m m, Über die Farbbeständigkeit der

Papiere. Klimschs Jahrbuch 1901, S. 32.
[64] Papierzeitung 1902, S. 961. Wochenblatt für
Papierfabrikation 1902, S. 810.
[65] Zeitschrift für angewandte Chemie 1896, S. 3, und L u n g e,
Chemisch-technische Untersuchungsmethoden, Bd. I, S. 325.
 Bestimmung der Saugfähigkeit
von Löschpapier.
Zur Bestimmung der Saugfähigkeit von Löschpapier bedient man
sich zweckmäßig eines von W i n k l e r vorgeschlagenen Apparates,
dessen Bau aus Fig. 64 zu ersehen ist.[66]
An dem in vertikaler Richtung verschiebbaren und in jeder Lage
durch eine Schraube festzulegenden Querbalken befinden sich 4
Maßstäbe mit Millimeterteilung und daneben 4 Klemmen zum
Festhalten des zu prüfenden Papiers. In dem unteren Teil des
Gestelles befindet sich eine Schale aus Zinkblech, in die so viel
Wasser gegossen wird, daß die Maßstäbe beim tiefsten Stand des
Querbalkens die Oberfläche eben berühren.
Zum Versuch entnimmt man Streifen von etwa 15 mm Breite (die
Breite der Streifen ist ohne Einfluß auf das Ergebnis) und 180 mm
Länge, je 5 aus der Maschinen- und Querrichtung. Diese bringt man
bei hochgehobenem Querbalken in die Klemme, wie es Fig. 64 zeigt,
so daß sie n e b e n den Maßstäben, und von diesen 1–2 mm
entfernt, herunterhängen. Die untere Kante der Streifen muß die
Maßstäbe um 5–10 mm überragen. Bringt man nun den Querbalken
in seine tiefste Lage, so tauchen sämtliche Streifen ins Wasser, und
letzteres steigt im Papier auf, zuerst schneller, dann immer
langsamer. Die Schnelligkeit des Aufsteigens hängt von der
Saugfähigkeit des Papiers ab. Als Maß für die Beurteilung hat sich
die Saughöhe nach 10 Minuten allgemein eingebürgert.
 Da die Saughöhe in der Maschinenrichtung meist etwas größer ist
als in der Querrichtung, so prüft man 5 Streifen jeder Richtung und
bildet aus den abgelesenen 10 Werten das Mittel.
Die Saughöhen der im Handel vorkommenden Löschpapiere sind
sehr verschieden; die schlechtesten, wie man sie namentlich in
Schulheften vorfindet, zeigen Saughöhen herunter bis zu 15 mm. Bei
mittlerer Handelsware findet man Saughöhen von etwa 40–60 mm,
bei den besten Erzeugnissen solche über 100 mm herauf bis 150
mm und mehr.

Fig. 64.
Winklers Löschpapierprüfer.
 Dr. K l e m m[67] hat für die Abstufung der Löschpapiere nach ihrer
Saugfähigkeit folgende Einteilung in Vorschlag gebracht:

Saughöhe nach 10
Saugfähigkeit.
Min.

ungenügen
weniger als 20 mm
d
20–40 mm schwach
41–60 „ mittel
61–90 „ groß
mehr als 90 mm s e h r g r o ß.
In Verbraucherkreisen zeigt sich vielfach eine besondere Vorliebe
für ausländische, namentlich englische Löschpapiere, die sachlich
nicht begründet ist. Zahlreiche Versuche[68] haben gezeigt, daß man
nicht nach ausländischen Erzeugnissen zu greifen braucht, um einer
großen Löschfähigkeit sicher zu sein; es gibt zur Genüge deutsche
Fabrikate, die den höchsten in dieser Hinsicht zu stellenden
Anforderungen genügen.

[66] Das von F a v i e r vorgeschlagene Verfahren, die

Löschfähigkeit von der Fläche aus zu bestimmen, hat sich nicht
als brauchbar erwiesen. (Vergl. Mitt. a. d. techn. Vers. Anst. 1896,
S. 46.)
[67] Papier-Industriekalender.
[68] Mitt. a. d. techn. Vers. Anst. 1896, S. 46.
 Prüfung von Filtrierpapier.
Bei der Beurteilung eines Filtrierpapiers spielt die
Geschwindigkeit, mit der Flüssigkeiten durchlaufen, eine
hervorragende Rolle; unter sonst gleichen Umständen wird das
Papier um so wertvoller sein, je schneller das Durchlaufen erfolgt.
Diese Eigenschaft des Filtrierpapiers kann man zahlenmäßig zum
Ausdruck bringen, indem man die Zeit bestimmt, die eine bestimmte
Menge Wasser braucht, um unter einem bestimmten Druck durch
eine bestimmte Fläche des Papiers hindurchzulaufen. Meist geht man
so zu Werke, daß man Filter von bestimmter Größe in Trichter von
bestimmtem Winkel legt und eine bestimmte Wassermenge auf das
Filter bringt. Bei diesem Vorgehen sind aber die
Versuchsbedingungen nicht immer die gleichen; die wirkende Fläche
des Filters ist nicht immer gleich groß, der Wasserdruck schwankt,
und außerdem kann das Ergebnis durch Nebenumstände (z. B.
Saugwirkungen) beeinflußt werden.
Bei dem nachstehenden, in der Versuchsanstalt unter
Zugrundelegung des M a r i o t t eschen Prinzips gebauten Apparat
werden diese Fehlerquellen vermieden.

Beschreibung des Apparates.

Die Hauptteile und die Wirkungsweise des Apparates sind aus
Fig. 65 zu ersehen.
 Ein oben und unten offenes Glasrohr G ist unten in eine
Messinghülse M eingekittet. Oben ist eine mit 2 Bohrungen
versehene Messingkappe N luftdicht aufgekittet; durch die eine
Öffnung geht ein Trichterrohr T, durch die andere ein mit einem
Hahn H versehenes Glasrohr.
Das so durch das Glasrohr G gebildete Gefäß steht durch das mit
einem Dreiwegehahn D versehene Rohr R mit dem aus Messing
gefertigten Filtrierzylinder F in Verbindung; der obere abnehmbare
und mit der Ablaufrinne A versehene Teil E des Zylinders kann durch
Schrauben mit dem unteren Teil verbunden werden. Zwischen F und
E wird das zu prüfende Papier eingespannt; das aus E durch die
Ablaufrinne A ablaufende Wasser wird in dem Kolben K aufgefangen
und gemessen.

Versuchsausführung.
Aus dem zu prüfenden Papier werden zunächst kreisrunde Stücke
von etwa 5 cm Durchmesser, wenn möglich je eins aus 10
verschiedenen Bogen, entnommen. Man entfernt dann E von F, stellt
D so, daß durch R kein Wasser abfließen kann, öffnet H und gießt
durch T d e s t i l l i e r t e s , v o r d e m G e b r a u c h s t a r k
a u s g e k o c h t e s W a s s e r von etwa 20° C. in G; nach beendigter
Füllung wird H wieder geschlossen.
Dann wird D so gestellt, daß langsam Wasser in den unteren Teil
des Filtrierzylinders tritt; ist dieser gefüllt und zwar so weit, daß die
Wasserkuppe über den oberen Rand von F hervorragt, so stellt man
den Wasserzufluß bei D ab und legt eins der 10 Blätter auf den
abgeflachten Rand von F; hierauf wird E aufgesetzt, fest auf F
geschraubt und dann durch Drehen von D die Verbindung von G mit
F wieder hergestellt. Das Wasser dringt nun durch das Papier, füllt E
und läuft dann durch A in den Kolben K. Man kann nun bestimmen,
innerhalb welcher Zeit eine bestimmte Menge Wasser (z. B. 100
ccm) durch das Papier hindurch geht.
 Fig. 65.
Herzbergs Filtrierpapierprüfer.

Der Druck, unter dem das Ausfließen erfolgt, wird bedingt durch
die Entfernung der unteren Öffnung des Trichters T von dem
Wasserspiegel in E; durch Verschieben von T kann man also den
Druck beliebig einstellen.
In der Versuchsanstalt wird bei Ausführung amtlicher Prüfungen
stets mit einer Druckhöhe von 50 mm gearbeitet; die Abmessungen
des Filtrierzylinders sind so gewählt, daß bei dem Filtrierpapier eine
wirksame Fläche von 10 qcm abgegrenzt wird. Die Durchlaufzeit von
100 ccm wird in Sekunden bestimmt; als Endergebnis wird diejenige
Wassermenge angegeben, die in einer Minute bei einem
Wasserdruck von 50 mm und einer Wasserwärme von 20° C. durch
100 qcm Papier läuft.
Mit Hilfe des Filtrierapparates kann man auch die Festigkeit des
Filtrierpapiers im nassen Zustande feststellen, indem man durch
Höherziehen des Trichterrohres T den Wasserdruck so lange steigert,
bis das eingespannte Papier durchreißt.
Um einen Überblick über die Filtriergeschwindigkeit der im
Handel vorkommenden Filtrierpapiersorten für analytische Zwecke zu
gewinnen, wurden 30 verschiedene Proben aufgekauft und in
geschilderter Weise geprüft. Die in der Minute durchlaufende
Wassermenge schwankte von 23 ccm bis zu 760 ccm; die Verteilung
innerhalb dieser Grenzen zeigt die nachfolgende Zusammenstellung.

0–100 101–200 201–300 301–400 401–500 501–600 601–700 701–800

ccm ccm ccm ccm ccm ccm ccm ccm

4 Papiere 3 Papiere 7 Papiere 4 Papiere 3 Papiere 3 Papiere 4 Papiere 2 Papiere

Eine zweite wichtige Eigenschaft der Filtrierpapiere ist ihre

Scheidungsfähigkeit; man versteht hierunter die Fähigkeit, feste in
Flüssigkeiten schwimmende Körper, wie Niederschläge u. s. w., beim
Filtrieren mehr oder weniger vollkommen zurückzuhalten. Um sich in
dieser Hinsicht ein Bild von der Brauchbarkeit eines Filtrierpapiers für
chemische Arbeiten zu verschaffen, prüft man es zweckmäßig mit
einem Baryumsulfatniederschlag in folgender Weise.
Gleiche Teile einer Baryumchloridlösung (122 g Salz in 1 Liter
Wasser) und Kaliumsulfatlösung (87 g Salz in 1 Liter Wasser) werden
einmal heiß und einmal kalt miteinander vermischt. Die heiße Fällung
wird heiß, die kalte in kaltem Zustande filtriert. Aus dem zu
prüfenden Papier wird ein Rundfilter von etwa 10 cm Durchmesser
geschnitten, in gewöhnlicher Weise in den Trichter glatt eingelegt
und mit Wasser angefeuchtet.
Papiere mit hervorragender Scheidungsfähigkeit ergeben selbst
bei kalt gefälltem und kalt filtriertem Baryumsulfat klare Filtrate;
andere lassen bei kalter Fällung die Flüssigkeit trübe durchlaufen,
liefern aber bei heiß gefälltem und heiß filtriertem Niederschlag eine
klare Lösung; noch andere zeigen in beiden Fällen trübe
durchlaufende Flüssigkeiten.
Bei 5 in der Versuchsanstalt auf Antrag geprüften Sorten wurden
Durchlaufsmengen von 141, 203, 296, 952 und 1250 ccm
beobachtet.
Bei den Papieren 141 und 296 filtrierte kalt und heiß gefälltes
Baryumsulfat völlig klar, bei den übrigen die kalte Fällung stark
trübe, die heiße mehr oder weniger trübe.
Handelt es sich um Filtrierpapiere für gewerbliche Zwecke oder
um solche des Haushaltes, so wird man naturgemäß bei der Prüfung
den Verwendungszweck berücksichtigen und nicht etwa die
Brauchbarkeit eines Kaffeefiltrierpapiers nach seinem Verhalten zu
einer Baryumsulfatfällung beurteilen.
Die Prüfung eines Filtrierpapiers auf Fettstoffe und Eisen
geschieht in bekannter Weise durch Ausziehen mit Äther
beziehungsweise durch Behandeln mit Kaliumeisencyanür (oder
Untersuchung der Asche). Über die Art des zur Herstellung
verwendeten Rohmaterials gibt die mikroskopische Untersuchung,
über den Gehalt an unverbrennlichen Bestandteilen die Veraschung
des Papiers Aufschluß.
 Anhang.

Vorschriften für die Lieferung und Prüfung Von

[69]
Papier zu amtlichen Zwecken.
Vom 1. Januar 1893 ab treten unter gleichzeitiger Aufhebung der Grundsätze
für amtliche Papierprüfungen vom 5. Juli 1886 nachstehende V o r s c h r i f t e n
für die Lieferung und Prüfung von Papier zu amtlichen
Z w e c k e n in Kraft.

§ 1.

Unter Zugrundelegung der folgenden Tabellen für die Stoff- und

Festigkeitsklassen (Tabelle I und II) sollen die zu amtlichen Zwecken bestimmten
Papiere die in Tabelle III gegebenen Eigenschaften, Bogengrößen und
Einheitsgewichte besitzen. Die Bogengröße 33 × 42 cm ist überall, auch bei
Formularen, Büchern u. s. w., vorzugsweise in Anwendung zu bringen.

Ta b e l l e I.
S t o f f k l a s s e I b i s I V.

Klasse I. Papiere, nur aus Hadern, mit nicht mehr als 3% Asche.
Klasse II. Papiere aus Hadern, mit Zusatz bis zu 25% von Cellulose, Strohstoff,
Esparto, aber frei von Holzschliff, mit nicht mehr als 5% Asche.
Klasse III. Papiere von beliebiger Stoffzusammensetzung, jedoch ohne Zusatz
von Holzschliff, mit nicht mehr als 15% Asche.
Klasse IV. Papiere von beliebiger Stoffzusammensetzung und mit beliebigem
Aschengehalt.
 Ta b e l l e I I.
F e s t i g k e i t s k l a s s e 1–6.

Skala
Klasse 1 2 3 4 5 6 für den Widerstand
gegen Zerknittern

a Mittlere 0) außerordentlich
Reißlänge in gering,
Metern
mindestens 6000 5000 4000 3000 2000 1000
b Mittlere 1) sehr gering,
Dehnung in
Pro- 2) gering,
zenten der
ursprüng-
lichen Länge 3) mittelmäßig,
mindestens 4,5 4 3 2,5 2 1,5
c Widerstand 4) ziemlich groß,
gegen Zer-
5) sehr groß,
knittern 6 6 5 4 3 1
6) sehr groß,
7) außerordentlich
groß.

Unter Berücksichtigung der beiden Klassifikationstabellen I und II gelten die in

Tabelle III gegebenen Vorschriften.

Ta b e l l e I I I.
Verwendungsklassen, B ogengrößen und Gewichte der
N o r m a l p a p i e r e.

Gewichte
Eigenschaften
Bogen- für
Klassen-
Verwendungsart Festig- größe 1000 1
zeichen Stoff-
keits cm Bogen qm
klasse
klasse kg g

A. S c h r e i b p a p i e r
1 Für besonders wichtige, auf lange
Aufbewahrungsdauer berechnete
Urkunden 33×42 15 –
Ordrepapier (Quart) I 1 26,5×42 12 –
Für Urkunden,
Standesamtsregister,
Geschäftsbücher u. s. w.:
2a für erste Sorte I 2 33×42 14 –
2b für zweite Sorte I 3 33×42 13 –
Für das zu dauernder
Aufbewahrung
bestimmte Aktenpapier:
3a für Kanzlei-, Mundir- u. s. w.
Papier 33×42 13 –
Briefpapier (Quart-) 26,5×42 10,4 –
II 3
desgl. (Oktav-) 26,5×21 5,2 –
3b für Konzeptpapier II 4 33×42 13 –
Für Papiere, welche für den
gewöhnlichen
Gebrauch bestimmt sind und nur
einige Jahre in Akten u. s. w.
aufbewahrt werden sollen:
4a für Kanzlei-, Mundir- usw. Reißlänge
Papier 3500 m,
Briefpapier (Quart-) Dehnung
desgl. (Oktav-) 2,75%, 33×42 12 –
III Widerstand 26,5×42 9,6 –
gegen Zer- 26,5×21 4,8 –
knittern
ziemlich
groß
4b für Konzeptpapier III 4 33×42 12 –
Bemerkung. Die unter A 1–4b
gegebenen
Vorschriften gelten auch für
solche
Schreibpapiere, welche
gleichzeitig
bedruckt werden
 (Standesamtsregister,
Tabellenwerke u. s. w.).
Für Briefumschläge, Packpapier
etc.
und zwar:
5a für erste Sorte II 3 – – –
5b für zweite Sorte III 5 – – –
für Briefumschläge (für beide
Sorten):
1) bis zur Größe 13×19 cm – – – – 70
2) für größere und solche
Umschläge,
welche für Geld- und – – – – 115
Wertsendungen
bestimmt sind
für Packpapier:
für Klasse 5a – – – – 130
für Klasse 5b – – – – 115
6 Für Papiere, welche zu
untergeordneten
Zwecken im täglichen Verkehr
verwendet
werden sollen und an welche
Ansprüche
auf Dauerhaftigkeit nicht gestellt
werden, kann ohne besondere
Rücksicht
auf eine Festigkeitsklasse gewählt
werden IV – – – –

B. A k t e n d e c k e l.
7a Für Aktendeckel, welche Reißlänge
für häufigen Gebrauch und 2500 m,
I 36×47 81,2 480
längere Dehnung
Aufbewahrung bestimmt sind 3,5%
7b Für Aktendeckel, welche Reißlänge
2500 m,
für laufenden Gebrauch III 36×47 42,3 250
Dehnung
bestimmt sind
2,5%

C. D r u c k p a p i e r.
 8a Für wichtigere, zu dauernder I
Aufbewahrung aber
bestimmte Drucksachen bis zu 4 – – –
10%
Asche
8b Für weniger wichtige Drucksachen III 4 – – –
8c Für Drucksachen, welche zu
untergeordneten
Zwecken im täglichen Verkehr
verwendet
werden sollen, kann ohne
Rücksicht auf
eine Festigkeitsklasse gewählt
werden IV – – – –

Gewichte für
Klassen- 1000
Verwendungsart 1 qm
zeichen Bogen
g
kg

Für Bücher, Formulare u. s. w. sind in den Fällen, in

welchen die normale Größe Nr. 1 = 33×42 nicht
anwendbar
ist, die nachfolgenden Bogengrößen oder vielfache
derselben,
in der Regel unter Innehaltung der gleichzeitig
angegebenen
Einheitsgewichte, zu benutzen
Nr. 2 = 34×43 cm 14,6
„ 3 = 36×45 „ 16,2
100
„ 4 = 38×48 „ 18,2
„ 5 = 40×50 „ 20,0
Nr. 6 = 42×53 cm 24,5
„ 7 = 44×56 „ 27,1
110
„ 8 = 46×59 „ 29,9
„ 9 = 48×64 „ 33,8
Nr. 10 = 50×65 cm –
nach
„ 11 = 54×68 „ –
Bedarf
„ 12 = 57×78 „ –
 Gegen die in der vorstehenden Tabelle III angegebenen Einheitsgewichte darf
die Lieferung

a. für Schreib- und Druckpapier um 2,5%,

b. für Aktendeckel und Packpapier um 4,0%

nach oben oder unten abweichen, wobei die Riesumhüllung (das zum Verpacken
von 1000 Bogen verwendete Umschlagpapier) bei der Gewichtsfeststellung
mitgewogen wird.

§ 2.

Die Schreibpapiere der Stoffklassen I, II und III, soweit sie den

Verwendungsklassen 1 bis 4b angehören (§ 1), sind mit einem Wasserzeichen zu
versehen. Das Wasserzeichen soll im nassen Zustande auf dem Siebe in das Papier
gebracht werden. Es soll die Firma des Erzeugers (Fabrikanten) in Buchstaben
sowie neben dem Worte „Normal“ das Zeichen der Verwendungsklasse, welcher
das Papier genügen soll, enthalten; die Hinzufügung einer Jahreszahl wird dem
Fabrikanten freigestellt. Abkürzung der Firmenbezeichnung ist gestattet, indessen
nur soweit, daß man ohne Zweifel und ohne weiteres auf den Inhaber
zurückgreifen kann. Das Wasserzeichen muß vollständig, wenn auch unterbrochen,
in jedem Bogen vorhanden sein.

§ 3.

Papiere der Verwendungsklassen 1 bis 4b (§ 1) werden nur von Firmen

angenommen, deren Wasserzeichen bei der Königlichen mechanisch-technischen
Versuchsanstalt (Charlottenburg, Technische Hochschule) angemeldet sind.

§ 4.

Die mit dem vorschriftsmäßigen Wasserzeichen versehenen Normalpapiere

dürfen in ihrer Reißlänge um höchstens 10% und in ihrer Dehnbarkeit ebenfalls
um höchstens 10% nach unten hin von den in Tabelle III (§ 1) genannten
Eigenschaften abweichen. Alle anderen Eigenschaften müssen vorhanden sein,
wenn das Papier bei der Prüfung als zu der im Wasserzeichen angegebenen
Verwendungsklasse gehörig anerkannt werden soll.

§ 5.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com