Open-source News

A gentle introduction to HTML

opensource.com - Thu, 08/11/2022 - 15:00
A gentle introduction to HTML Jim Hall Thu, 08/11/2022 - 03:00 1 reader likes this 1 reader likes this

I feel confident in claiming that HTML is the most widely used markup language ever. While other markup languages exist, including nroff and groff, LaTeX, and Markdown, no other markup language is as widespread as the Hyper Text Markup Language. HTML is the de facto language of the Web. First implemented in web browsers in 1994, the language continues to evolve. Yet the basics of HTML remain the same.

If you are just getting started in HTML, I wanted to offer this gentle introduction to learning HTML. I focus on the essentials of HTML to build a basic understanding of how HTML works. You can use this as a starting point to learn more about HTML.

Collect words to fill a paragraph

Let's start with a basic understanding of HTML and how client applications like web browsers display HTML documents. At its core, HTML collects words in a file and fills a paragraph. That means if you don't add instructions (called markup) to an HTML file, and just leave it as plain text, a web browser turns all that text into a single paragraph.

Start with this sample text, saved in a plain text file called index.html. This is a paragraph from the old King's Toaster story, an Internet fable about how you might build a toaster out of a microcontroller:

The engineer replied,

"Using a four-bit microcontroller, I would write a simple
program that reads the darkness knob and quantizes its
position to one of 16 shades of darkness, from snow white
to coal black.

The program would use that darkness level as the index to
a 16-element table of initial timer values.

Then it would turn on the heating elements and start the
timer with the initial value selected from the table.

At the end of the time delay, it would turn off the heat
and pop up the toast.

Come back next week, and I'll show you a working
prototype."

You can put this file on a web server and access it like you would any website, or you can save it to your local disk and open it directly in a web browser. How you get the file into the web browser doesn't really matter. But you should name the file with an .html extension, which web browsers recognize by default as an HTML file.

In this case, I've written the file on separate lines. I've also added some blank lines, to demonstrate that HTML doesn't care about extra white space. This extra space may help humans read the HTML code, but the web browser just treats it as one block by default. Viewed on a web browser, this file looks like this:

Image by:

(Jim Hall, CC BY-SA 4.0)

Inline and block elements

At the core of HTML is the concept of inline and block elements. You can think of block elements as always filling a rectangle. Inline elements follow only the inline text.

The basic block element is called the division, and uses the tag. The basic inline element is the span, with the tag. Most HTML tags are some kind of block element or inline element, so it helps to start with just these two to understand how they work.

Add some and tags to your HTML document to see what block and inline elements look like:

<div>
The engineer replied,

"Using a four-bit microcontroller, I would write a simple
program that reads the darkness knob and quantizes its
position to one of 16 shades of darkness, from snow white
to coal black.

<span>
The program would use that darkness level as the index to
a 16-element table of initial timer values.
</span>

Then it would turn on the heating elements and start the
timer with the initial value selected from the table.

At the end of the time delay, it would turn off the heat
and pop up the toast.

Come back next week, and I'll show you a working
prototype."
</div>

I've added a block element around the whole paragraph, and a around just one sentence. Notice that when I start an HTML element like or , I need to provide its corresponding closing tag like and . Most HTML elements are formed like this, with an opening and closing tag.

The web browser uses these tags to display HTML content in a certain way, but because and don't really define any special formatting on their own, you can't see that anything has changed. Your sample paragraph looks the same as before:

Image by:

(Jim Hall, CC BY-SA 4.0)

You can include direct styling in these tags with a style instruction, so you can see how the block and inline elements behave. To make the boundaries of each element stand out, let's use a light blue background for the block and a pink background for the :

<div style="background-color:lightblue">
The engineer replied,

"Using a four-bit microcontroller, I would write a simple
program that reads the darkness knob and quantizes its
position to one of 16 shades of darkness, from snow white
to coal black.

<span style="background-color:pink">
The program would use that darkness level as the index to
a 16-element table of initial timer values.
</span>

Then it would turn on the heating elements and start the
timer with the initial value selected from the table.

