HTML だけで Shadow DOM を構築するための宣言型 Shadow DOM
HTML だけで Shadow DOM を構築するための宣言型 Shadow DOM 2024.10.19 宣言型 Shadow DOM は `<template>` 要素を使用して Shadow DOM を構築する方法です。宣言型 Shadow DOM を使用することで、従来の JavaScript を使用した Shadow DOM の構築方法と比較して、サーバーサイドレンダリング（SSR）に対応しているため、パフォーマンスの向上や SEO 対策に期待されます。 Shadow DOM は Web Components を構成する 3 つの技術の 1 つです。Shadow DOM はコンポーネントのカプセル化を実現します。Shadow DOM で定義されたスタイルは Shadow DOM の外部に影響を与えず、また外部のスタイルの影響を受けません。 Shadow DOM は再利用可能なコン
htmz - a low power tool for html
=>htmz> a low power tool for html htmz is a minimalist HTML microframework for creating interactive and modular web user interfaces with the familiar simplicity of plain HTML. [GitHub] plain🍦 Use straight up HTML. No supersets. No hz- ng- hx- v- w- x-; no special attributes. No DSLs. No <custom-elements>. Just vanilla HTML. lightweight🪶 166 bytes in total. Zero dependencies. Zero JS bundles to l
SCRIPT 要素の変遷から触れる Web の進化 - Repro Tech Blog
はじめに こんにちは。Repro で Booster の開発をしている杉浦と申します。 最近は JavaScript の盛り上がりが凄いですね。今ではブラウザ内にとどまらず、サーバサイドでも活用される様になりました。 これには、言語仕様が整理されたり機能が強化されたり、非常に大きな発展があったという点が大きいです。 実は、言語としての JavaScript だけではなく、最近 HTML との境界インタフェースとしての JavaScript の仕様も最近かなり明確化されてきています。 自分も HTML5 の最初のあたりまでは把握していたのですが、Booster の開発に携わる中で久しぶりに確認したところ、随分と仕様が進化し複雑になっていました。 今回はそんな HTML 規格の変化部分の紹介と、過去からの HTML と JavaScript の流れを振り返る簡単なまとめです。 HTML 仕様と
Resumable な JavaScript フレームワーク Qwik を学ぶ | ドクセル
Frontend engineer @lapras_inc / TypeScript / Vue.js / Firebase / 元消防士
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
HTML Centricで行きたい私たち - LIFULL Creators Blog
LIFULLの中島です。 近頃、LIFULL HOME'Sのフロントエンド(ここではJavaScriptのみを焦点とします)もようやく進む道を見出し、そろそろ設計方針を一新しようと試みています。 今回はそれについて話したいと思います。 現在の私たちの課題感 私たちの管理する多くのレガシーコードはDOM操作ライブラリとしてjQueryを、UI設計の格子としてBackbone.Viewのような設計方式を導入しています。 (もちろんそうでないマイクロサービスも多くありますが) 具体的なコード例を示すことこんな感じになります let Slider = Backbone.View({ events: { '.next click': 'next', '.prev click': 'prev' }, next() { this.$(...).css({left: '111px'}); }, ... }
ECMAScript modules in browsers
ES modules are now available in browsers! They're in… Safari 10.1. Chrome 61. Firefox 60. Edge 16. <script type="module"> import { addTextToBody } from './utils.mjs'; addTextToBody('Modules are pretty cool.'); </script> // utils.mjs export function addTextToBody(text) { const div = document.createElement('div'); div.textContent = text; document.body.appendChild(div); } Live demo. All you need is t
Chrome DevToolsを用いたメルカリWebのパフォーマンス計測 - Mercari Engineering Blog
フロントエンドチームの @urahiroshi です。Mercari Advent Calendar 2018 12日目を担当します。 今年の8月から12月にかけて，メルカリ・メルペイのフロントエンドチーム有志で「超速！Webページ速度改善ガイド」の社内輪読会を行いました。 この本の中で，「推測するな，計測せよ」という言葉が紹介されていますが，今回の記事は，輪読会で学んだことのまとめとして，Chrome DevToolsを用いてメルカリWebのパフォーマンス計測と簡単な分析を行ったものです。 なお，現在メルカリWebのアーキテクチャを刷新するための開発が進んでいるため，ここで計測したパフォーマンスの値は大幅に変化していく可能性が高いです。アーキテクチャの刷新後に振り返って見られる楽しみが増えることも、この記事を書いた目的の一つです。 計測方法，環境 計測はGoogle Chrome 71.
Pixel-perfect rendering with devicePixelContentBox | Articles | web.dev
It has 3440 pixels in width and the display area is 79cm wide. That leads to a resolution of 110 DPI. Close to 96, but not quite. That is also the reason why a <div style="width: 1cm; height: 1cm"> will not exactly measure 1cm in size on most displays. Finally, dPR can also be affected by your browser's zoom feature. If you zoom in, the browser increases the reported dPR, causing everything to ren
WPTをChromeで実行してHTML5 APIを理解する - Qiita
WPTとは WPT (web-platform-tests)という、ブラウザを作っている人のためのテストスイートがある。これは、ブラウザがどう動くべきかを定義している様々なWeb標準を、各ブラウザが満たしていてるかを確認するためのテストなのだが、Webサイトを作っているWebデベロッパーが新しいWebのAPIをどう使ったらいいかを調べるときにも役立つと思う。 という話を、電車で横に座っていたとある人に話したら「じゃあ、やり方を(日本語で)紹介してくださいよ。」と言われたので、簡単に紹介したい。 手軽に試す 手軽に試したければ、https://w3c-test.org 以下にある目的のテストファイルを開くといい。 例えば、Service Worker Navigation Preloadのテストであれば https://w3c-test.org/service-workers/service
サイトのパフォーマンス改善で重要なクリティカル レンダリング パスについて | コリス
ブラウザがページを表示する際にサーバーからHTMLのレスポンスを受け取ると、スクリーンにピクセルが描画されるまでに多くのステップが必要になります。ブラウザがページの最初のペイントを実行するために必要とするこのシーケンスは「クリティカル レンダリング パス(Critical Rendering Path)」と呼ばれます。 クリティカル レンダリング パスを理解することで、サイトのパフォーマンスを改善するのに役立ちます。 Understanding the Critical Rendering Path 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 クリティカル レンダリング パス(Critical Rendering Path)には、6つの段階があります。 クリティカル レンダリング パスの6つの段階 01. DOMツリーの構築
Measure performance with the RAIL model | Articles | web.dev
Measure performance with the RAIL model Stay organized with collections Save and categorize content based on your preferences. RAIL is a user-centric performance model that provides a structure for thinking about performance. The model breaks down the user's experience into key actions (for example, tap, scroll, load) and helps you define performance goals for each of them. RAIL stands for four di
Shadow DOM v1でHTMLの内容と構造を分離する
近年ではウェブに対する要求が肥大化しており、それに対応してHTMLも複雑化してきています。しかし、もともとHTMLはウェブアプリを記述するための言語ではありません。大規模なウェブアプリを作成するとなると、様々な点で不都合が出てきてしまいます。特に、まとまった部品をコンポーネント化して扱う機能に欠けていました。このことが私たちを悩ませ、今まで多くの苦労を引き起こしていました。 でも、もう悩まなくてもよくなるかもしれません。HTMLをコンポーネント化する規格が生まれました。それがWeb Componentsです。 Web ComponentsとShadow DOM Web Componentsは次の4つの部分からなる規格です。 Templates Shadow DOM Custom Elements HTML Imports 今回は、このうちのShadow DOMに焦点を当てていきたいと思いま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webデザイン入門：HTMLとCSSの書き方をゼロから学ぼう