フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5
はじめに さいきんのWebはSPA技術を中心としたフロントエンドが賑わっていますね💪 従来サーバーサイドを扱っていた人もフロントを触る機会が増えていたり、これからプログラミングを学んでいく人も、フロントエンド領域に興味を持っているのではと思います。 そこで、フロントエンドの経験が浅い方や初学者向けに、おすすめのドキュメントや勉強すべき領域をまとめました。 とりあえず動けば良い段階から一歩進んで、フロントエンドエンジニアとして、良いアプリケーションを作るために必要な知識を浅く広く紹介します。 ※補足 新米と表記しましたが、実際には新卒や未経験でなく、新卒2~3年目の若手フロントエンドエンジニアやフロント分野に苦手意識のあるバックエンドエンジニアの方を対象としています。 数日で目を通せるような内容ではないため、マイルストーンやスキルセットの一つの参考にして頂けると幸いです。 フロントエンド入
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
// Good: choose between two options as appropriate (see below). import * as ng from '@angular/core'; import {Foo} from './foo'; // Only when needed: default imports. import Button from 'Button'; // Sometimes needed to import libraries for their side effects: import 'jasmine'; import '@polymer/paper-button'; Import paths TypeScript code must use paths to import other TypeScript code. Paths may be r
開発環境にChromeを選ぶなら知っておきたい12のテクニック Photo by Morning Brew on Unsplash さて、何らかの理由で、開発ブラウザとしてChromeを選んだとします。次は、デベロッパーツールを開き、コードのデバッグを開始します。 Consoleパネルを開いてプログラムの出力を確認したり、Elementsパネルを開いてDOM要素のCSSコードを確認したりします。 でも、Chromeデベロッパーツールを本当に理解していますか？実は、パワフルだけど知られていない機能がたくさん用意されていて、開発効率を大幅に改善できるのです。 ここでは、最も便利な機能を紹介します。お役に立てたら嬉しいです。 ChromeのCommandメニューから始めましょう。ChromeのCommandメニューは、LinuxのShellのようなものです。コマンドを入力してChromeを操作で
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
エンジニアお茶会 2020/08/19 pastak.icon @pastak この発表のゴール 現代のウェブブラウザの目指している方向性について紹介する モダンブラウザで使える最新の面白便利APIを紹介する ちゃんと仕様に入りそうなもの(Googleの力技で…も含む) （前半の各ベンダの話はpastak.icon個人の見解を含みます） 次ではない フロントエンドなんでも相談室 前提知識のコーナー "WebAPI"とは何を指すのか、標準化について ECMAScript Ecma InternationalにてECMA-262という規格番号 ほぼLiving Standardという雰囲気もあるけど、年に1回タグが付く ES2020: ECMAScript® 2020 Language Specification 最新の様子: https://tc39.es/ecma262/ Array、Nu
ウェブの進化とウェブブラウザ開発の最前線
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます！次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね！ ウェブ以前のハイパーテキストの歴史も取り入れるべきでは？ ありがとうございます！おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
On the 11th of January 1982 twenty-two computer scientists met to discuss an issue with ‘computer mail’ (now known as email). Attendees included the guy who would create Sun Microsystems, the guy who made Zork, the NTP guy, and the guy who convinced the government to pay for Unix. The problem was simple: there were 455 hosts on the ARPANET and the situation was getting out of control. This issue w
ブラウザの作り方
リンク集 - Populating the page: how browsers work: https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work/ - How Browsers Work: Behind the scenes of modern web browsers: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ - Let's build a browser engine!: https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html/ - W3C: https://www.w3.org/ - WHATWG: https://html
あくまで有効日数はW3C仕様の名目上のステータスであり、参考情報にしか過ぎないわけですが、HTML5とそれよりも前に策定された(X)HTML仕様は、2018年3月に一斉に廃止され、HTML Review Draftと入れ替わるタイミングでHTML 5.1とHTML 5.2が同時に廃止されました。Second Editionを含んでいますが、HTML5シリーズがいずれも勧告から3年で廃止されているのは何とも興味深いところではあります。 また、古い話ですが、当時HTML5のEditorを務めていたHixieことIan Hickson氏が2008年に「HTML5の完成は2022年ごろになる」と発言していたことがありました（HTML5の完成は2022年！？ | Web標準Blog | ミツエーリンクス）。2012年にW3CとWHATWGのHTMLが分裂[1]し、結局今年になってWHATWG HTM
個人的なJavaScriptの情報収集の方法についてまとめてみます。 JSer.infoなどをやっているので、JavaScriptの情報については色々な情報源を見るようにしています。 JSer.infoの範囲の中での情報源については、次の記事でまとめています。 JSer.info 13周年: JavaScriptの情報源を整理する - JSer.info この記事では、少しスコープを広げてJavaScriptの情報収集についてまとめてみます。 かなりスコープが広がってしまうので、万人向けの方法ではなく、個人的な情報収集方法としてまとめています。 この記事では、膨大な情報の中から見つけるというアプローチをとっているので、人によって向き不向きがあると思います。 情報収集の方法 情報の元となる情報源はさまざまなサイトや人になると思います。 しかし、そのサイトや人ごとに見ていくというのはかなり大変
はじめに Web では古来より <img> タグを用いて画像を読み込んでいました. しかし <img> タグにはアスペクト比に関する情報を埋め込むための属性が用意されていません. そのため, ブラウザが画像をネットワークから fetch して読み込みが完了するまで, レスポンシブな img 要素の寸法を決定できず, ページにガタツキ (Layout Shift) が生じる問題がありました. この問題を解決するため以前より, アスペクト比を埋め込むための新たな属性の導入が提案されていました. しかし最近議論に動きがあり, 既存の属性を利用する方法が提案され, ブラウザに実装され始めています. ここでは問題の背景, 提案と議論の変遷, そして開発者が取るべき対応について紹介します. はじめに img タグと Layout Shift intrinsicsize 属性 intrinsicsize
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方
setTimeout は、指定された時間以降に指定されたコードを実行する JavaScript の API です。ブラウザでも Node.js でも広く使われているのですが、実装はまちまちで、色々と特殊な条件も多く、挙動を完璧に理解している人は少ないと思います。この記事では、そんな setTimeout を可能な限り深堀りしてみようと思います。 先に書いておきますが、ものすごくニッチで細かい話ばかり並びます。突然私が、ただ純粋に setTimeout について調べたくなったので、その結果をまとめただけのものです。普通に開発している人には必要のない情報が多くなるでしょう。この記事は基礎から setTimeout を学ぼう、という方には全然向かないと思います。 また、JavaScript のイベントループについてある程度理解していることを前提とします。その詳しい理解には、@PADAone さん
2021年になりましたね。 矢倉眞隆（myakura）です。ウェブ標準やブラウザに興味のあるウェブ開発者です。gihyo.jpでは2009年に「Web標準とその周辺技術の学び方」という連載をしていました。 今回は昨年の泉水さんに代わり、2021年のウェブ標準やブラウザの動向を占おうと思います。2020年は世界もブラウザもそれなりに大きな出来事がありましたので、2020年の動きをまずおさえ、そのうえで2021年はどうなるのかを考えてみました。 W3Cのプロセス改訂でLiving Standardライクな仕様の改訂が増えていく W3Cは2020年9月に、新しいプロセス文書と特許ポリシーを公開しました。 新しい文書プロセスはW3Cの組織の定義や標準化の流れ、意思決定などについて定めた文書です。ここ数年は毎年更新されていますが、2020年はこれまでと比べて最大級とプレスリリースでもうたわれています
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
「Web 技術解体新書」執筆について
「Web 技術解体新書」執筆について Intro 「Web 技術解体新書(Web Anatomia)」という書籍の執筆と、 zenn 上での販売についてアナウンスします。 各章を分割して執筆し公開していく予定です。 第一章: Origin 解体新書 Web 技術解体新書とは Web というものを正しく理解するために必要な知識や技術は日増しに増え、それに従い学ぶためのコストもかなり上がってきています。 一方で、多くの書籍や雑誌、 Web 上の記事、動画や音声コンテンツは充実しており、学ぶための手段もかなり広がっています。 しかし、 Web に関わる技術書籍の多くは、何らかのフレームワークの解説や、 JS/CSS などの特定技術、特定の非機能要件に特化したものが多く、(その括りの曖昧さ故) Web という括りで書かれたものはあまりありません。 あったとしても、多くは初心者向けなものが多く、ある
Intro ちょうどタコピーの原罪が流行ってるのでこのタイトルにしたけど結構気に入ってる。 d.potato4d.me この話を読んでの感想とここまで大きくなった Node.js の振り返りをしようと思う。 どんなプログラミング言語であってもみんなから使ってもらって開発者をハッピーにしたいと思ってる。ただ最初は良かったと思ってた機能がなんか古臭くなったり、他にクールな機能を持ったものが登場したことによって徐々に飽きられていき、最終的に他の言語に乗り換えられる。 まぁどんな言語も同じだと思う。C言語だって生まれた当初はすごくクールでみんなをハッピーにしてた。今丁度「戦うプログラマー」を読んでるが、C++が出てきて、周りのエンジニアが C++ を使おうとするシーンが出てくる。そこで、「あんなの使って何が良いんだ、Cで十分だろ」とWindows NT 開発リーダーのデーブカトラーが言ってたりする
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考リンク 色々なテスト事例 setTimeout を使うコンポーネントのテスト 補足: Storybook の story を使
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル
「とほほのWWW入門」管理人の杜甫々氏が、これまでの経歴と、「とほほのWWW入門」執筆時に気をつけていること、自身の趣味について話しました。全2回。 「とほほのWWW入門」管理人 杜甫々氏 杜甫々氏（以下、杜甫々）：どうも杜甫々です。「とほほのWWW入門」というやつを作っています。こういうところに出ることはあまりなくて、2022年の岡山のオープンセミナーも録画でやっていたので、こんなにたくさんの人の前でしゃべるのは初めてだったりします。 まずちょっと、おじさんの紹介をやっていきます。「とほほのWWW入門」の管理人です。1996年から始めたので、もう27年目に突入ですね。ハンドルネームは杜甫々です。途中で漢字を当てはめてみました。本名は違いますけどね。 広島生まれの広島在住です。もちろんカープファンです。2023年の観戦成績は6勝1敗で、けっこう良かったんじゃないかなと思っています。 次にイ
JavaScript を書いたことがある人ならば一度は使うであろう console.log ですが、この関数は思ったよりも厄介な性質を持っています。その性質を知らずに console.log を使うと、デバッグ時に大ハマリしてしまうことがあります。この記事では console.log の落とし穴についてお話します。 今回は Chrome に特化して解説しますが、Firefox や Safari でも同じ落とし穴があります。 console.log とは まずはさらっと基本をおさらいしましょう。 大前提なのですが、console.log は JavaScript の言語仕様（ECMAScript）で定義されていません。ブラウザ向けには whatwg の仕様がありますが、あくまでもそれはブラウザ向けの仕様であり、Node.js を含むほぼ全ての JavaScript 環境で使えるのは cons
HTML標準仕様の策定についてW3CとWHATWGが合意発表。今後はWHATWGのリビングスタンダードが唯一のHTML標準仕様に
HTML標準仕様の策定についてW3CとWHATWGが合意発表。今後はWHATWGのリビングスタンダードが唯一のHTML標準仕様に W3CとWHATWGは、HTML標準仕様の策定について合意したことを発表しました。 いわゆるHTML5と呼ばれるHTMLの最新仕様には、WHATWGが公開しているものとW3Cが公開しているものが併存しており、しかも両者には一部で異なる仕様があったために混乱を招いているところがありました。 今回の合意によりW3CはHTMLとDOMに関する標準策定をやめ、今後はWHATWGが策定するリビングスタンダードがHTMLとDOMの唯一の標準となります。 両者が合意した主な内容は下記となります。HTMLとDOMのリビングスタンダード、すなわちつねにアップデートされていく標準仕様はWHATWGがメンテナンスをし、W3Cはそれに協力していくこと、W3Cは今後単独でのHTMLとDO
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先順
わたしはページ内検索を普通に使いたい
以前にも少し書いたのですが、ウェブブラウザーで使えるページ内検索による体験が阻害されるのが本当にストレスで、その例を残しておこうと思います。 採用側の気持ちも分かりますので、どうなると皆が幸せになるのか分からないという種類のものなので困ったところです。 省略されたテキストoverflow: hiddenとtext-overflow: ellipsisまたは-webkit-line-clampによってテキストが省略された場合、その省略部分がページ内検索にヒットすると非常に探しづらいです。 特に、グリッドで区切られたアイテムが複数列・複数行で並んでいる際に顕著です。 以前の記事のとおり、わたしはYouTubeでよく遭遇します。 下記のデモは、1000個のアイテムを並べたものです。 このうち、「Red Rose」というワードは12個のアイテムに含まれています。 デモを開いて「Red Rose」で
const url = "https://fetch-api-normalization.deno.dev"; await fetch(url, { method: "PATCH" }); await fetch(url, { method: "patch" }); 実行すると、次のようなエラーを得るはずです。 PATCH を小文字で書いた際のエラーの一例 さて、どのような条件でこのエラーが発生するのでしょうか？これが意図されたものなのだとしたら、 GET や POST は大文字・小文字を無視してよくて PATCH は無視できない理由がなにかあるのでしょうか？以下でその理由を探ってみましょう。 いつエラーが発生するか このエラーは、 Fetch API を利用して外部の HTTP サーバーに対してリクエストを行う時に、 PATCH と書くべきところを patch と書いていると発生します。
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前々回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先
2021年3月31日付で Google を退職し、本日4月1日から Progate でエンジニアとして働くことにしました。*1 そこで、以下の３点について、つらつらと書いていって転職エントリとすることにします。 東京でGoogleのエンジニアとして働いた５年間 キャリアパスについての悩み プログラミング教育について期待すること もし他にも聞きたいことがあったらTwitterでリプでも飛ばしてください。答えられそうなことは答えるかもしれません。 東京でGoogleのエンジニアとして働いた５年間 僕は東京の Chrome チームで、 Service Worker という JavaScript の API を実装していました。 const reg = await navigator.serviceWorker.register('sw.js'); という JavaScript のコードを書いたと
はてなエンジニア Advent Calendar 2022 - Hatena Developer Blog の 2023/1/5 の記事です。 id:hogashi です。 目次 目次 3行 こういうやつ 仕様を眺める 追記1: おまけ 追記2: id="top" な要素があるときは？ 3行 a タグの href 属性に #top と書くと、クリックしてページの先頭にスクロールできる、という話をしているのを見て、 それって仕様なんだっけ、と思って調べたところ、 仕様でした こういうやつ クリックしてこのページの先頭にスクロールする <a href="#top">クリックしてこのページの先頭にスクロールする</a> 仕様を眺める MDN の a タグのページにちょろっと書いてあって、 HTML の仕様に定義されているよ、とある <a>: The Anchor element - HTML:
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
今年も GitHub のトレンドで 2021 年の JavaScript/TypeScript を振り返ります。去年の記事はこちらです。 — GitHub のトレンドで振り返る 2020 年の JavaScript | WEB EGG 集計方法 GitHub トレンドは過去の履歴を公式に提供していないため、非公式に集計されたデータを利用しています。 データソースはlarsbijl/trending_archiveを使用 去年はxiaobaiha/github-trending-historyを利用したが今年のデータは無かったので変更 日ごとにまとめた markdown になっており、remark で AST→ データ化しました 集計期間は 2021/01/01 から 2021/12/15 まで 対象言語はJavaScriptとTypeScriptのみ 集計後のデータはこちらのスプレッドシー
空のdiv要素について - uhyo/blog
昨日はこちらの記事に端を発する形で、空のdiv要素やspan要素は妥当なのかといった話題が見られました。 中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか？ - dskdこの記事は空のdiv要素やspan要素が妥当かどうかという疑問にHTML仕様の観点から考察を加える大変面白い記事です。記事の結論としては、“僕の結論としては「否」である。”としています。 しかし、いくらHTML仕様を読んだといっても、こういった議論には解釈が入りがちです（こちらの記事でも結論の前に“ここからは完全に僕の解釈として書く。”と明記されています）。 仕様なのに解釈を入れる必要があるのはどうなのと思いつつ、実はこの記事でこれから紹介するように、HTML仕様もなかなか曖昧に書かれており解釈が必要なのは仕方のないことです。 筆者はどちらかというと空のdivを肯定する考えを持っていたの
ヤフーのユーザー5,400万人から"同意"を得るための技術（HTML/CSS/JavaScript）
こんにちは。SWATチームの今谷と、LY会員サービス統括本部の木所です。 LINEとヤフーの会社合併に伴って、LINEヤフー株式会社が提供するサービスを利用するユーザーに「新プライバシーポリシーへの同意」をいただくためのモジュールを開発しました。本記事では、ヤフーのユーザー5,400万人から”同意”を得るための工夫について、実装上の不具合も交えてご紹介します。 なお、ご紹介する内容は、UIT × Bonfire Front-end Meetup #1 での発表が起点となっています。詳細についてより深く知りたい方は、発表資料 や Podcast をあわせてご参照ください。 会社合併と、新プライバシーポリシーのご案内 LINEとヤフー、それぞれで同意モジュールがあります。Web向けのほか、iOS・Androidアプリ向けにも提供しました。 Webの同意モジュールでは「Modal版」と「Ful
こんにちは。転職ドラフトでWebアプリケーションエンジニアをやっている@iwtnです。 転職ドラフトでは自社開発企業に特化したエージェントサービスを始めました。 agent.job-draft.jp そこでサービスの申し込みフォームを作ったのですが、その中に生年月日の入力がありました。 生年月日ということは日付の入力。 ブラウザの実装もリッチになってきて、デフォルトでinputタグの type="date" を使うだけでカレンダーまで表示されます。素晴らしいですね！ しかしこの実装の問題は多くの人が指摘しています。実際あまりよいUIとは言えません。 動作はバラバラ、特にスマホでは入力しにくい 実装はブラウザに依存します。なので統一したUIをユーザーに提供できません。 caniuse.com もちろん普段使っているブラウザで慣れていればそれがその人にとってのベストのUIにはなりえます。 しか
あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年と同じく、2022年のWebアクセシビリティに関連する出来事を振り返りつつ、2023年のWebアクセシビリティの展望について俯瞰していきたいと思います。 WCAG 2.2 2022年9月版のWCAG 2.2で、文書のステータスとしてはようやく勧告候補（Candidate Recommendation）にまでたどり着き、仕様文書として完成する勧告（Recommendation）が見えてきた…と思っていたところですが、12月になって達成基準4.1.1構文解析を削除するという話が急浮上してきました。 達成基準4.1.1がどういったものなのか、改めて振り返ってみましょう。この達成基準については、もとはWCAG 2.1（原文、参考日本語訳）と同じものであり、WCAG 2.0とも同一です。達成基準4.1.1は、マークアップ言語
液晶風の画面は決まった形をオン・オフするだけなので、canvas にコードで描くのは大変なだけで無駄が多い。かといってセグメントを1つ1つ画像にわけて座標指定で配置していくのも面倒くさい。 と考えていくと SVG を埋めこんで、SVG の要素を JS で操作するのが効率が良い。ワークフローとしては SVG の作成と JS の実装で綺麗に境界を作ることができる。 Inkscape Inkscape の良いところは以下の点 XML エディタが UI と連動している レイヤーやオブジェクトを選択すると該当箇所にエディタ上で跳べる 構造をコントロールしやすい 画像を編集するというより SVG の XML を編集するUIというイメージ Inkscape でオブジェクトに名前をつけると、svg 上では inkscape:label 属性に入る。これを利用して JS から操作すれば Inkscape で
なぜインライン要素・ブロック要素概念は依然として有用なのか：現代的なWeb制作への適用 https://zenn.dev/coedo/articles/html-css-inline-element-block-level-element この記事では、『なぜインライン要素・ブロック要素概念は依然として有用なのか』という記事（以下「元記事」といいます）の説明について見ていきます。 この記事の対象者 この記事は、ウェブ制作を学んでいる人や、「インライン要素」「ブロック要素」という用語の扱いに困っている人を想定しています。 はじめに： 結論 この記事の結論は次の2つです。 今日のHTMLから「インライン要素」「ブロックレベル要素」という表記はなくなった。 ある要素にどのような要素を入れるのかは、「インライン要素」「ブロック要素」という考え方を使わなくてもできる。 詳しく説明したいと思います。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
どうしてHTML5が廃止されたのか | フューチャー技術ブログ
すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
Google TypeScript Style Guide
シニアフロントエンド開発者みたいにChromeデベロッパーツールを使おう - Qiita
XMLHttpRequest とはなんだったのか | blog.jxck.io
面白Web API 100連発 - pastak-pub
The History of the URL | The Cloudflare Blog
W3C発行のHTMLがすべて廃止された日 | フロントエンドBlog | ミツエーリンクス
私のJavaScriptの情報収集法 2024年版
画像による Layout Shift が無くなる Web がやって来る - mizdra's blog
JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー
setTimeout を完璧に理解する
2021年のウェブ標準とブラウザ | gihyo.jp
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
Node.js の原罪 - from scratch
Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io
PC-8801mkIISRで「漢字BASIC」を制作、大学の研究室ではApple IIを使用… 杜甫々氏が「とほほのWWW入門」を開設するまで
Chrome の console.log でハマらないために
JavaScriptの非同期処理をじっくり理解する (2) Promise
Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる
JavaScriptの非同期処理をじっくり理解する (3) async/await
Google のエンジニアを辞めて Progate を始めます。 - 知見（・・）！
aタグで#topにリンクするとページ先頭にスクロールするのは仕様 - hogashi.*
RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
GitHubのトレンドで振り返る2021年のJavaScript/TypeScript
最速の生年月日入力フォームを求めて - LIVESENSE ENGINEER BLOG
2023年のWebアクセシビリティ | gihyo.jp
JS+SVGで液晶画面風の表示をつくる | tech - 氾濫原
『なぜインライン要素・ブロック要素概念は依然として有用なのか：現代的なWeb制作への適用』という記事について