At the end of the time delay, it would turn off the heat
and pop up the toast.

Come back next week, and I'll show you a working
prototype."
</div>

With these changes, the entire paragraph has a light blue background. The block element is a rectangle, so the blue fills even the empty space after the last sentence ends. Meanwhile, the second sentence has a pink background. This highlight follows the sentence because is an inline element.

Image by:

(Jim Hall, CC BY-SA 4.0)

Most HTML elements are either block or inline. The only difference is these other elements carry some default styles, depending on what they are. For example,

is a block element that has extra space above and below the block. The heading tags, through , are also block elements defined at different font sizes and text styles like italics and bold. The tag is an inline element that displays text in a bold weight. Similarly, is also an inline element that sets the text in an italics style.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources Finishing an HTML page

Some HTML elements are required. While the sample HTML file you have used display correctly on any web browser, it is not technically a correct HTML page. There are a few elements you need to add:

Every HTML document should provide a document type declaration. Use the single tag on the first line of the HTML file to define an HTML document. The HTML standard also expects you to wrap the document text in two block elements: to define the full page, and to define the document body.


<html>
<body>
<div style="background-color:lightblue">
The engineer replied,
...
</div>
</body>
</html>

HTML documents also need a block before the that provides meta information about the page. The only required meta information is the title of the document, defined by the element:


<html>
<head>
<title>The King's Toaster</title>
</head>
<body>
<div style="background-color:lightblue">
The engineer replied,

"Using a four-bit microcontroller, I would write a simple
program that reads the darkness knob and quantizes its
position to one of 16 shades of darkness, from snow white
to coal black.

<span style="background-color:pink">
The program would use that darkness level as the index to
a 16-element table of initial timer values.
</span>

Then it would turn on the heating elements and start the
timer with the initial value selected from the table.

At the end of the time delay, it would turn off the heat
and pop up the toast.

Come back next week, and I'll show you a working
prototype."
</div>
</body>
</html>

The supporting tags like , , and do not change how the HTML page appears in a web browser, but they are required for a technically correct HTML document:

Image by:

(Jim Hall, CC BY-SA 4.0)

This gentle introduction to HTML provides just the essentials of HTML, but now that you understand block and inline elements, you're well on your way to learning how to write HTML documents using other HTML tags.

Learn the markup language of the web.

Programming Linux Documentation What to read next How I use the Linux fmt command to format text How I use the Linux sed command to automate file edits Old-school technical writing with groff Create beautiful PDFs in LaTeX This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Mesa 22.2-rc2 Released With Many Fixes - Heavy On Zink

Phoronix - Thu, 08/11/2022 - 12:00
Following last week's branching and feature freeze along with the Mesa 22.2-rc1 release, released on Wednesday evening was Mesa 22.2-rc2 as the first week's worth of bug fixing...

"CC_OPTIMIZE_FOR_PERFORMANCE_O3" Performance Tunable Dropped In Linux 6.0

Phoronix - Thu, 08/11/2022 - 03:00
Following recent upstream discussions around the -O3 compiler optimizations for the Linux kernel, the Kconfig switch advertising this option is being removed in Linux 6.0...

Adopting Sigstore Incrementally

The Linux Foundation - Thu, 08/11/2022 - 02:21

This post is authored by Hayden Blauzvern and originally appeared on Sigstore’s blog. Sigstore is a new standard for signing, verifying, and protecting software. It is a project of the Linux Foundation. 

Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.

Sigstore additionally has the ability to use code signing certificates with short-lived signing keys bound to OpenID Connect identities. This signing approach offers simplicity due to the lack of key management; however, this may be too drastic of a change for enterprises that have existing infrastructure for signing. This blog post outlines strategies to ease adoption of Sigstore while still using existing signing approaches.

Signing with self-managed, long-lived keys

Developers that maintain their own signing keys but want to migrate to Sigstore can first switch to using Cosign to generate a signature over an artifact. Cosign supports importing an existing RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and can sign and verify with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.

