コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

CSSにおいて疑似要素はコロン2つ、擬似クラスはコロン1つにすると良い

CSS

なんか混在しているものを見るので自分自身のためのまとめ。

TL;DR

  • 現状の疑似要素のスタンダードな仕様はコロン2つで書く
  • IE8などCSS2準拠のブラウザではコロン1つで定義されているが、多くがCSS3に対応している2021年時点では考えなくても良い要素

そもそも擬似クラスと疑似要素は

MDNの記述が適切なので引用

まずは疑似クラスについて

疑似クラスは、特定の状態にある要素を選択するセレクターです。たとえば、それらはそのタイプの最初の要素であるか、マウスポインターによってホバーされています。それらは、ドキュメントの一部にクラスを適用したかのように振る舞う傾向があり、マークアップの余分なクラスを削減し、より柔軟で保守可能なコードを提供するのに役立ちます。 - 疑似クラスと疑似要素 - ウェブ開発を学ぶ | MDN

そして疑似要素について

疑似要素は同様に動作しますが、既存の要素にクラスを適用するのではなく、まったく新しいHTML要素をマークアップに追加したかのように動作します - 疑似クラスと疑似要素 - ウェブ開発を学ぶ | MDN

擬似クラスは特定の状態において反応しスタイルがあたり、疑似要素は指定された条件でDOMが書き換わりスタイルがあたるイメージ。

過去経緯と切り分け

CSS1~2では疑似クラスと疑似要素は記述は切り分けて考えられておらず、:focus と :first-line のようにコロン1つの記法になっていた。 そのためIE8などはCSS2準拠の実装になっているため:beforeという形で疑似要素を利用していた。

しかしCSS3の Selectors Level 3 の Changes from CSS2 にて、以下の記述がある。

new pseudo-elements, and introduction of the "::" convention for pseudo-elements

また後続の解説で追加された経緯も記載があり

This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements. ( この::表記は、疑似クラスと疑似要素の区別を確立するために、現在のドキュメントで導入されています。 )

ということで、疑似クラスと疑似要素を切り分けるためにこのダブルコロンの記法が追加されたものかと思われる。

参考リンク

Microsoftがブラウザの機能としてIEでアクセスをしたらEdgeに転送してくれる仕組みを提供している

Tips

IE11対応が辛い、というときの一つの切り札として.

出典

Moving users to Microsoft Edge from Internet Explorer - Microsoft Edge Development | Microsoft Docs

どのような機能なのか

Microsoftの https://edge.microsoft.com/neededge/v1 にて、EdgeにリダイレクトしてほしいURLが管理されており、このURLをIE11で開くとブラウザ側でIEには非対応な旨の表記がされる。

リストへ追加してもらうには

出典元のページにもあるが、必要情報を記入して指定されたMicrosoftのメールアドレスへ連絡をすることで審査がされ登録されるとのこと。

参考リンク

Mixed contents の問題点と考え方をざっくりまとめる

考えるメモ

Mixed Contentsが指すものは何で、何が問題なのか。

MixedContents(混在コンテンツ)とは

MDNの説明が的確なので引用すると以下

ユーザが HTTPS を通じてページにアクセスすると、ユーザとウェブサーバとの接続は TLS で暗号化され、盗聴や中間者攻撃から保護されます。HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、混在コンテンツと呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。つまり、ページは安全ではありません。 -混在コンテンツ - ウェブセキュリティ | MDN

例えば、ページそのものがhttpsでやり取りされているが、その中のimgタグやsrcタグなどで指定されているURLがhttpであったりする場合がこれにあたる。

何が問題なのか

混合することによって誤認される

ひとつのページ内にhttpとhttpsが混在すると、ページ上はhttpsで通信しているため秘匿されていると思いきや、個々の要素の取得がhttpで通信していることでその通信で秘匿情報（ブラウザが通信時に等しくheaderに入れるような情報やcookieなど）が漏れ出してしまう危険があるため、「パッと見としては安心できそうだが実は安全ではない」という状態が作られてしまう。

