HTTP レスポンスステータスコードについて調べてみた

こんばんは、有村です。
今日はHTTP レスポンスステータスコードについて学んだので、メモとして残します!

そもそもHTTP レスポンスステータスコードとは。

HTTP レスポンスステータスコードは、特定の HTTP リクエストが正常に完了したかを示します。
レスポンスは情報レスポンス、成功レスポンス、リダイレクト、クライアントエラー、サーバーエラーの 5 つのクラスに分類されます。

だそうです。
引用元:https://developer.mozilla.org/ja/docs/Web/HTTP/Status

それぞれ、
100番台 … 情報レスポンス
200番台 … 成功レスポンス
300番台 … リダイレクト
400番台 … クライアントエラー
500番台 … サーバーエラー

その中から、よく見るな〜というものを簡単にかいつまんでみました。

200(OK)
リクエストが成功した。

301(Moved Permanently)
リクエストされたリソースのURIが変更された。

302(Found)
リクエストされたリソースのURIが一時的に変更された。

403(Forbidden)
クライアントにコンテンツのアクセス権がない。

404(Not Found)
リクエストされたリソースを発見できない。

500(Internal Server Error)
サーバ側で処理方法が分からない事態が発生した。

503(Service Unavailable)
サーバがメンテナンスや過負荷でダウンしているなど。

504(Gateway Timeout)
ゲートウェイとして動作するサーバが時間内にレスポンスを得られない。

番号と内容だけではなく、名前も覚えたほうがいいよ〜とのアドバイスをいただいたので、
それも含めて頭に叩き込みたいと思います!

それでは、きょうはこのへんで。

小ネタ2つ!transitionendと暗黙のsubmit

こんばんは、有村です。2ヶ月なにも書いてなかった。
MacBook Proを破格で譲ってもらったので、せめてMacを使って何かをせねば…とブログ書くことにしました(?)

今回は小ネタ2つ。

小ネタ1・transitionendってバブリングするんだ!?
親もアニメーションするし、子もアニメーションする、というコードを書いていました。
(だいぶ略してますが)

さらに、animation1には、アニメーションが終わったタイミングで発火するnanikasuruを仕込んでいます。

で、動かしてみると、なぜか意図しないタイミングでnanikasuruが実行されるんですよね。
なんでだ?どこだ?と調べると、ちょうどanimation2のアニメーションが終わった後でした。

animation2には何も仕込んでないのにな……と思ったものの、それがよくなかった!
なぜなら、transitionendはバブリングするから…!

つまり、animation2のtransitionendがバブリングしてanimation1まで伝わり、
animation1のtransitionendが発火してしまったということですね!

これを仕込まないといけなかった。ここにだいぶやられた。

小ネタ2・暗黙のsubmitってあったんだね!?
業務中、こんな相談を受けました。
「テキストボックスにフォーカスしたままEnterを押すと、なぜか戻る動作が発動してしまうんだけど…」
と。

こんな感じのコードでした。

name=”return”っていかにも。どうやらこれがsubmitされて、画面遷移が行われているらしい。
しかしJS周りで特にそこをいじっている様子もなく、なんでだろうと首をひねっていたところ、
「あれ、このページ以外でも、テキストボックスでEnter押したら勝手にsubmitしたことになってないか?」
と気付きました。

まさか…と思い、W3C周りを調べてみたところ、なんとこんな項目が。
暗黙のsubmit。

hitting the “enter” key while a text field

まさにこれじゃないか。

ユーザがテキストボックスに入力して、その後すぐEnterを押してsubmitが実行されれば、
ユーザビリティとして便利やん!ってお話だったのですね…。

なお、複数のsubmitボタンがあった場合、一番はじめに出てくるsubmitが実行されるらしい。
だからreturnが送られていたのか…。

私が最初からバグだと決めつけてしまっていたので、「それって仕様じゃないのか?」「他でもそうなのか?」と多角的に考える気持ちを忘れていました。
それに、それなりに長いことフロントエンドに携わっていても、「こういう仕様だったの!?」と気付かされることが多いです。

日々勉強!って感じで、ほんとおもしろいですね、フロントエンド!
それでは、きょうはこのへんで。

ボタン作成で失敗したこと

こんばんは、有村です。
新年度を迎えても、実装でうんうん唸ってます。いつになったら立派になれるんだろうか。

さて、今日は備忘録としてボタン作成で失敗したことを残しておきたいと思いまーす!

何に失敗したかというと、ボタンに当てるCSSの選択と、HTML側の構造です。
(全然まだ最適解だとは思ってないのですが)

