brタグにおいて、
<br>
<br />
という２つの書き方を見たことはないだろうか。
ニコ動とかだと後者をよく見かけます。
この２つはどう違うのでしょうか。
この２つ、HTML5においては、どちらを書いても動きます。
ではなぜ二種類あるんでしょう？
まず、 <br> は特殊なタグです。
これは、内側に何かを挟むことがないタグです。
<p>aaa</p>
このように、本来はタグで挟むのが一般的ですが、 <br>は単体で完結するタグです。
その上で、書き方が違うのはなぜでしょうか。
HTML5が今では当たり前ですが、HTMLにはいろんな種類がありました。
XHTMLと呼ばれるものがあり、そちらの仕様では、 <br />と書く必要がありました。
HTML5では互換性があるために、どちらも使えるということでした。
まさかの体調激崩し( ；∀；)
体調崩してる時に、他の人に頼ることが出来た。
なんとか体調戻ったこと？
かなりひどい症状だったけど、水はそこそこ取ったから、脱水症状は低めだった気がする。
そもそも体調崩したくない・・・てか体調崩した原因不明・・・
原因不明で体調崩したから、学びが薄い・・・
101.6kg
なんでこんなに増えた(＠_＠;)！？
HTMLのaタグで、hrefにJavaScriptを記述することが出来る。
<a href="javascript:window.location.href='https://www.google.com/'">google</a>
<a href="javascript:history.back()">戻る</a>
では、この2つのボタンに対して
これらの結果は？
検証はしましたが、結果の理由がわからないので、ご存じの方教えてくださると嬉しいです・・・！
ちなみに、Chromeのポップアップブロックは切りました。
aタグでJavaScriptを動かしたい。
onclickを使ってもいいが、hrefで動かしたい。
<span onclick="submit();">ボタン</span>
こんなふうに描けば、submitが動くが、
hrefを扱ってaタグでの挙動にしたい。
あるいは、デザインとか扱いの都合でaタグを使いたい。
しかし、通常のhrefの動きではこまり、JavaScriptを動かしたい。どうするか。
<a href="href="javascript:history.back()"></a>
こうかくと、aタグでもJavaScriptが動かせる。
かつ、aタグの扱いで処理が出来る。
「生産性アップの推しツール」
私は、ツールを導入するべきときって？って話をして、チャットツールとかについて話す予定。
少し主題と離れているかもですが、こんな話をします
4コマ漫画のネームっぽいものを作ってみることになったので、
その時どう作ったかのメモ。
てか絵も描けないし、マンガとかも書いたこと無いワタシになぜ依頼したし！！！
なので、表情とかは雑に描いてます。
とりあえず、ブログで培った話構成力と、
昔文芸部にいた頃のちからを頑張って使ってみた。
これから意識したことを書きますが、
マンガの端にある地の文っぽいやつ、なんて呼ぶかわからないので地の文って以下記述します。
特に、転結は最低でも意識。
そして、意識してみたら、だいたい以下のような流れが多かったです。
転を意識。
1コマ目と2コマ目をセットにして、
同じ内容で、より大きな3コマ目と4コマ目を作る。
2コマ目と4コマ目にオチがあるパターン。
あるいは、
1コマ目で起を描いて、
2,3コマ目で行動を描いて、
4コマ目で結果を書くパターン。
めっちゃ疲れた！
初体験だったから、悩まず雑に作ったからハイスピードで作れたけど、
これの質が良いかと言われたら知らない！！！
でも、出来ないし、定石を知らない人が変に悩んでも良いもの作れるとは限らないので、
スピード感持って頑張りました。
このブログでは発表しない予定ですが、いつか世に出た時は、どうなるか楽しみなのです。
プログラミング系の話でもいつかこういうの書いてみたいな……！
<script>
function xxx() {
return "x";
}
</script>
こんなふうにスクリプトタグに直接関数を書いた。
<script src="common.js"></script>
こんな感じにJavaScriptを別ファイルに書いていた場合、
common.jsと関数名が被る可能性があります。
すると、読み込み順によって動作が被る可能性があります。
それを避けたい。
common.js
const common = {
xxx() {
return "x";
}
}
このように書くことで、common.jsに書かれた関数を書く際は、
<span onclick="common.xxx();"></span>
このように、 common.を付けて呼び出すことになり、重複を避けやすくなります。
commonという変数は付けられなくなりますが、
関数名一つ一つにルールをつけるより意識することが減るので、良さそうですφ(･･
Aをクリックしたら、Bがおかしくなる！
こうなった時に、何も考えずに、
『Bがおかしくならないようにしよう』
この思考でコードを書く方がいます。 すると、Bにif文が付け足されるわけです
出来れば、
『なんでバグが出たのか』
『バグの原因を断つ』
でコードを見てほしいと思いました。
今回の想定ケースとしては、
Aのロジックが間違えていたので、本来ありえない値がBに飛ばされたというケースを想定して話しています。
もし、このような問題があったときにBに修正を加えるだけだと良くないと思いました。
根っこのバグは治ってないので、良くないことが起こります。
1. ロジック自体は問題なので、新たなバグの発生 2. if文によってコードが見にくくなる 3. 問題の関心事以外のコードが増える
今回『間違えたこと』をしているのはAなので、Aを修正したいですよね。
でも、問題が起こっているのはBです。
そのためにはどうしたらいいか。
『なんで』バグが起こったのだろう。
これを一瞬でも考えてくれるといいなと思いました。
『なんで』を考えた時に、Bが間違えたロジックを走らせていたなら、Bを直すべきです。
でも、問題が発生したからといって、発生した場所が原因とは限りません。
『なんで』と考えて、コードの流れを一度追ってみましょう。
すると、どこが原因か見つかるかもしれません。
原因を正しく直せば、先程あげた3つの問題も回避されます。
バグを見ると慌てがちですが、一度一呼吸おいて、問題を正しく捉える努力をしましょうφ(･･
