Home
HTML

HTML Unleashed: Bombs, Fonts, and Canvas Creations!

Jamal El Hizazi
HTML Unleashed: Bombs, Fonts, and Canvas Creations!

HTML, the backbone of the web! For over a decade, I’ve been immersed in its intricacies, from crafting simple layouts to wrestling with its quirks. You might be surprised to know that even after all this time, HTML continues to evolve, throwing curveballs and presenting new challenges. This isn't just about semantic tags or responsive design; we're diving into the deep end, exploring the unexpected corners of HTML that can either empower you or leave you scratching your head.

In this article, we're not just skimming the surface. We're going to explore some unconventional uses of HTML, from the potentially dangerous (but educational!) concept of a <strong>valid HTML zip bomb</strong> to the artistic possibilities of <strong>HTML-in-Canvas</strong>. We'll even tackle the frustrating problem of custom fonts not rendering correctly in tools like <strong>WKHTMLTOPDF</strong>. Get ready to push the boundaries of what you thought HTML could do!

So, buckle up! We are about to embark on a journey through the wilder side of HTML, uncovering hidden gems and learning lessons that will make you a more versatile and resourceful web developer. Let's get started!

The Dark Side: Valid HTML Zip Bomb

Let's start with a disclaimer: I'm presenting this for educational purposes only. Creating and distributing a <strong>valid HTML zip bomb</strong> is unethical and potentially illegal. Don't do it!

A zip bomb, in essence, is a compressed file that expands to an enormous size when decompressed, potentially crashing a system. You might be wondering, "How does this relate to HTML?" Well, HTML allows for entity expansion. By defining nested entities that reference each other, you can create a relatively small HTML file that, when parsed, expands to a massive size, consuming memory and potentially causing a denial-of-service. In my 5 years of experience, I have never implemented this, and I do not recommend doing so.

The basic principle involves defining an entity that contains multiple references to other entities, which in turn contain more references. The browser or parser dutifully expands these entities, leading to exponential growth. The code might look something like this (remember, this is just for illustration!):

<!DOCTYPE html>
<html>
<head>
  <title>HTML Bomb</title>
</head>
<body>
  <p>This is just an example. Do not use maliciously!</p>
  <!ENTITY lol1 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol2 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol3 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol4 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol5 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol6 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol7 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
  <!ENTITY lol8 "&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;">
  <!ENTITY lol9 "&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;&lol10;">
  <!ENTITY lol10 "lolololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololololol">
  <p>&lol1;</p>
</body>
</html>

Important warning: Running this code can crash your browser or even your system. Proceed with extreme caution and only in a controlled environment!

Taming the Fonts: WKHTMLTOPDF Woes

Ever struggled with <strong>WKHTMLTOPDF doesnt see my custom fonts when i use it by font face</strong>? You're not alone! This is a common pain point when trying to generate PDFs from HTML that uses custom fonts defined with @font-face in CSS. I remember spending hours debugging this issue for a client project involving dynamically generated reports.

The key to solving this often lies in ensuring that WKHTMLTOPDF can actually access the font files. Here's what I've found to be crucial:

  1. Absolute Paths: Use absolute paths to your font files in the src attribute of your @font-face declarations. Relative paths often cause issues because WKHTMLTOPDF might be running in a different context. For example: src: url('file:///path/to/your/font.woff2') format('woff2');
  2. Font Format Support: Ensure that the font format you're using is supported by WKHTMLTOPDF. WOFF and WOFF2 are generally good choices.
  3. Permissions: Verify that the user running WKHTMLTOPDF has read permissions for the font files.
  4. Embedding Fonts: Consider embedding the fonts directly into the HTML as base64 encoded data URIs. This eliminates the need for external font files altogether, but can increase the size of your HTML.

Here's an example of how you might define a @font-face rule with an absolute path:

@font-face {
  font-family: 'MyCustomFont';
  src: url('file:///path/to/your/font.woff2') format('woff2');
  font-weight: normal;
  font-style: normal;
}

body {
  font-family: 'MyCustomFont', sans-serif;
}

Remember to replace /path/to/your/font.woff2 with the actual absolute path to your font file. Debugging font rendering issues in WKHTMLTOPDF can be frustrating, but these steps should help you get your custom fonts displaying correctly.

Styling the Unstylable: Custom Search Engine Search Bar

