- 投稿日：2019-12-04T21:55:20+09:00
onsenuiを利用してサイドバーを設置しましたが、iframeでMapを表示させるとサイドバーが閉じない
前提・実現したいこと
Monacaを利用して、Onsenui+javascriptにてアプリを制作しています。
サイドバーをで作成して、その中のアイテムを選択すると、googlemapをiframeで表示したいと考えいております。発生している問題・エラーメッセージ
サイドバー単体では動作は問題ないのですが、iframeを使用するとmap表示がされなくなります。
iframeを優先させるとサイドバーが閉じなくなります。該当のソースコード
<!DOCTYPE HTML> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no, viewport-fit=cover"> <meta http-equiv="Content-Security-Policy" content="default-src * data: gap: https://ssl.gstatic.com; style-src * 'unsafe-inline'; script-src * 'unsafe-inline' 'unsafe-eval'"> <script src="components/loader.js"></script> <script src="lib/onsenui/js/onsenui.min.js"></script> <link rel="stylesheet" href="components/loader.css"> <link rel="stylesheet" href="lib/onsenui/css/onsenui.css"> <link rel="stylesheet" href="lib/onsenui/css/onsen-css-components.css"> <link rel="stylesheet" href="css/style.css"> <script> window.fn = {}; //初期読み込み時のマップ表示 window.onload = function() { "use strict"; var url = "https://maps.google.co.jp/maps"; var param = { tokyo: { center: { lat: 35.681661, lng: 139.767185 } }, zoom: 18, lang: "ja" }; var name = "tokyo" var iframe = document.getElementById("ifr"); // パラメータ指定 var p = "?output=embed" + "&ll=" + param[name].center.lat.toString() + "," + param[name].center.lng.toString() + "&z=" + param.zoom.toString() + "&hl=" + param.lang; iframe.setAttribute("src", url + p); } window.fn.open = function() { var menu = document.getElementById('menu'); menu.open(); }; window.fn.load = function(page,name) { "use strict"; var url = "https://maps.google.co.jp/maps"; var param = { tokyo: { center: { lat: 35.681661, lng: 139.767185 } }, oosaka: { center: { lat: 34.702803, lng: 135.495908 } }, zoom: 18, lang: "ja" }; var content = document.getElementById('content'); var menu = document.getElementById('menu'); var iframe = document.getElementById("ifr"); // パラメータ指定 var p = "?output=embed" + "&ll=" + param[name].center.lat.toString() + "," + param[name].center.lng.toString() + "&z=" + param.zoom.toString() + "&hl=" + param.lang; iframe.setAttribute("src", url + p); //alert(url + p); content.load(page) .then(menu.close.bind(menu)); }; </script> </head> <body> <ons-page> <ons-toolbar> <div class="center">Map</div> </ons-toolbar> <ons-splitter> <ons-splitter-side id="menu" side="left" width="220px" collapse swipeable> <ons-page> <ons-list> <ons-list-item onclick="fn.load('map1.html','tokyo')" tappable> 東京駅 </ons-list-item> <ons-list-item onclick="fn.load('map2.html','oosaka')" tappable> 大阪駅 </ons-list-item> </ons-list> </ons-page> </ons-splitter-side> <ons-splitter-content id="content" page="map1.html"></ons-splitter-content> </ons-splitter> <template id="map1.html"> <ons-page> <ons-toolbar> <div class="left"> <ons-toolbar-button onclick="fn.open()"> <ons-icon icon="md-menu"></ons-icon> </ons-toolbar-button> </div> <div class="center"> 東京駅 </div> </ons-toolbar> <iframe id="ifr" width="100%" height="100%"></iframe> </ons-page> </template> <template id="map2.html"> <ons-page> <ons-toolbar> <div class="left"> <ons-toolbar-button onclick="fn.open()"> <ons-icon icon="md-menu"></ons-icon> </ons-toolbar-button> </div> <div class="center"> 大阪駅 </div> </ons-toolbar> <iframe id="ifr" width="100%" height="100%"></iframe> </ons-page> </template> </ons-page> </body> </html>試したこと
iframeのsrcに入れるデータをalertで表示させてみましたが、ちゃんと関数内で受け取れていました。
content.load(page) .then(menu.close.bind(menu));javascript内のcontent.loadのタイミングが一番悪さをしていそうですが、どう修正していいかわかりません。
よい方法を教えていただけますでしょうか？
お願い致します。使用
フレームワーク：onsenui
言語:HTML+CSS+javascript
- 投稿日：2019-12-04T21:20:08+09:00
Laravel6 ViewからControllerへ渡されたget/post データの取得の仕方 パターン整理
Laravelでviewからpost/get したデータをControllerで記述形式がいくつかあって、よくわからないので整理します。
とりあえず、思いつく限りでどんな記述形式がるか書き出してみます。
仮にview側でpostかgetでデータが送られたときに、3パターンくらい取得方法がある気がします。
記述形式はどれでもいいのかと思いきや、エラーではじかれる組み合わせがあるっぽいので整理します。形式は１個でいい気がするけど、どうしていくつもあるのでしょう？
たぶん、整理していくうちに分かるかもしれません。Controllerfunction example(Request $request){ $request->input('name'); $request->name; $request('name'); }例えば、View側からPOST形式でデータを渡した場合
View<form method="POST" action="/index"> <input type="text" name="name"> <input type="text" name="pass"> <input type="submit"> </form>コントローラー側で正しく動作する記述は
Controllerfunction example(Request $request){ $request->name; $request->input('name'); }の２つでした！
$request('name');
を使用すると
こんなエラーが出ちゃいました。次にget形式ではどうなるか調べてみます。
View<form method="GET" action="/index"> <input type="text" name="name"> <input type="text" name="pass"> <input type="submit"> </form>postの時と同じ結果になりました（笑）
ということは、単純に自分の勘違いで使えないコードを覚えてしまったようです。。
どうして、こんな勘違いをしていたのか？
それは２つの記述方法が、混同して記憶違いで直感的に書きやすい記述が刷り込まれてしまったからだと思います（言い訳）
結局、形式が２つある理由はよくわかりませんでした。
１つだけなら、勘違いすることもないのにと思いました。Laravelでは
ページ表示にview()とredirect()があって、
どちらを使うと便利なのかわからずにいます。redirect()は記述形式がroute()を使う場合と使わずに記述する方法があるので、
どれがどういうときに向いている記述なのか？
調べたいと思います以上、勘違いしていましたという記事になりました。
- 投稿日：2019-12-04T20:10:43+09:00
HTMLでバーコードリーダーを使用するときに便利なibisBrowserDXRの独自拡張
- 投稿日：2019-12-04T20:05:42+09:00
初心者によるプログラミング学習ログ 176日目
100日チャレンジの176日目
twitterの100日チャレンジ#タグ、#100DaysOfCode実施中です。
すでに100日超えましたが、継続。100日チャレンジは、ぱぺまぺの中ではプログラミングに限らず継続学習のために使っています。
176日目は
おはようございます
— ぱぺまぺ@webエンジニアを目指したい社畜 (@yudapinokio) December 3, 2019
176日目
webサイトコーディングの課題
オブジェクトの配置修正
flexの使い方#100DaysOfCode #駆け出しエンジニアと繋がりたい #早起きチャレンジ
- 投稿日：2019-12-04T18:20:27+09:00
(aKuad流?)文書作成の心得
ここは誰？あなたはどこ？
aKuad と申します。興味関心ごとやステータスをざっと挙げると･･･
- ハードウェア、ソフトウェア共に、コンピュータ系のことはほとんど好き。自作PCも興味、サーバ関係にも興味、業務用機材は無限に見ていられるくらい好き。オーディオにも興味。いつかスピーカー自作もしてみたい。
- 一番の好み・得意は、コーディング系のこと。これまでである程度いじくった言語は、「C, HTML & CSS & JavaScript, SHシェルスクリプト」。それから、一応「Arduino, HSP」も添えて。「C++」は、学校で勉強中(本記事投稿時)。触りだけなら、加えて「Java, Fortran, Ruby, Perl, Python」。最も付き合ったのはHTML周辺。GitHub.io でも Web ページ作成予定。ちなみに、今の所 GUI を構成する術は HTML & JavaScript のみ。そのうち OpenGL とかもやってみたい。
- ブログの執筆は初だが、好きに文を書くのは結構好み。ただ手書き耐性が低く、手書き原稿用紙を前にするとモチベガタ落ち。手書きレポートを要求されることがほとんど無い学科に入れて、心底嬉しく思っている。
･･･究極雑ななぐり書き説明ですが、aKuad とはこのような人物です。
さて、この記事ですが、自分流の文書作成について説明してみようかと思います。
「プログラミング関係のブログで、なぜ文書の話？」
『いえ、プログラミング関係 'だからこそ' 、文書の話です。』
私aKuadの経験を基に、「こうすると良さげなんじゃ？」と思った文書の書き方を説明致します。
ワープロでの文書作成に限った話ではありません。プレーンテキストファイルへの簡易メモでも、Webデザインでも活用できると思います。情報系エンジニアと文書の付き合い
エンジニア、特に情報系は、何かと文書との付き合いが多い、というより、文書との付き合いは避けては通れないハズ。
例えば、あなたが何か新しいライブラリを導入するとなったとき、何かサーバソフトを導入するとなったとき･･･。
検索をかけて、いろいろな解説サイトを見て回って、見様見真似で実装したり、比べてみたり、そして出てきたエラーや不具合を検索し･･･。
あらゆるページ、すなわち文書にお世話になることと思います。今まさに Qiita をご覧になっているそこのあなたも。そして、文書というのは、誰かが書いたから存在するもの。雑草じゃあるまいし、自生するものではありません。
自分で文書をまとめる機会も、きっと少なからず。誰かへの説明としてかもしれないし、自分への備忘録としてかもしれない文書を。「せっかく文書を書くなら、見やすく書きたい！」
そう思われた方の、少しの参考にでもなれれば幸いです。記事に進む前に･･･
ここに記載するのは、あくまでもaKuad流です。
「こうすると良い。」と断言するような言い方をしますが、科学的・論理的な証拠も何も用意していません。ほぼ全て僕のフィーリングです。
個人の感じ方によっては、何一つ使い物にならない書き方かもしれません。
なので、あくまでも「へぇ〜、こんな考えもあるんだなぁ〜。」程度に見て頂けると幸いです。
では、ようやく本題へ･･･。其の一 - '目的' と '対象' をハッキリすべし
日記のようにフリーダムに綴るものはちょっと例外だが、大抵の文書に関係。
文書は特定の目的を持って書かれるはずです。ハッキリしたことを書くはずの文書が、行き先不明では意味を成しません。
文書の初めに、指針を読者に示す「この文書は、誰のための何なのか。何から何までをまとめたものなのか。」を書きましょう。
タイトルの十数文字程度だけで目的を説明できるほどシンプルな内容だとしても、物事には導入がつきものです。明確な目的と内容の範囲.タイトル: Apache のインストールをするだけ Windows, Mac, Linux における、Apache のインストール手順です。 Apache の細かい設定についてはこの記事には書いていないので、別途 http...XXX... を参照基礎的な事項を踏まえての、より応用的な話である場合、前提としている技術レベルなんかを書けば、対象がハッキリするでしょう。
ハッキリとした対象.タイトル: 自作関数に配列を渡す方法 C言語のポインタが分かり、扱えることと、自作関数が作れることを前提に話を進めます。 ポインタについては http...XXX... 自作関数については http...YYY... を参照。ちょっとした体験談や備忘録なんかを書くときは、その文書を書いた背景を記録すべきでしょう。そのときの状況や環境なんかも忘れずに。
もしかすると、同じ状況にある人が記事を見て解決できるかも･･･！体験談サンプル.samba の設定でちょっと詰まってしまったのでメモ･･･。 簡易的なLANで、5人程度でファイル共有をしようとしたが、 クライアントからファイルの書き込みができるようにするために、ちょっと試行錯誤した話。 サーバマシンのOS: ･･･ クライアントマシンのOS: ･･･其のニ - '記号' と 'スペース' を活用すべし
技術関係の記事でも、案内ポスターでも、レポートでも、大抵の文書に関係。
記号を使う身近な例としては、箇条書きがあります。
口頭での説明とは違い、文字だと記号が使えます。活用しない手はありません。
例えば以下の文。口で話す、そのままの字幕のような文。見づらく、見栄えも良くありません。字幕のような綴り.マシンのCPUはRyzen7 3700X、メモリはDDR4 8GiBを二枚、グラボはRADEON RX 590、OSはUbuntu18.04です。「変数名と数値」のような形も、またいい感じ。
上記の文を、コロンとスペースを用いてまとめてみると･･･コロンとスペースで修正.マシンの構成は以下の通り。 CPU: Ryzen7 3700X メモリ: DDR4 8GiB × 2 グラボ: RADEON RX 590 OS: Ubuntu18.04ワープロソフトやWebページであれば、表を使ってまとめるのもヨシ。
また、プログラムで言うインデントは、文書でも有効。
一つの文書の内容において、何から何まで左端から文が始まっていてはなんだかパッとしません。
個人的には、箇条書きの左部分とかにインデントを入れるのも良きかと。それから、目立たせたい、あるいは目立たせるべき単語があれば、記号を使って装飾するのも一手。
ワープロソフトであれば、下線、太字、色の変更なんかを用いることでも可能。
プレーンテキストのように、フォント書式が設定できない状況では、記号での装飾は有効。例えば、ここの見出しのように。其の三 - 空き行や行間等、余白を作るべし
ワープロソフトやWebデザインなら、行間は確認必須。
プレーンテキストでは、空き行でカバー。今まさにご覧になっている Qiita の表示に注目してみると？
通常サイズの文と文の間は、およそ一文字分くらいも開いている。見出しの上は、見出しの文字一つ半が入るほどに開いているのがお分かり頂けるかと思います。
行間、重要です。僕の経験的には、行間も空き行も無しがずっと続いていると、読んでいてすさまじくストレスを感じます。
ものすごく極端な例を上げれば、「ソースコードからインデントと改行を全部抜くと修羅」って所でしょうか。ワープロソフトとかにおいては、デフォルトでも大体適当に行間が設けられているかと思います。
何か、今手元に適当な編集可能な文書(docx とか odt とか)があれば、行間を無し(行の高さを一文字ピッタシ)にしてみてください。
行間が文書の見栄えに大きく関わっていることに気づけることと思います。また、文のある程度の区切りごとに段落を設けるように、ちょくちょく空き行を作ると良いでしょう。この記事のような感じに。
ワープロソフトでならマージンの設定で充分ですが、プレーンテキストなら空き行必須です。
空き行、段落が無く、デカいブロックのような文字の塊では、読む気が失せます。少なくとも僕は。其の四 - 内容を適度に区切り、構造化すべし
気楽に綴る短い日記等はちょっと例外だが、ある程度のスケールの文書に関係。
ある程度のスケールがあるのであれば、見出し分けは必須。
必要なところだけもう一度読むとなったときなんかには、どこから読むべきかをすぐに見つけられます。スケールが非常に膨大、あるいはちょうど良く区切りれるのであれば、複数の文書に分割しても良いかもしれません。
(何かの仕様書だとか、分割すると不都合な場合は除きます。)
例えば、「Apache に関して、インストールのことと設定のこととで、別の記事に分割」というように。
ひとまず、単一の文書が肥満化するのは避けるべきでしょう。其の五 - 最低限、同一文書内では '書式を統一' すべし
全文書における話。
記号、空白、見出しを整理したとしても、部分によって書式がバラバラでは、逆効果です。
一つの箇条書き内の同レベルの項目において、項目ごとに別々の記号を使うだなんて、ポスターの飾り付けとかじゃなければ、普通しませんよね？
(複数レベルにまたいでいるならまだしも･･･)謎に記号を変えてみた箇条書き.* Debian - Ubuntu + LinuxMint第一見出しを「行の高さ 2文字、フォントサイズ 20px、ゴシック体、太字」としたら、全ての第一見出しはこの書式で統一。
ワープロソフトであれば、「スタイル」機能を用いることで、見出しの書式なんかを統一。
プレーンテキストで、記号を用いて見出しを目立たせているなら、見出しごとに記号を統一。プレーンテキストで見出し装飾.---[序章]--- このテキストファイルでは... ---[其の一 - '目的' と '対象' をハッキリすべし]--- 文書は特定の目的を持って･･･単語の強調に用いる記号を、例えば「""(ダブルクォート)」と決めたなら、全ての単語強調をこれで統一。
一部例外や別記号を導入するなら、そのルールを自分で決め、統一。表記ゆれも無くすべきでしょう。例えば、所々「ワープロソフト」だったり「ワープロ」だったりでは、文書の統一感が失われてしまいます。
略称で書くのか、略称ではなくフルで書くのかも同様です。
(口で喋るものではなく、ある程度考えて書く文なので、難しくはないはず。)言葉を略称で表記するのであれば、最初だけ略さず書き、以降略称を用いる断りを。
もしくは、「JDK とは、Java Development Kit のことで･･･。」略称を用いる断り.この記事では、Linux への「Java Development Kit」(以下「JDK」)のインストールについて説明します。ただ、略称の表記の方が完全に馴染みきって、略称でない表記の方が有名じゃなかったりするようであれば、わざわざ断らなくとも差し支え無いかと。
(例えば、「Slack」->「Searchable Log of All Conversation and Knowledge」)其の六 - 自分流を作り上げるべし
記事を読んで、ちょっと思い当たる節があったそこのあなたへ。
文書の書き方は、当然一つ限りではありません。各個人によって書きやすい、書きにくいは異なります。
自分のパフォーマンスをしっかりと発揮できる書き方を、自分なりに模索しましょう。
上達するには、何事も経験の積み重ねです。おしまいに
･･･以上、aKuad流の文書作成の心得でした。
もし、内容が気に入らなければ、この記事の存在を忘却して頂いても結構です。
結局の所、文書の書き方は十人十色ですので･･･。
- 投稿日：2019-12-04T17:42:09+09:00
困る前に知っておきたい SVGの基本再解釈
はじめに
アイコンやロゴなどで使用されることが多いSVGですが、よくわからずにとりあえずで使ってしまうと意外なところでハマってしまったりします。
SVGをソースレベルで解釈しつつ、現状で自分なりにベストな使用方法を探っていきます。対象
SVGってあれでしょ？よく知らないけど
- 拡大しても画像が綺麗なやつ
- ちょっと使ってみたけど挙動がよくわからないやつ
- ぱっと見でコードがごちゃごちゃしてて何やってるかよくわからないので、結局JPGとかPNGにしちゃうやつ
このくらいの人を対象に想定して書いています。
「アニメーションとかパーツごとにごりごり動かしたりはしないけど、CSSでアイコンの色を変えたりレスポンシブに対応させたりはしたいなー」くらいな感じで使用していくときの前提知識として読んでいただけると幸いです。「SVGチョットデキル」という人はまとめまで飛んでいただくと良いかと思います。
そもそもSVGを使うメリットって？
以下のようなボタンコンポーネントを例に確認していきます。
拡大しても画像が綺麗
PNGやJPGはラスターグラフィックスであり、SVGはベクターグラフィックスであるというところがキーワードになります。
ピクセルごとに色を割り振るラスターグラフィックスに対し、ベクターグラフィックスは「どの座標からどこまで線を引く」というパスから描画を行うため、拡大してもピクセル単位の荒れが出ません。
PNG（ラスターグラフィックス）
SVG（ベクターグラフィックス）
データ容量が比較的小さい
SVGはパスと座標のデータが大部分のテキストデータですので、データ容量が比較的小さく済みます。またテキストエディターで開き、編集することも可能です。
アイコンやロゴなどは線や色の規則性がコードで表現しやすいため、SVGでの使用に向いていますが、色や線が複雑な写真などを表示するのには不向きであると言えます。色などをCSSで制御できる
パスの中身を塗りつぶす色などを、WebページのCSSから制御することができます。
「SVGで置いたアイコンの背景色などによって画像の色を少し変えたい！」というときなど、わざわざ複数の画像を用意する必要がない訳ですね。もう少し掘り下げておくと
規格としてはxml（拡張可能なマークアップ言語）をベースとしたテキストデータです。
整形したSVGデータを眺めてみるとHTMLの記述にも近いものがあり、大体の構造が見えてくるかと思います。
次節で基本的な記述方法を把握し、SVGデータを眺めていきます。基本的なSVGデータの記述
<svg> 要素
SVGデータを記述するための外枠です。
ビューポートの大きさであるwidth, heightや、アスペクト比となるviewBoxも記述されます。width, height, viewBox指定の有無で、SVGデータは以下のように描画されます。
- width, heightが指定されている場合 縦横のサイズが固定されます。
- viewboxのみが指定されている場合 縦横の比率は保たれますが、サイズが固定されていないのでレスポンシブに対応させることが可能です。
- 全て指定されていない場合 基本的にはSVGのサイズのデフォルト値としてwidth="300px", height="150px"で表示されるようです。
詳細は以下をご覧ください。
HTMLタグリファレンス svg要素<defs> 要素
defs要素内に定義された要素はそのままでは描画されません。
SVGデータ内で同じようなパスを使いまわしたい場合など、defs要素内で定義しておいてdefs要素外から参照する、というような使い方をします。
参照される要素は、可能なかぎりdefs要素内で定義されることが推奨されています。詳細は以下をご覧ください。
HTMLタグリファレンス defs要素<path> 要素
画像を描画するためのパスを記述します。
パスを記述する要素として、<rect> や <circle> など沢山もありますが、<path> 要素はこれらの元となる要素であり、他の描画要素は可読性の向上や記述量の削減のためにショートカットとして定義されているもののようです。
描画要素についてはキリがなさそうなので省略しますが、よく見かけるものとして以下のような要素があります。<circle> <ellipse> <line> <polygon> <polyline> <rect>詳細は以下をご覧ください。
HTMLタグリファレンス path要素<g> 要素
パスのグルーピングを行う要素です。HTMLでのdivタグのようなものだと思っておけば良さそうです。
詳細は以下をご覧ください。
HTMLタグリファレンス g要素このくらいを把握しておけば、ソースを眺めたときにSVGの実態をざっくり掴むことができるかと思います。
SVGのソースを眺めてみる
Adobe XDでボタンコンポーネントをSVGとして書き出し、ソースを眺めてみます。
XDではSVGの書き出し時に内部CSSとプレゼンテーション属性で選択が可能です。
それぞれ以下のように書き出しが行われます。内部CSSでの書き出し （1325バイト）
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="90" height="36" viewBox="0 0 90 36"> <defs> <style> .cls-1 { fill: none; } .cls-2 { clip-path: url(#clip-path); } .cls-3 { fill: #009688; } .cls-4 { fill: #fff; font-size: 14px; font-family: Roboto-Medium, Roboto; font-weight: 500; } .cls-5 { filter: url(#長方形_182); } </style> <clipPath id="clip-path"> <rect class="cls-1" width="90" height="36"/> </clipPath> <filter id="長方形_182" x="-3" y="-1" width="96" height="42" filterUnits="userSpaceOnUse"> <feOffset dy="2" input="SourceAlpha"/> <feGaussianBlur stdDeviation="1" result="blur"/> <feFlood flood-opacity="0.239"/> <feComposite operator="in" in2="blur"/> <feComposite in="SourceGraphic"/> </filter> </defs> <g id="Normal_Raised_Light" data-name="Normal Raised Light" class="cls-2"> <g class="cls-5" transform="matrix(1, 0, 0, 1, 0, 0)"> <rect id="長方形_182-2" data-name="長方形 182" class="cls-3" width="90" height="36" rx="2"/> </g> <text id="Normal" class="cls-4" transform="translate(16 23)"><tspan x="0" y="0">NORMAL</tspan></text> </g> </svg>
内部CSSでの書き出しでは、<defs> で囲まれた <style> 要素内にCSSが記述され、グルーピングされたパスにスタイルが当てられていることが確認できます。プレゼンテーション属性での書き出し （1045バイト）
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="90" height="36" viewBox="0 0 90 36"> <defs> <clipPath id="clip-path"> <rect width="90" height="36" fill="none"/> </clipPath> <filter id="長方形_182" x="-3" y="-1" width="96" height="42" filterUnits="userSpaceOnUse"> <feOffset dy="2" input="SourceAlpha"/> <feGaussianBlur stdDeviation="1" result="blur"/> <feFlood flood-opacity="0.239"/> <feComposite operator="in" in2="blur"/> <feComposite in="SourceGraphic"/> </filter> </defs> <g id="Normal_Raised_Light" data-name="Normal Raised Light" clip-path="url(#clip-path)"> <g transform="matrix(1, 0, 0, 1, 0, 0)" filter="url(#長方形_182)"> <rect id="長方形_182-2" data-name="長方形 182" width="90" height="36" rx="2" fill="#009688"/> </g> <text id="Normal" transform="translate(16 23)" fill="#fff" font-size="14" font-family="Roboto-Medium, Roboto" font-weight="500"><tspan x="0" y="0">NORMAL</tspan></text> </g> </svg> <text id="Normal" transform="translate(16 23)" fill="#fff" font-size="14" font-family="Roboto-Medium, Roboto" font-weight="500"><tspan x="0" y="0">NORMAL</tspan></text>`
プレゼンテーション属性では内部CSSは記述されず、各パスに属性としてスタイルが割り振られています。
可読性は内部CSSでの書き出しの方が高そうですが、今回のボタンコンポーネントに関してはプレゼンテーション属性の方が容量が小さいようですね。Webでの扱い
WebページにSVGを表示させたいとき、HTMLにSVGデータを直書きする方法（インラインSVG）と、外部画像ファイルとしてimgタグでの読み込む方法があります。
こちらも簡単に比較してみます。インラインSVG の場合
メリット
- タグやクラスに個別にスタイルを当てることができる
- SVGの機能を全て使用することができる
デメリット
- HTMLに直書きすることになるので、コードが煩雑になり可読性が低下する
- HTMLのファイルサイズが肥大化してしまう
外部画像ファイルとしてimgタグでの読み込み の場合
メリット
- PNG画像やJPG画像と同じように扱うことができる（imgタグで拡張子を変えるだけ）ため、HTMLへの記述がコンパクトにまとまる
デメリット
- パーツごとにスタイルを当てることはできない
SVGの取り扱い方法 個人的メモ
現状、ロゴなどでSVGを使用する場合においては以下の取り扱いをすると良いかと考えています。
使用時は外部画像ファイルとしてimgタグで読み込み
パーツごとのアニメーションなどが必要なければ、HTMLの見通しやSVGファイルごとの差し替えを考慮し、外部ファイルとして読み込んでおくのが良いかと思います。
書き出しはプレゼンテーション属性で行う
プレゼンテーション属性で記述されたスタイルは優先順位が低く、CSSなどでの上書きが容易なようです。
画像があまり複雑でないアイコンやロゴなどであれば、内部CSSでスタイルを切り離すよりもこちらの方が扱いやすいかと思います。またSVGデータの扱いにおいて、複数のSVGデータを一つにまとめるSVGスプライトという方法が取られることがありますが、プレゼンテーション属性での記述であれば内部CSSの衝突を避けることができそうです。
(こちらは未確認です。)svg要素に記述されているwidthとheightは削除
svg要素に記述されているwidthとheightは、画像のサイズを固定してしまいます。
レスポンシブに対応させるため、こちらの記述は削除しておきます。
画像のアスペクト比はviewBoxで指定しておき、WebページのCSS側で大きさを指定します。注意点
width, heightを指定せずにbackgroundでSVGを読み込んだ場合、IEで表示崩れが起きることがあるようで、この場合に関してはwidth, heightは削除しない方が良さそうです。
imgタグで読み込む分には問題ないかと思っているのですが、他にも表示崩れがある場合、ご教授いただけると幸いです。まとめ
現状このあたりを最低限意識しておくと、比較的ストレスなくSVGが使用できることかと思います。
- 外部画像ファイルとしてimgタグで読み込み
- 書き出しはプレゼンテーション属性で行う
- svg要素に記述されているwidthとheightは削除
クリスマスまであと三週間ですね、皆様良い12月をお過ごしください！
- 投稿日：2019-12-04T17:40:22+09:00
[HTML] GET メソッドの form で URL のクエリパラメータが消えてしまう
問題
GET メソッドの form 要素の action 属性で指定した URL のクエリパラメータが消えてしまう
<!-- 送信時に URL のクエリパラメータから part=bass が消える。 --> <form action="/members?part=bass" method="GET"> <input type="text" name="members[name]"> <input type="submit"> </form>原因
仕様らしい。W3C 仕様書 には次のように書かれている。
Let query be the result of encoding the form data set using the application/x-www-form-urlencoded encoding algorithm, interpreted as a US-ASCII string.
Let destination be a new URL that is equal to the action except that its <query> component is replaced by query (adding a U+003F QUESTION MARK character (?) if appropriate).意訳: 送信先を action 属性の値と同じ URL にする。ただし、URL の query 部分は form データをエンコードした結果で置き換えられる。
仕様がないね。
対策
input[type="hidden"] を使ってフォームデータにパラメータを加える。
<!-- 送信時にクエリパラメータから part=bass が消える。 --> <form action="/members" method="GET"> <input type="hidden" name="part" value="bass"> <input type="text" name="members[name]"> <input type="submit"> </form>参考
- 投稿日：2019-12-04T11:38:10+09:00
PCで編集中のウェブサイトをスマホから確認する方法
はじめに
本記事は Mac + iPhone という環境を想定しています。
Win + Android も基本的なところは共通しています。確認事項
PCとスマホが同じネットワーク化にいることを確認する
WiFiの場合、 基本的には 同じSSIDで接続していれば同じネットワークです。
ファイアウォールの設定をOFFにする
[システム環境設定]>[セキュリティとプライバシー]>[ファイアウォール]
localhostを立ち上げる
コマンドラインから開発中のディレクトリでhttpサーバーを立ち上げます。
Python2の場合
$ python -m SimpleHTTPServerpython3の場合
$ python3 -m http.server実行例
$ python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...オプションでポート番号を指定しない場合は上のように8000番を使用します。
PCからの確認はブラウザでlocalhost:8000にアクセスするだけです。スマホからアクセスする
MacのIPアドレスを表示する
[システム環境設定]>[ネットワーク]>[詳細]>[TCP/IP]
IPv4アドレス: 192.168.11.43がローカルネットワークにおけるこの端末のアドレスになります。
通常ローカルのIPv4アドレスは192.168.XX.XXのような形をしています。
このアドレスは固定ではないため、ネットワークに繋ぐたびにその時のアドレスを確認するようにしてください。
または
ifconfigで確認する場合は$ ifconfig en0 inet en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet ⭐️192.168.11.43⭐️ netmask 0xffffff00 broadcast 192.168.11.255iPhoneのブラウザからアクセス
[ローカルIPアドレス] : [ポート番号]で表示することができます。
スマホの場合キャッシュのクリアが面倒なので、ブラウザーのプライベートモードで確認すると捗ります。
アクセスできない場合の確認事項
- httpサーバーを立ち上げるディレクトリは正しいですか？
- ファイアウォールはOFFになっていますか？
- PCとスマホは同じネットワーク下にいますか？
- MacのIPアドレスやポート番号は最新ですか？
- 投稿日：2019-12-04T09:40:57+09:00
Qiitaのブランド カラーコード 16進数
「ねぇ、Qiita君の好きなカラーコードを教えて？」
Qiita(New)
黒
#1D2121
緑#00FD00
肌#F6DFD6
緑#31B600
緑#00CA00
青#0298E1Qiita(Old)
緑
#59bb0c
白#ffffff投稿する
濃い緑
#409202ストック
灰
#777777アクション
灰
#aaaaaaQiita:Team
青
#2398d8
白#ffffffIncrements++
黒
#000000kobito
黒
#000000
緑#59bb0c
白#ffffffQiitan
緑
#82b046
顔#82b046
耳#ede455カレンダー
赤#EF5351アドベントカレンダー
ワイン
#A82632
オレンジ
#D0712Fフッター
背景
#F6F6F4
黒#3E3E3E
文字#B3B3B3目次
文字ホバー
#333333
文字#85837a
背景ホバー#E6E5E1
背景F6F6F4通知
緑
#74C13A
薄#F0FBE4
数字#568F29通知来た
赤
#D15633Qiitaのことが好きだったんだよ！
（12/2 早速のNewデザイン、勝手に使用してすみませんでした[2]。）使用例
もし、この記事が役に立ったら、「いいね」「ストック」押してくれ??
参考
[1]ブランドガイドライン Qiitaサポートガイドライン
[2] Qiitaのビジュアルアイデンティティを再定義し、ロゴ等を変更しました
- 投稿日：2019-12-04T02:38:26+09:00
HTMLの基本要素について
はじめに
HTML5の基本要素について、備忘録も兼ねて整理をしてみた。
HTMLの基本構造
要素 意味 DOCTYPE HTMLのバージョン情報を宣言する。 html HTML文書のルートを表す。全ての要素はhtml要素の中に記述する。 head HTML文書自体の情報を表す。html要素の最初の要素として記述する。 meta 文章に関する情報を表す。 title HTML文書の表題を表す。ブラウザのタイトルバーに要素の内容が表示される。 body 文章の内容を記述する領域を表す。 HTMLの代表的な特殊文字
HTMLの中に半角の<や>を入れるとHTMLタグの一部と認識されてしまい表示されない。
なので表示するために、特殊な書き方をする必要がある。
ブラウザでの表示 コード上の書き方 名前 < < 小なり > > 大なり & & アンパサンド 空白 © © 著作権記号 ページ全体(body)の構造を表現するタグ
HTML5から追加された文書を構造化しやすくするためのタグ。
構造化することで検索エンジン(Google)のクローラーがコンテンツ内容を認識しやすくなり、
クローラビリティがあがり、検索エンジンに評価されやすくなる。
要素 意味 nav ページのナビゲーションを表示する header コンテンツのヘッダー部分に使用 article 独立したコンテンツであることを示す section コンテンツの中の一つの区切りを示す aside メインコンテンツとは別にサブに表示するタグ footer コンテンツのフッター部分に使用 h1〜h6 見出し p 段落
headerとfooterはページ内で１つだけしか使えないというわけではなく、一覧ページの１つ１つのコンテンツを囲む際にも使うことができる。- 内容が異なるものを区別する場合は、
articleタグを使う。- 関連している内容を区別する場合は、
sectionタグを使う。- 厳密にどちらかわからない場合は大人しく
divタグを使う。構造化データのSEO効果については構造化データとは？マークアップ方法からSEO効果まで解説！に詳しく解説されていたので、こちらをご確認ください。
参考記事
HTML のセクションとアウトラインの使用
HTML5の新規タグ「section、article、header、footer」の使い方