Benefits
  • Developers can get accustomed to Sigstore tooling to sign and verify artifacts.
  • Sigstore tooling can be integrated into CI/CD pipelines.
  • For signing containers, signature metadata is published with the OCI image in an OCI registry.
Signing with self-managed keys with auditability

While maintaining their own signing keys, developers can increase auditability of signing events by publishing signatures to the Sigstore transparency log, Rekor. This allows developers to audit when signatures are generated for artifacts they maintain, and also monitor when their signing key is used to create a signature.

Developers can upload a signature to the transparency log during signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If developers would like to use their own signing infrastructure while still publishing to a transparency log, developers can use the Rekor CLI or API. To upload an artifact and cryptographically verify its inclusion in the log using the Rekor CLI:

rekor-cli upload --rekor_server https://rekor.sigstore.dev \ --signature <artifact_signature> \ --public-key <your_public_key> \ --artifact <url_to_artifact|local_path> rekor-cli verify --rekor_server https://rekor.sigstore.dev \ --signature <artifact-signature> \ --public-key <your_public_key> \ --artifact <url_to_artifact|local_path>

In addition to PEM-encoded certificates and public keys, Sigstore supports uploading many different key formats, including PGP, Minisign, SSH, PKCS#7, and TUF. When uploading using the Rekor CLI, specify the –pki-format flag. For example, to upload an artifact signed with a PGP key:

gpg --armor -u user@example.com --output signature.asc --detach-sig package.tar.gz gpg --export --armor "user@example.com" > public.key rekor-cli upload --rekor_server https://rekor.sigstore.dev \ --signature signature.asc \ --public-key public.key \ --pki-format=pgp \ --artifact package.tar.gz Benefits
  • Developers begin to publish signing events for auditability.
  • Artifact consumers can create a verification policy that requires a signature be published to a transparency log.
Self-managed keys in identity-based code signing certificate with auditability

When requesting a code signing certificate from the Sigstore certificate authority Fulcio, Fulcio binds an OpenID Connect identity to a key, allowing for a verification policy based on identity rather than a key. Developers can request a code signing certificate from Fulcio with a self-managed long-lived key, sign an artifact with Cosign, and upload the artifact signature to the transparency log.

However, artifact consumers can still fail-open with verification (allow the artifact, while logging the failure) if they do not want to take a hard dependency on Sigstore (require that Sigstore services be used for signature generation). A developer can use their self-managed key to generate a signature. A verifier can simply extract the verification key from the certificate without verification of the certificate’s signature. (Note that verification can occur offline, since inclusion in a transparency log can be verified using a persisted signed bundle from Rekor and code signing certificates can be verified with the CA root certificate. See Cosign’s verification code for an example of verifying the Rekor bundle.)

Once a consumer takes a hard dependency on Sigstore, a CI/CD pipeline can move to fail-closed (forbid the artifact if verification fails).

Benefits
  • A stronger verification policy that enforces both the presence of the signature in a transparency log and the identity of the signer.
  • Verification policies can be enforced fail-closed.
Identity-based (“keyless”) signing

This final step is added for completeness. Signing is done using code signing certificates, and signatures must be published to a transparency log for verification. With identity-based signing, fail-closed is the only option, since Sigstore services must be online to retrieve code signing certificates and append entries to the transparency log. Developers will no longer need to maintain signing keys.

Conclusion

The Sigstore tooling and infrastructure can be used as a whole or modularly. Each separate integration can help to improve the security of artifact distribution while allowing for incremental updates and verifying each step of the integration.

The post Adopting Sigstore Incrementally appeared first on Linux Foundation.

Linux 6.0 Adds Raptor Lake P Support To Intel's TCC Cooling Driver

Phoronix - Thu, 08/11/2022 - 02:01
While last week saw the main set of thermal and power management updates for Linux 6.0, a few more items were sent in this week for the v6.0 merge window...

Weston 11.0 Alpha Released With Many Improvements For This Wayland Compositor

Phoronix - Wed, 08/10/2022 - 21:10
Weston 11.0 Alpha is out as the newest feature milestone for this reference Wayland compositor that has seen quite an uptick in development activity this year...

Pages