簡単に要所だけ書きますが、私こんな感じのソースを書いてました。

やりたかったのは、ボタンの中身を天地中央にするということ。
最初はline-heigetとpaddingを使っていたのですが、font-sizeとの兼ね合いもあったりとかで、「それだと高さを意識してボタン作るのが若干面倒だなぁ…」と思い、上のような形に作り変えました。

flexだとalign-itemsがあるじゃないですか。
そりゃ使うじゃないですか。
そしたらですよ。
実機(iPhone)で見たら崩れてた。

具体的にどう崩れていたかというと、ボタンの文言が思いっきり左に寄ってました。
普段はchromeのエミュレータで実装しているので、全く気付かなかったんですよね…。

なんでー!?って調べてみたら、どうやらブラウザのデフォルトスタイルとdisplay: flex;が干渉し合っており、flexのほうが競り負けているようだと知りました…。
いやらしいのがchromeは問題なく見れるということ。まだ見れてないですけど、IE11も大丈夫らしい。Edgeはダメだとかなんとか。

そこで有村は色々考えました。

1. かつてのpadding方式に戻す。
paddingを駆使して高さを設定するのはやはり面倒では?
高さを設定したいなら素直にheigetを使うべきじゃないか?
よって却下。

2. ボタンってもともと天地中央だから何もしなくてよくない?
わざわざflexを使った理由は、それがbuttonだけではなく、aタグなど他の要素でも使用されるため。
よって、buttonのデフォルトスタイルに頼ればいいや〜が使えない。
これも却下。

3. buttonがダメならinputは?
そもそも試していないけども、inputは空要素なのでbeforeやafterが使えなかったり、小回りが効かない時点で却下。

4. HTMLとCSSを書き換える

みたいな。要は間にspanをかませる。
デメリットとしては、本来ひとつで完結するはずなのに、buttonとspan(場合によってはaとspanなども)のようにHTML側の記述が増えてしまうということ…
けれども、現時点ではこれ以上の策は無さそうだし、「ボタンを配置する時はspanもセットで」というルールがあればいい話なのかなと思ったので、この案を採用しました。

form系はどうも痒いところに手が届かない感がありますね…
いつか「そんな日もあったね〜www」という時代が来ればいいのですが。
ひとまず締めとしては、Appleさん早くなんとかして!!!!

それでは、きょうはこのへんで。

colgroupとcolの違いって?

こんばんは。有村です。
またご無沙汰してしまいました。ちゃんと仕事してます。

日々新たな発見というのはあるものですが、最近特に「あ〜そういえば知らないな〜」となっているのがtable
さらに言えば、colgroupとcolの違い。
テーブルレイアウト(笑)とか笑ったりしていましたが、よく考えたら私この子のことよく分かっていなかった。

colはcolgroupの子要素であるというのは大前提として…。
colは列の幅指定でよく使いますが、とあるソースを読んでいたら

という記述がありました。
そこで私は疑問に思ったのです。

と何が違うのか?と…。

というわけで調べました。

Q. colgroupって何してるの?
A. 列を「意味的なまとまり」としてグループ化している

意味的?どういうこと?というと…
たとえば前者、colgroupが2つに分かれている場合の例。

商品名 1月販売数 2月販売数
商品A 5 10
商品B 7 12

これを見ると、一番左の列は「商品名」、あとの2列は「月」を表していることが分かります。
つまり、列の意味として「商品名」「月」という2つのグループができているということです。
対して後者の例だと、

12月販売数 1月販売数 2月販売数
3 5 10
6 7 12

3列全てが「月」という同じものを表しているので、1つのグループにまとめられるという感じです。

ただ見た目を整えるだけであれば全てのcolを同じcolgroupに入れても実装できますが、
せまんてぃっくを意識するなら、tableもちゃんと構造が分かるように組まないといけないということですね!

それでは、今日はこのへんで。

strongをそれなりに真剣に考えてみた

こんばんは、有村です。
ぼーっとすることが増えてやばいなと思ってます。春だから?

さて今日は、みんな大好きstrongタグについて考えてみます!
WEBやっててstrong使ったことない人なんていないよね!ね!
さっそく始めます。

Q. 「重要」って、どこと比べて重要なの?
A. コンテンツ中の他の文章

我々の神、W3C様はこうおっしゃっています…

The strong element represents strong importance, seriousness, or urgency for its contents.

コンテンツの〜とか言われても、よく分からなかった有村。
私が引っかかっていたのは、この重要度が「ページ全体における重要度なのではないか?」と思っていたことです。
ページ全体における重要度になる = あっちこっちで使うと、一体どれが本当に重要なのかが分からなくなるのでは?と考えていたのです。