そのため、各ブラウザはこの混在する状態が発生しないように対応をしており、それが副次的な問題となる。

目に見える問題としてのブラウザのブロック

各ブラウザ（Chrome,Firefox,Edge,Safari）はMixed Contentsとなる状態を現状許容をしていない。

そのためhttpsのページ内にhttpで記述されたものがあればそのコンテンツは取得できない、もしくは処理ができない状態となる。このため利用するユーザからすると一部の情報が見えない歯抜けの状態となり、コンテンツ提供として問題が発生する。

この状況を回避するためにやるべきこと

Mixed contentsは何度も記載したとおり、httpsのページにhttpに内容をソースとする記述があることが問題なので、ちゃんとページ内で利用するリソースに関してはちゃんとhttpsで統一することで回避できる。

参考リンク

GoogleAdManagerを無料で使う場合、1ヶ月あたりに表示できるインプレッションには上限がある

アドテク

知らなかったのでメモ。

出典

Terms & Conditions – DoubleClick for Publishers – Small Business

AdManagerの前進のDFPの利用規約

Using the Program, You are permitted to serve without charge up to (A) (i) 90 million impressions per month to non-video ad units if You are located in the United States of America, Canada, Australia, or New Zealand; (ii) 200 million impressions per month to non-video ad units if you are located in the Russian Federation, Slovakia, Czech Republic, Greece, Slovenia, Lithuania, Romania, Poland, Ukraine, Hungary, Croatia, Bosnia and Herzegovina, Cyprus, Kenya, Morocco, Estonia, Latvia, Bulgaria, Turkey, Lebanon, Israel, United Arab Emirates, Saudi Arabia, Egypt, South Africa, Mexico, Argentina, Chile, Columbia, Guatemala, Uruguay, Peru, India, Taiwan, Malaysia, Korea, Hong Kong, Indonesia, Pakistan, Thailand, Philippines, China, Vietnam, Bangladesh, or Sri Lanka; or (iii) 150 million impressions per month to non-video ad units if You are not located in any of the countries listed in the preceding clauses (i.e., clauses (A)(i) and (A)(ii)); and (B) 800,000 video advertisement impressions per month (collectively (A) and (B), "Impression Limits").

上の内容を噛み砕いて無償枠の話を読み解くと

ということになり、日本は一番最後のものに該当するので、1億5千万回までとなる。

関連リンク

metaタグの robotsで指定できる値に関してざっくりまとめる

SEO

仕様が単一にまとまっているものではないので、利用できるものをまとめる

検討するクローラー

今回焦点を当てるのは Google と Bing 。 YahooJapanはすでにGoogle検索を利用しているので今回は考慮しない。

出典

使えるもの

値 説明 Google Bing
all インデックスの登録に制限を設けない。既定値。 ○ ?
noindex 検索結果のインデックスに登録させない。 ○ ○
nofollow ページ内のリンク情報を辿らせない。（どういうことかは関連リンク参照） ○ ○
noarchive 検索結果にキャッシュ表示をさせない ○ ○
nosnippet 検索結果にてサムネイルやページのプレビューを生成させない ○ ○
max-snippet: [number] 検索結果にてテキストスニペットに使われる最大文字数をnumberに設定できる。0の場合はnosnipepetと同義、-1を指定すると特段リミットを設定しません。 ○ ○
max-image-preview: [setting] 検索結果のページプレビューサイズに関して設定をすることができる。 none が 画像プレビューを表示させない、 standard はデフォルトのサイズ、large はスタンダードと同等かそれ以上に大きいサイズをプレビュー表示させます。 ○ ○
max-video-preview: [number] 検索結果で動画を表示する際の最大秒数をnumberに設定できる。0を指定すると動画は使わず静止画となり、-1を指定すると制限は特にかけないことになる ○ ○
noodp Open Directory Projectに登録させない記述だが、プロジェクト自体が2017年に運用が停止しているのでGoogleでは意味のあるタグとして認識されなくなった。 - ○
nocache noarchiveと同義 - ○
none noindexとnofollowを同時指定（ noindex,nofollow )と同義 ○ -
notranslate 検索結果でこのページを翻訳させない ○ -
noimageindex 検索結果で指定されたページの画像をインデックスさせない ○ -
unavailable_after: [date/time] 検索結果に、date/timeで指定した日時以降は表示させない ○ -

