Web制作者なら絶対押さえたい、HTML 5.1勧告で生き残った新機能7つ
11月1日にW3Cから勧告されたHTML 5.1。およそ2年ぶりのアップデートでどこが変わったのか？ 主要な変更点を押さえておきましょう。 HTML 5.1とは 2年ほど前のHTML5スタンダードのリリースは、Web開発界隈における大きな出来事でした。一連のすばらしい新機能が搭載されただけでなく、1999年のHTML 4.01リリース以降初のメジャーアップデートでもあったからです。「モダンな」HTML 5スタンダードを意気揚々と使ったWebサイトをいまでも見かけることがあります。 幸い、HTMLの次のアップデートまでそう長くはかかりませんでした。2015年10月、W3CはHTML5で未解決となっていたいくつかの問題の修復を目的としたHTML 5.1ドラフトの策定に着手しました。多くのアップデートを経て2016年6月に「勧告候補（Candidate Recommendation）」、2016
Re: h1要素は複数回使って良いのか!? HTML5.1に関するW3CとWHATWGの主張の違い
2016年12月21日 著 忙しさにかまけているうち、すっかり投稿のタイミングを逃してしまって、既に旧聞に属する話ではあるけれど、少し前に話題になったh1要素は複数回使って良いのか!? HTML5.1に関するW3CとWHATWGの主張の違い - Togetterまとめについて、アクセシビリティおじさんとして反応しておきたい。 各所で指摘されている通り、h1要素を複数回使うことについて、是か非かでいえば明確に「是」ですね。W3Cの策定する「HTML5」を使おうと、WHATWGの策定する「HTML Standard」を使おうと。ちなみにSEO上でも問題ないらしい。従い、この話題で論じられるべきは、アウトラインアルゴリズムを前提として見出し要素をマークアップすべきか否かでしょう。HTML 5.1の4.3.10.1. Creating an outlineには、以下の注記があります： There
HTML 5.1で変更されたsection要素の使い方、header要素とfooter要素のネストについて解説
2016年11月1日に、HTML 5.1が勧告されました。HTML 5から新しく加えられた点、削除された点、変更された点がいろいろあります。 その中から、ページのアウトラインを組み立てる上で重要なsection要素の使い方、header要素とfooter要素のネストについて具体的な事例を添えて紹介します。 Document Outlines in HTML 5.1 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 私は以前、HTMLのページにvalidなアウトラインを持つ重要性について説明しました。 先日、HTML 5.1が公式にリリースされました。 興味深い変更が数多くあり、そのうちの2つはvalidなアウトラインに関係しています。 削除 アウトラインを作成するh1要素を入れ、ネストされたsection要素の使用。 変更 hea
HTMLチェッカーはchecker.html5.orgを推してみたい - 水底の血
次の3つのチェッカーについて、 Validator.nu Living Validator https://validator.nu/ Nu Html Checker https://validator.w3.org/nu/ Nu Html Checker https://checker.html5.org/ 次のHTMLコードを投入して比較してみたよという話。 <!DOCTYPE html> <html> <head> <title>Test</title> </head> <body> <!-- dlの中のdivは現時点のHTML 5.2に規定されない --> <dl> <div> <dt> Last modified time </dt> <dd> 2004-12-23T23:33Z </dd> </div> <div> <dt> Recommended update interva
[JavaScript]HTML5 Form Validationの制御と注意事項
概要 HTML5から支援しているForm Validation、皆さんご存知ですよね。 非常に便利ですし、自分もHTML5に感謝しています。👏 サーバでは常にデータを検証するべきですが、追加のデータ検証をWebページ自身で行うことにも多くの利点があります。ユーザがフォームに入力している間にデータを検証することで、ユーザは何らかのミスをしたことを直ちに知ることができます。これはユーザが HTTP のレスポンスを待つ時間を減らし、またサーバで誤ったフォーム入力を扱うことがないようにします。 詳しい内容は以下の記事をご参考してください。 🔗[JavaScript]HTML5 Form Validation しかし、ドンー (OA O; ) ブラウザー別にメッセージが統一されず、実際の案件には、デメリットになっちゃったんです。 やっぱりHTML5 Form Validationに完全に依存され
![[JavaScript]HTML5 Form Validationの制御と注意事項](https://cdn-ak-scissors.b.st-hatena.com/image/square/12de11151f7e2bf7c001fafd74d9114194f6c4f2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCSmF2YVNjcmlwdCU1REhUTUw1JTIwRm9ybSUyMFZhbGlkYXRpb24lRTMlODElQUUlRTUlODglQjYlRTUlQkUlQTElRTMlODElQTglRTYlQjMlQTglRTYlODQlOEYlRTQlQkElOEIlRTklQTAlODUmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTU4MDFhZWQ4YjVkNDlmNzRiZTUxNjA2MWU5MWFlOWYz%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBsZWVkb2h5dW5nLWRiYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDc2YjkyMzZlYmQ1NjRjODA2MGUzZDk3MjdmZWM5MGE%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-RnVzaWM%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D10aaa24c7d20618d84a87203a8f6263b)
HTML 5.1 が今年 9月の勧告に向けて勧告候補への移行検討段階へ、HTML 5.2 の策定も開始
今年 4月6日に 「Working on HTML5.1 - W3C Blog」 というエントリーが W3C 公式 Blog に投稿され、2016年 9月には HTML 5.1 を勧告として公開する計画がアナウンスされましたが、これに関連して先週末、下記の通り、現在最新の HTML 5.1 Working Draft を勧告候補（CR - Candidate Recommendation） に移行する提案（CFC - Call For Consensus）がされた旨、公式 Blog にてアナウンスされました。 Finishing HTML5.1 ... and starting HTML 5.2 ： W3C Blog 元々、HTML5 の勧告スケジュールとして公開されていた 「Plan 2014」 内で、HTML 5.1 については 2016年第4四半期 （2016 Q4） に勧告というス
HTML5のセクショニング・コンテンツについて知っておくべきこと
この記事は、スマートフォン時代のWebコーディングスクール のスライドの一部を再構成した記事です。 この記事ではHTML5以降の「セクショニング・コンテンツ」に絞って書いています。 HTML5以降で一般的なWebページをマークアップしようとした際、セクショニング・コンテンツへの理解は不可欠であると私は考えています。 セクショニング・コンテンツとは まず「セクション」とは「区分、節、（会社などの）部門」のことを指します。 要するに「区切り」のことです。 セクショニング・コンテンツは「見出しやフッターの範囲を定義する コンテンツ」のことで、潜在的に見出しとアウトラインを持っています。 これまでのHTMLだと何が問題？ 上の図はスライド資料のため、「記事小見出し」の下にあるはずの本文や、サイドバー内にある要素は省略しています。 例えばこのような場合だと、人間にはどこからどこまでが本文でどこがサイ
今どきの入力フォームはこう書く！ HTMLコーダーがおさえるべきinputタグの書き方まとめ - ICS MEDIA
みなさん、入力フォームを制作する際、どのような施策をおこなっていますか？ 入力項目を見直したり、入力ステップを明確にしたりなど、入力フォーム最適化をおこなっていると思います。そのことで、コンバージョン率があがったり、ユーザーがストレスを感じないようになるでしょう。入力フォーム最適化はEFO対策 = Entry Form Optimizationとも呼ばれます。 サイトの設計段階で検討すべきことが多いですが、コーディングでも考慮すべき事が多々あります。今回はHTMLコーダーがエントリーフォームを制作する際に考慮すべき点について紹介します。 ※本記事では最近のブラウザに適したHTMLコーディング方法の紹介を目的としています。そのため、デザインとアクシビリティーでのベストプラクティスを紹介したものではありませんのでご了承ください。 自動入力機能に対応しよう Google Chrome（デスクトッ
マークアップのいらない未来を考える
みなさん、マークアップ好きですか？ 私はまあまあ好きです。デザインされたパーツをHTMLでどう組むかを考えたり、他の開発者と意見を戦わせたりするのは楽しいですよね！ ただ、自分はマークアップ行為そのものについて、「ここにそんな拘る意味あるのかな？」と疑ってしまうことがあります。<dl> を使うか使わないか、とか、パンくずナビはどうマークアップするか、とか、少しでも良いマークアップをするために切磋琢磨するのはきっと楽しいことなのでしょうが、エンジニアとしての自己満足に陥ってはいないだろうか？ と我に返る時があるのですよね。その時の感情を掘り下げてみようと思ったことが、この記事を書くきっかけとなりました。 この記事で私が最終的に述べたいことは、近い将来の標準的なWebプロジェクトにおいて、緻密なマークアップ作業の重要性は極めて低下するだろうということです。なぜ私がそう思うか、妄想を交えつつまと
HTMLフォームでのクレジットカード情報の自動入力について調べた - Qiita
「なぜ日本のウェブサイトでは1Passwordでクレジットカード番号を一発入力できないのか？」という素朴な疑問から、少し調べてみました。なお1Passwordはパスワード管理ソフトであり、またウェブサイトのフォームにパスワードやクレジットカード情報を一発入力するためのブラウザ拡張機能です。 クレジットカード番号入力フォームに関する標準を探したところ、IETFとWHATWGの取り組みを見つけることができました： Electronic Commerce Modeling Language (ECML), Version 2 Specification by IETF HTML Standard: 4.10.19.8 Autofill by WHATWG こういった標準に準拠することで、1Passwordのような支援技術(assistive technology)にフォームの「意味」(seman
AMP(Accelerated Mobile Pages) HTMLしてみたという話 / masuP.net
Googleさんが発表したモバイル端末での表示高速化のAMP HTMLに対応してみたよ、という話です。 Introducing the Accelerated Mobile Pages Project, for a faster, open mobile web 概要などは上記見てもらえれば感じはつかめると思いますし、日本語で紹介してる記事だとKenichi Suzukiさんの紹介記事を見ると分かるかと思います。 なぜやってみようかと思ったかというと、「javascriptが無い静的なHTMLとCSSのページは爆速で表示したるで！」というGoogleさんの粋な計らいかと勘違いし、ほとんどが静的なページであるこのブログもサクーっと対応できたりするんじゃね、と思ったからですが、ちょっと苦労しました。 なおブログを完全に対応させたのではなく、記事ページのみ別にAMP HTML用の記事を出力してい
meta keywordsについての定型文 - Qiita
<meta name="keywords" content="キーワード,キーワード,キーワード"> ただ現在はGoogle(Yahoo!)さんなども、meta keywordsは読んでいない。 クライアントに説明する時に、毎回リソースを探して文章を作るのもめんどうなので、定型文を用意した。 2009年に公式の声明がありましたが、meta keywordsは、現在GoogleとYahoo!の検索エンジンでは読まれていません。 またBingにおいては、keywordsが多く記述しているとスパム判定するようになっており、マイナスの要因にしか使われていません。 原文 参考に2009年に公開されたGoogle公式ブログとBingの記事を記載します。 「Official Google Webmaster Central Blog: Google does not use the keywords m
省略したＵＲＬをコピペしても完全なＵＲＬとして貼り付けられるようにするTwitterの心遣いがすごい - Qiita
これを、 コピペすると、 こうなる。 ・・・ ・・・なんでそんなことが起こるのかと色々考えたけど、調べてみると結局はTwitterの心遣いだった。 い・・・invisible！！！ いんびずぃぼぅ！！ ちょっと感動した。 見習おう。 【追記】jQueryプラグインにしました せっかくなのでjQueryのプラグインにしました。 ダウンロード jquery-twellipsis(Github) 実行サンプル sample(jsbin) Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do wit
もう逃げない。HTMLのviewportをちゃんと理解する
<meta name="viewport" content="width=device-width,initial-scale=1"> と呪文のように書いてきたが、いい加減ちゃんと整理して理解しよう。 いろいろ調査した結果、以下の考え方で理解できると思う。 まず、実際の液晶の解像度は一旦忘れろ。 <meta name="viewport" content="width=480">と指定したとする。 するとそこに幅480pxの仮想的なウインドウが作られる。幅480pxの液晶モニターがあることをイメージして欲しい。これをviewportと呼ぶ。 ブラウザはviewportにレンダリングする。viewportの中では、あたかも本当に480pxのモニターを使っているかのような環境になっている。なので、JSのdocument.documentElement.clientWidthなんかも480を返す
Webフォントを分割、というか削りたい - Archiva
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。 @font-face { font-family: "FontAwesome"; src: url('/font/fontawesome-webfont.eot'); /* IE9 Compat Modes */ src: url('/font/fontawesome-webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('/font/fontawesome-webfont.woff') format('woff'), /* Modern Browsers */ url('/font/f
HTMLのアウトライン意識してますか？ - QiitaのSEO事情（前編） - Qiita
「最近Qiitaを検索結果でよく見るようになったなぁ」と感じる人はいませんか？ SEOを頑張ってるWebサービスは数多存在しますが、Qiitaもその中の1つです。 SEOっていうとやれキーワードがどうだこうだ、サイト内リンクがどうだこうだ、という話になってしまいがちですが（そういうのが不要と言っているわけではないですよ）、今回はQiitaがSEOの一環として行なっている数多の取り組みの中で、比較的Web上での言及数の少ない印象のある、HTMLのマークアップについて、外に出せる範囲で、前編と後編に分けて解説したいと思います。 後編はこちら 免責事項的な SEOというのは完全に結果論でしか語ることのできないものです。また時と共に効果的とされるテクニックは変わっていきます。この記事はQiitaの中の人が「効果あるんちゃうか」と試行錯誤しながらあれこれ行なっていることの一部を紹介するものであって、
ワンランク上【謎】のアクセシビリティを確保するための18【嘘】のポイント
Web Accessibility Advent Calendar 2013(www.adventar.org) の8日目の記事です。 ウェブ制作におけるアクセシビリティについて、マークアップでのありがちなことなどを取り留めもなく書いていきたいと思います。 記事タイトルは釣りなので18もありません。あと、どこかで似たようなタイトルを見たことがあってもたぶん気のせいです。ゆるしてヒヤシンス。 代替テキストを書く キーボード操作に対応する 表の要約 WAI-ARIAを設定する 代替テキストについて思っていること 代替テキストを書く § 代替テキストは基本中の基本ながら「適切な代替テキストとは」を突き詰めるとW3Cの文書 がひとつできてしまうくらいには奥の深いものです。とくにHTML5では限定的ながらimg要素のalt属性が省略できるケースがあるなど[1]、文法的な変化も見られます。 ですが、従
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Masataka Yakura on Twitter: "BEMのmodifier (--) 入りのソースをコメントアウトしたらHTMLの構文に違反する問題に直面している。これどうエラー処理されるんだっけか……"
"This interface to HTML5 document checking is deprecated"
Form Inputs: The Browser Support Issue You Didn’t Know You Had — Smashing Magazine