W3Cの資料など読んで、こう考えたら理解できました。

この場合、
「黒魔道士は、他のジョブより強い。」
という一文の中で、特に強いという部分に注目して欲しい!という意図だと思います。

では、この場合はどうでしょうか。

「黒魔道士は、他のジョブより強い。
最新のゲームが欲しい。」
前者は「強い」、後者は「最新のゲーム」という点が、これらの文で重要だと示していると思います。

つまり言い換えれば、「重要度」はそのコンテンツ = 親タグの中だけで有効になるということですね。
なので、他のコンテンツのstrongと比べて「どっちがより重要か」とか、レベルを競うようなものでもない。
もしレベルという話をするのであれば、strongのネストという使い方もありますが、それも同一コンテンツの中だけでのレベルになるのだと思います!

ということでおしまい。
それでは、きょうはこのへんで。

fieldsetとlegendタグ!

こんばんは、有村です。
トイレの芳香剤って、なんで設置からしばらくすると匂いしなくなるんでしょうね?鼻が慣れるんですかね?

さてトイレの話はどうでもよくて、今日のテーマは「fieldsetとlegendタグ」です。
legendって聞いたことなくて、「伝説のタグ…?昔話とかを囲むタグなんだろうか、なんて限定的な…」と思っていたのですが、全然違った。

論より証拠ということで、用法。

こんな感じ。
上の例だと、formの中に大きく分けて「アンケート」と「ユーザ情報」の2つの入力欄があります。
その2つの入力グループを「fieldset」はグルーピングしていて、「legend 」はそのグルーピングが何であるかを説明しています。dl、dt、ddのform版みたいなものでしょうか?

「おっ!じゃあinput系のまとまりはfieldsetで囲んでlegendつけとけばええんやな!」と思ったところ、ひとつ落とし穴が。
それは、「legendは、fieldsetの一番最初の子要素でなければいけない」という点です。
まぁ、グルーピングされた入力欄の途中に説明が出てくるデザインはそうそう無いとは思うのですが、場合によっては引っかかるポイントかも知れません。
が、fieldsetにおいてlegendは必須項目というわけではないので、もしそのようなデザインが出てきた場合は、div等で適宜対応は可能だと思います。

それにしてもlegendタグって名前かっこいいな。
それでは、きょうはこのへんで。

metaタグってなんだっけ?

こんばんは。有村です。
ここ最近仕事で心がけていることは、「全てを疑え」です。でも全てを疑うって実は難しいんですよね。

で、そんな中で、疑ってみたら実のところよく分かってなかったものがあったのですが。
そのモノの名は…metaタグ!
htmlやってたら絶対お世話になるタグなはずなんですけど、head内のフォーマットが決まった実装をしていると、気にする機会も少ないかもしれません。

Q.まずmetaタグってなに?
A.メタデータを指定するタグ。
そもそもメタとは…という話からなのですが(そっからかよ)
メタ = 情報についての情報を示すものです。
で、htmlにおけるメタの対象というと、情報 = htmlデータ(文書)を指すようです。つまり、一言で言うと「ページについての情報を指定するタグ」でいいのでしょうか?

Q.metaってどんなものがあるの?
A.ググれカス
というわけでMDNのmetaタグ説明ページから抜粋。
【viewport】
viewportの初期値を設定する。でviewportって何さと調べると、文書(html)の表示領域のことらしい。
表示領域?そんなんデバイス幅のことやんけ!と思ったけれどそうではなく、デバイスの中にキャンバスが1つ入っているイメージ。
そのキャンバスのサイズをwidthで設定したり、キャンバスとデバイスウィンドウとの比率をinitial-scaleで設定したりする。

【robots】
クローラがページを訪問時に行う操作を指定する。
noindex、noarchiveあたりが、刺さる人には刺さる設定かもと個人的に思います。
ポイントは、「協力的なrobotのみが指定に従う」という点ではないでしょうか。いくらこの設定をしても、必ずしもそれが実現できるとは限らない、ということですね。

【charset】
THEおまじないだと思います。知らないけれどとりあえず書いてる。しかしやっていることは単純明快で、ページで使用している文字エンコードを指定しています。
ポイントは、「ページの始めから1024バイト以内に記載しなければならない」という決まりがあることです。ページの文字集合を確認するまでに、最初の1024バイトしか確認をしないブラウザがあるからだそうで。

他にも、BOMとか文字エンコーディングとか、知ってそうでよく分かっていない項目がありますので、それも調べて記録を残したいです〜。

それでは、今日はこのへんで。

説明リストの落とし穴