<strong>How can I copy the css for the Custom Search engine search bar to make a similar looking dropdown box?</strong> is a question I've seen pop up frequently. Google's Custom Search Engine (CSE) provides a decent search bar, but often developers want to replicate its style in other parts of their application, like a custom dropdown box. The challenge is that you don't have direct access to the CSE's CSS.

Here's my approach to reverse engineering the CSE search bar's styling:

  1. Inspect Element: Use your browser's developer tools (right-click on the search bar and select "Inspect" or "Inspect Element") to examine the HTML and CSS applied to the CSE search bar.
  2. Identify Key Styles: Pay close attention to the font, colors, borders, padding, and any other visual properties that define the search bar's appearance.
  3. Recreate in CSS: Create your own CSS rules that mimic the styles you identified in the previous step. You'll likely need to create similar HTML structure for your dropdown box to apply the styles correctly.
  4. Fine-Tune: Adjust your CSS to perfectly match the CSE search bar's appearance. This might involve some trial and error.

Keep in mind that Google might change the CSE's styling at any time, so your replicated styles might eventually become outdated. You also need to adhere to Google's CSE terms of service.

For instance, if you inspect the CSE search bar, you might find CSS properties like these:

.gsc-input {
  border: 1px solid #ccc;
  padding: 5px 10px;
  font-size: 14px;
  border-radius: 3px;
}

You can then use these properties as a starting point for styling your own dropdown box.

Canvas Creations: HTML-in-Canvas

<strong>HTML-in-Canvas</strong> opens up a fascinating world of possibilities. The <canvas> element allows you to draw graphics using JavaScript. But what if you could render HTML elements directly onto the canvas? While you can't directly embed HTML into a <canvas> element in the traditional sense, there are techniques to achieve a similar effect.

One approach involves using <foreignObject> within an <svg> element, and then rendering the <svg> onto the canvas. The <foreignObject> element allows you to embed foreign XML namespaces (like HTML) into an SVG. This is one of the <strong>latest tech trends</strong> that allows to render interactive elements that are not natively supported on canvas.

Here's a basic outline of the process:

  1. Create an SVG with a <foreignObject>: Define an SVG element and include a <foreignObject> element inside it. Within the <foreignObject>, you can include your HTML content.
  2. Serialize the SVG: Convert the SVG element into a string using XMLSerializer.
  3. Draw the SVG onto the Canvas: Create an <img> element, set its src attribute to a data URI containing the serialized SVG, and then draw the image onto the canvas using drawImage().

Here's a simplified example:

const canvas = document.getElementById('myCanvas');
const ctx = canvas.getContext('2d');

const svg = `<svg xmlns="http://www.w3.org/2000/svg" width="200" height="100">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml" style="font-size:16px; color: blue;">
      Hello from HTML in Canvas!
    </div>
  </foreignObject>
</svg>`;

const img = new Image();
img.onload = () => {
  ctx.drawImage(img, 0, 0);
};
img.src = 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent(svg);

This technique allows you to leverage the power of HTML and CSS for creating complex and styled content within a canvas environment. It's particularly useful for creating interactive visualizations and games.

HTML is more than just static content. It's a dynamic and evolving language that continues to surprise and challenge even seasoned developers.
Information alert: Experimentation is key to mastering HTML. Don't be afraid to try new things and push the boundaries of what's possible.
Can I really crash a browser with an HTML zip bomb?

Yes, a carefully crafted HTML file with deeply nested entity references can consume excessive memory and potentially crash a browser. However, modern browsers have some built-in protections against this, so the effectiveness of an HTML zip bomb may vary. It's crucial to remember that creating and distributing such files is unethical and potentially illegal.

Why does WKHTMLTOPDF sometimes fail to render custom fonts?

WKHTMLTOPDF relies on WebKit to render HTML, and it can be sensitive to how fonts are referenced. Issues often arise from incorrect file paths, insufficient permissions, or unsupported font formats. Using absolute paths, ensuring proper permissions, and embedding fonts as base64 data URIs are common solutions.

Is it possible to completely replicate the Google CSE search bar's styling?

While you can get very close by inspecting the CSE's elements and recreating its CSS, achieving a perfect replica is difficult. Google may change the styling at any time, and there might be subtle differences that are hard to reproduce exactly. However, with careful observation and fine-tuning, you can create a very similar-looking search bar.

Source:
www.siwane.xyz
A special thanks to GEMINI and Jamal El Hizazi.

About the author

Jamal El Hizazi
Hello, I’m a digital content creator (Siwaneˣʸᶻ) with a passion for UI/UX design. I also blog about technology and science—learn more here.
Buy me a coffee ☕

Post a Comment