もうHTMLをXHTMLで書くことは推奨されないという話 | フロントエンドBlog | ミツエーリンクス
春です。入社式のニュースが流れてくる季節ですが、当社もこの4月に多くの新入社員を迎えることができました。 そんな若者について、そもそもXHTMLという単語は何だろうという反応をするかもしれない一方で、長らくHTMLと付き合ってきた人は、XHTMLについて複雑な想いを抱く方も多いだろうと思います。そんな往年のXHTML1時代を過ごしてきた方に改めてお伝えしたいことは、XHTML（HTML Standardでは正確にはXML構文）でHTMLを書くことが推奨されないことが仕様に明示されるようになるというものです。 これは、HTML Standardを管理しているGitHubにWarn that the XML syntax is not recommendedというプルリクエストが作成されたことによります。 このプルリクエストは、XML構文が記載されている14章に次のWarningを追加するとい
Web アプリケーションエンジニアのためのウェブアクセシビリティの基礎
Web アプリケーションエンジニアのためのウェブアクセシビリティの基礎 2023.02.18 ウェブアプリケーションエンジニアを対象に、アクセシビリティの対応について解説した記事。アクセシビリティを向上させるためには、正しいHTMLの書き方が必要である。HTML要素には、アクセシビリティに関する機能が元々備わっているため、適切なHTMLを選択し使用することが大切だ。複雑なUIの場合はWAI-ARIAを使用し、ARIA Authoring Practices Guideに基づき適切に実装する必要がある。UIライブラリ選びの際には、WAI-ARIAに従った実装を行っているかが基準の1つとなる。 この記事は、ウェブアプリケーションエンジニアとして仕事をされているほうを対象に書かれています。日々のウェブフロントエンドの開発の中で意識しておきたい基礎的な内容をメインに記載しています。 そのため、ここ
JavaScript の MIME タイプが `text/javascript` に統一されようとしている
現在、 JavaScript の MIME タイプは2006年4月に公開された RFC 4329(www.rfc-editor.org) にて text/javascript (OBSOLETE) application/javascript (COMMON) text/ecmascript (OBSOLETE) application/ecmascript (COMMON) の4つが定義されています。 この RFC 4329 では text/* の2つは OBSOLETE 扱いな一方で、 JavaScript を呼び出す HTML の仕様では HTML5 以降、 <script> 要素の type 属性を省略することが推奨 されたうえで、省略時の値は text/javascript である とされました。 このように RFC 側と HTML 側で矛盾が生じる事態が長い間続いています。 実
`<meta charset="UTF-8">` を書く必要性があるケースとデメリット
HTML 文書内に <meta charset="UTF-8"> を書いていますか? 書いているとしたら、その必要性を問われた時に理由を説明できますか? 実は私も勘違いしていた部分があり[1]、改めてまとめてみました。 <meta> による文字エンコーディング指定の歴史 Content-Type ヘッダーと <meta> の関係性と優先度 <meta> が必要なケース <meta> で文字エンコーディングを指定するデメリット <meta> による文字エンコーディング指定の歴史 § まず基本的なおさらいをします。<meta charset="UTF-8"> は HTML5 で登場した新しい記法で、 HTML4 以前は <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> などという長くて覚えにくい書き方をしてい
React17におけるuseEffectの破壊的変更を理解する
しばらく前、React 17 RCが発表されました。現行のReact 16に比べて、いくつかの破壊的変更がある一方、新機能が何もないというのが特徴です。Reactチームとしては、新機能が無いとはいえ、破壊的変更も少なくなっておりなるべく16から17へのアップデートを行なってほしいという考えのようです。 この記事では、React 17における破壊的変更のうち、useEffectのクリーンアップのタイミングに関する変更を取り上げます（以下は公式サイトから引用）。 In React 17, the effect cleanup function also runs asynchronously — for example, if the component is unmounting, the cleanup will run after the screen has been updated.
画像による Layout Shift が無くなる Web がやって来る - mizdra's blog
はじめに Web では古来より <img> タグを用いて画像を読み込んでいました. しかし <img> タグにはアスペクト比に関する情報を埋め込むための属性が用意されていません. そのため, ブラウザが画像をネットワークから fetch して読み込みが完了するまで, レスポンシブな img 要素の寸法を決定できず, ページにガタツキ (Layout Shift) が生じる問題がありました. この問題を解決するため以前より, アスペクト比を埋め込むための新たな属性の導入が提案されていました. しかし最近議論に動きがあり, 既存の属性を利用する方法が提案され, ブラウザに実装され始めています. ここでは問題の背景, 提案と議論の変遷, そして開発者が取るべき対応について紹介します. はじめに img タグと Layout Shift intrinsicsize 属性 intrinsicsize
GitHub Flavored Markdown は何であって何でないか - Qiita
のんびりしていたらこんなメンションをもらっていたので、ちょっとまとめてみようと思います。 そろそろ @tk0miya さんがアップしてくる頃。GFMはspecかっちりしてるんでしたっけ(markdown全く詳しくない — Aki Ariga (@chezou) February 1, 2020 かっちりしている? この記事を読んでいる皆さんは Markdown の歴史に精通していると思うので、古い部分はざっくり割愛してしまいますが、オリジナルの Markdown は かっちりしていない ことで有名なマークアップ言語です。 必要最低限のマークアップ要素は規定されていて HTML への変換ツールも完成していた Markdown ですが、マークアップ言語の言語仕様としては貧弱で、インデントのルールやインライン要素をネストしたときの挙動、空行の有無による解釈の違い、などなど、細かい部分のルールにつ
W3Cで現在公開されているHTMLとDOM仕様は将来廃止されます - 水底の血
まえがき W3C（とWHATWG）からの公式なアナウンスはまだ確認していませんが、何度目かに結成されるW3C HTML WorkingのDraft Charterと、このCharterから辿れるDRAFT Memorandum of Understanding Between W3C and WHATWG（Memorandumは日本語で覚書などと訳されるので、ここでも覚書と呼びます）がブログエントリーのタイトルのソースになります。もっとも、今確認できる覚書もドラフトですから、変更があるかもしれません。しかしながらURLで観測できるわけですから、大筋でW3CとWHATWGとの間で合意が取れているのではないかと推測します。あとは、覚書だけでなくCharterもドラフトということになっていますが、以下の文章では面倒なので省略します。最後にお約束ですが、このブログエントリーは「だいたいあってる」感
ページ内リンクの実装から考える、a要素のclickイベントとその振る舞い
この他に macOS の Chrome では、ShiftキーとMetaキーを併用することで、新しいタブで開きつつそのタブをアクティブにすることができました。 CSS によるスムーズスクロール ページ内リンクをクリックしたときのスクロールを、アニメーションによってスムーズにしたいということはよくあります。これは CSS のscroll-behaviorプロパティを使えば非常に簡単に実装できます。 body { scroll-behavior: smooth; } たったこれだけの宣言で、JavaScript を一切用いることなく、ページ内リンクをクリックしたときのスクロールにアニメーションが伴うようになります。また、ページ内リンクのクリックだけでなく、可視領域外にある要素がフォーカスされたときや、ページ内検索に一致したテキストがハイライトされたときなど、スクロールが伴う場面すべてに適用されま
Masato Kinugawa Security Blog: ユーザ入力を使った正規表現から生じるDOM based XSS
お久しぶりです＆あけましておめでとうございます。昨年はブログを書く時間をうまく作ることができず、あまり記事を書けませんでした。今年はできるだけ月に1回程度何か書いていきたいと思っています。今年もよろしくお願いします！ さて、ブログを書かなかった間にXSSからSQLインジェクションへ興味が移った、なんてことはありませんでしたので、今日もいつも通り大好きなXSSの話をしたいと思います！ 最近、正規表現にユーザ入力を使っていることに起因するDOM based XSSに連続して遭遇しました。あまり見慣れていない注意が必要な問題だと思うので、この記事では、見つけたもの2つがどのように生じたか、また、問題を起こさないためにどうすればよいかを紹介します。 そのうちの1つはLINEのBug Bounty Programを通じて報告した問題です。 賞金と、"LINE SECURITY BUG BOUNTY"
CSSになり損ねた言語たち | POSTD
TeXやMicrosoft Word、あるいはその他の汎用的なテキスト処理環境では簡単に実現できるような見た目に自分の文書を似せようと頑張る（文字どおり）無数の人たちに対して、 “悪いけど、うまくいかないよ” と繰り返し言い続けるのは、実際のところ、この1年間、私にとっては継続的な楽しみだった。- Marc Andreessen 1994年 Tim Berners-LeeによってHTMLが発表された1991年には、ページのスタイルを設定する方法はありませんでした。HTMLタグがどのように処理されるかはブラウザ次第で、多くの場合、ユーザの恣意的な入力が大きく影響しました。そうした事情から、ページがどのようなスタイルで処理されるかを”提案”するような標準的な方法を求める声が上がるようになりました。 しかし、CSSが導入されるのは5年先で、完全に実用化されるには10年の歳月を待たねばなりません。
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
ep22 AMP | mozaic.fm
Theme 第 22 回のテーマは AMP(Accelerated Mobile Pages) です。 今回は @ymotongpoo さんをお迎えして、 AMP の登場背景やそこから見える今の Web の問題点、導入や普及、今後の展望などをふまえ、 AMP が登場した意味、そして AMP が Web にもたらす影響などを通して 「今何がおこっているのか」と「これからどうなっていくのか」を議論しました。 Show Note Why AMP is Fast ampproject.org ampproject/amphtml github Waht is AMP? Why AMP is fast Publishers using AMP HTML AMP Cache AMP Cache AMP Cache Update Ping Format AMP Validator Chrome Dev
効果的なフォームをデザインする：構造、入力、ラベルおよびアクション | POSTD
画像の出典：form-ux-tips あなたのアプリやサイトを利用する人々にはある一定の目的があります。そしてその目的を達成するために フォームに 記入しなくてはならないことがよくあります。Webやアプリにおいてフォームは、ユーザにとって未だに最も重要な 種類の操作 であるからです。事実、フォームは目的を達成するまでの 過程における最後のステップ と見なされることも多いのです。 フォームは目的達成の手段にすぎません。迅速に混乱なく、ユーザがフォーム入力を完了させられるようにするべきです。 この記事では、ユーザビリティテスト、フィールドテスト、視線計測（アイトラッキング）、そしてユーザからの実際の不満の声に基づく実用的なガイドラインを紹介します。 フォームの構成要素 一般的にフォームは以下の5つの要素から構成されます。 構造 。フィールドの順番、ページの外観、各フィールドとの論理的な関連付け
青色リンクのその先に： クリック可能なものは見てわかるようにしよう
フラットデザインか否かにかかわらず、インタラクティブな要素は、クリック可能とわかる十分な手がかりを提供する必要がある。枠線、色、サイズ、一貫性、配置や、Web標準の遵守といった手がかりによってクリックできることを伝えれば、インタラクティブな要素の外観はそれにふさわしいものとなる。 Beyond Blue Links: Making Clickable Elements Recognizable by Hoa Loranger on March 8, 2015 日本語版2015年5月11日公開 Webの移動とは目的を達成するための手段であり、クリック1回1回が非常に重要なものになる。したがって、ページの、どのエリアが地の静的なコンテンツで、どのエリアがクリック可能かどうか（あるいはタップ可能か）は、ユーザーにわかるようになっている必要がある。 クリック可能な要素が一目瞭然であれば、何かが期待
モバイル フレンドリー アップデートを開始します
+1 ボタン 2 AMP 11 API 3 App Indexing 8 CAPTCHA 1 Chrome 2 First Click Free 1 Google アシスタント 1 Google ニュース 1 Google プレイス 2 Javascript 1 Lighthouse 4 Merchant Center 8 NoHacked 4 PageSpeed Insights 1 reCAPTCHA v3 1 Search Console 101 speed 1 イベント 25 ウェブマスターガイドライン 57 ウェブマスタークイズ 2 ウェブマスターツール 83 ウェブマスターフォーラム 10 オートコンプリート 1 お知らせ 69 クロールとインデックス 75 サイトクリニック 4 サイトマップ 15 しごと検索 1 スマートフォン 11 セーフブラウジング 5 セキュリティ 1
Google が言う 「モバイルフレンドリー」 とは？ モバイルフレンドリーテストツールで色々試してみた
Google が言う 「モバイルフレンドリー」 とは？ モバイルフレンドリーテストツールで色々試してみた Google がモバイル検索の順位決定時に 「モバイルフレンドリー」 かどうかを重要なシグナルとして利用すると発表したことに関連して、そもそも Google は何を根拠に 「モバイルフレンドリー」 かどうかを判断しているのか、という点について調べてみました。 先週ですが、Google が Official Google Webmaster Central Blog で、2015年 4月 21日 （米国時間） から、モバイル検索の順位決定時に、その Web サイトが 「モバイルフレンドリー」 かどうかを重要なシグナルとして利用すると発表しました。 Finding more mobile-friendly search results ： Official Google Webmaster
Googleがウェブマスター向けガイドライン更新、CSSやJavaScriptのクロールをブロックしないよう求める ::SEM R (#SEMR)
Googleがウェブマスター向けガイドライン更新、CSSやJavaScriptのクロールをブロックしないよう求める グーグルのインデクシングシステムがモダンブラウザのようにウェブをレンダリングに基づいたシステムに変更されたことで、そのレンダリングを行うために必要な CSS や JavaScript ファイルへもクローラ Googlebot がアクセスできるよう確認することをガイドラインに明記。意味もなく robots.txt でクロールを禁止すると、インデックスに問題が生じて自然検索順位に悪影響も。 公開日時：2014年10月28日 06:24 米Google は2014年10月27日、ウェブマスター向けガイドラインの「技術に関するガイドライン」を更新し、ウェブクローラが正しくサイトを認識するために CSS や JavaScript などのウェブレンダリングに関連するファイルも巡回できるよ
oEmbed APIの使い方まとめ！URLから埋め込みHTMLタグを作ろう！
oEmbedとは、埋め込み用コードを取得するためのシステム、統一規格です。TwitterやYoutube、Vimeoなどといった世界的に有名なwebサービスの各々がこのoEmbedの規格を採用しています。 統一規格ってどういうこと？統一規格があることで、web開発者はoEmbedの仕様だけを知っておけば、「個別に各サービスの仕様を調べる」といった学習コストをかけることなく、様々なサービスの埋め込み用コンテンツを利用することができるわけです。 2014年9月には日本で人気のブログサービスはてなブログが、このoEmbedの規格を採用して、ブログ記事の埋め込み用コードを取得するAPIを公開しました。採用するサービスが増えれば増えるほど、web開発者にとって好ましい環境が整っていくというわけですね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゼロから始めるアクセシビリティ 「Backlog」の事例に学ぶ、ユーザーのための改善とは | イベント・セミナー