こんばんは。有村です。
ちょっと最近情報過多で整理をしきれない、思考回路はショート寸前の私です。

それでは本題、今日のコードレビューで起こった出来事を書きます。

みたいなコードを書いていたんですけど。

イケメン「なんでdl使ったねん」
有村「色についての説明だからや」
イケメン「色、の部分はheadingのほうがええんちゃうか」
有村「なんでや」
イケメン「【色】っていう言葉自体の説明にはなってへんやろ、そもそも色って何の色やねん」
有村「あー」

イケメンの指摘としては、説明リストを使っているけれど、それは本当に「説明」として成立しているんですかね?ということでした。
具体的に言うと、「商品Aは赤」「商品Bは青」というのは、確かに何かの色について説明なのかも知れませんが、「色」が何を指しているのかは示されてはいません。
もしかしたら箱の色かも知れないし、商品本体の色なのかも知れません。
さらに言えば、「商品Aは赤」「商品Bは青」という部分も説明リストを用いて書いていましたが、商品Aそのものが赤という色そのものを定義しているわけではありません。
たとえば、

であれば、文書として説明が成り立ちます。「お届けする商品本体の色は、商品Aの本体の色が赤、商品Bの本体の色が青です」となるので。
要は、dtとddを文章として切り出したときに、正しく説明として成立するかを見ろということですね。

なので、説明として成り立っていないのであれば「説明リスト」よりも、「見出しとコンテンツ」という構成の方が適しているのではないか、というアドバイスだったのです。
というわけで、最終的にこんなコードになりました。

HTML5で定義リストから説明リストに変わったとはいえ、それが文章として成り立っているかどうかという観点を忘れてはいけないな、という勉強になりました。
説明リストになったというよりは、厳密な定義から説明レベルに緩和されたんだよ、くらいに捉えるのがいいかも知れない、とイケメンからのありがたいお言葉でした。

それでは今日はこのへんで。

navについて本気出して考えてみた

こんばんは。有村です。

さて今日はフロントエンドエンジニアらしく、HTMLのタグの使い方について考えた記録を残します。
そのタグとは…ずはりnav

navってなんですか?という内容をいま一度。MDNではこう書かれています。

ナビゲーション要素(

まぁ、ナビゲーションだからね。そうなるよね。

で、私も勘違いしていたことなんですけど、
navは1つしか使用してはならない、なんて決まりはないのです。
「主要な〜」とあるので、navはひとつしか使ってはならない!と思っていたのですが、そんなことはないのですね。
では逆になんでもかんでもnavにしていいのかというと、それも違う。

主要か主要じゃないか…いや、そもそもWEBにおける主要とは……と考え始めたら、HTMLの深い闇に飲み込まれそうです。
そこでひとつ目安にするとしたら、まずは「このリンク群はサイトにとって重要かどうか」を考えるのがよいのかなと思いました。
たとえば、通販サイトを制作していると仮定して…利用規約やプライバシーポリシーへのリンク群を、ユーザに踏んで欲しいかどうか。もちろん規約自体は重要っちゃ重要ですけど、うちに来たからには絶対見て!というコンテンツではないように見えます。
では、商品一覧やカテゴリリストへのリンク群はどうでしょうか。通販サイトであれば、もちろん商品がメインコンテンツだと思うので、リンクを踏んで見て行ってもらいたいと考える気がします。
navはグロナビに使われることが多いといいますが、グロナビの中に入っている内容って、一般的にはそのサイトの主要コンテンツですものね。そう考えれば納得。

そして、先ほど挙げたような利用規約やプライバシーポリシーは、主にfooterに配置されていることが多いです。
MDNなどの説明を見ると、このようなリンク集であったり、サイトの説明ページへのリンクだったりは、navではなくfooterで十分とされていました。(じゃあfooterの定義って何よと調べたら、ページの著作情報や関連リンクを置くところとされていた)

サイトによって何をnavにするかは迷いどころだと思いますが、今までただのリンク集にしていたところは、実はnavが適切だった!ってこともあるかも知れませんね。

それでは、今日はこの辺で。

jQuery勉強会

梅雨の時期は髪がうねるし、広がるし困るー。
でも、紫陽花は綺麗だし、少しずつ夏になる感は好き。

今日はjQuery勉強会での内容を。

「9マスの中で押したパネルの周りの色が反転。
すべての色が揃ったらクリア!!」な内容がこちら。

仕様は理解できても、全ての色が揃うように揃えるのは難しいですね。

今回出てきている「Toggle」系メソッドに関しても、もっと理解しなきゃだな。
それはまた、次の題材。