書き方

標準的な記述方法は以下

<meta name="robots" content="noindex">

複数のものを指定したい場合は , で並べる

<meta name="robots" content="noindex,noarchive">

関連リンク

サーバーのリダイレクトとJavascriptのリダイレクトはGoogleの評価としては変わらないと考えられる

SEO

リダイレクトの仕方次第ではページ評価が下がるのでは、というところでそこに関する内容をまとめる

今回気にかけること

とあるページが移転したときにリダイレクトとして

  • サーバサイドのレスポンス（apacheやnginx）でのリダイレクト処理
  • JavaScriptによるリダイレクト処理 ( window.location.href('https;//example.com') のような記述）

この2つの方法において、Googleからの評価は同等であるか？ということ

Googleのドキュメントいわく

Googleに不正なリダイレクトに関しての記述がある

不正なリダイレクト  |  検索セントラル  |  Google Developers

その中に以下の記述がある

JavaScript を使用したリダイレクトが正当な行為にあたる場合もあります。たとえば、ユーザーのログイン後に内部ページにリダイレクトする場合は、JavaScript を使用しても問題ありません。JavaScript やその他のリダイレクト手法を使用したサイトが Google のガイドラインに沿っているかどうかを確認する際には、その目的を考慮してください。サイトの移転にあたっては 301 リダイレクトが最適ですが、ウェブサイトのサーバーにアクセスできない場合は、この目的で JavaScript によるリダイレクトを使用することもできます。

とのことで、明確に同列とは語られてはいないが、JavaScriptで対応することで不利になるような話は書いていない

ジョンミューラーいわく

Googleの検索周りの質問などに答えるジョンミューラーがQuestionに答える#AskGoogleWebmastersの動画内で問答があった。

www.youtube.com

上記の動画では

Can Google evergreen Chromium detect client-side Javascript redirects? I'm not able to submit GSC indexing request to pages tha have client-side JS redirect to a subscription page.

というchromium製のbotになったときにJSのリダイレクトは検知できるかという質問だったが、この中でサーバーのリダイレクトと同等に追跡できるとしている。

まとめ

ドキュメントとしての側面、Google側の案内としての側面からしてもサーバーリダイレクトの評価とJSでのリダイレクトの評価に差異がないような作りとして考えて問題がないと思われる

関連サイト

Asia/TokyoなどのTimeZoneの定義情報は現在IANAが管理している

Tips

Asia/Tokyo 等の文字列定義ってどこにあるのかを調べる。

出典/どこにあるか

IANA — Time Zone Database

上記のページに記載がある

The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules.

機械的に和訳すると以下

タイムゾーンデータベース（tzまたはzoneinfoと呼ばれることが多い）には、世界の代表的な多くの場所のローカルタイムの歴史を表すコードとデータが含まれています。このデータベースは定期的に更新され、タイムゾーンの境界、UTCオフセット、サマータイムのルールなど、政治的機関による変更を反映しています。

上記の出典ページに行くと、タイムゾーンデータが固められた圧縮ファイルがあり、その中に各タイムゾーンの定義情報が格納されている。

管理の定義

なお、管理をどのように行うかはRFCにまとまっている。

RFC 6557: Procedures for Maintaining the Time Zone Database

リストはどこを見るといいのか

ファイルの情報が一次ソースではあるが、wikipediaにリスト状で見れる形になっているので、探すときはこちらの方便利

List of tz database time zones - Wikipedia

関連リンク