「Sass」を含む日記

■anond:20231225192638

底辺コーダーやんけ

＞スキル

JavaScript / jQuery / TypeScript / HTML / CSS / Sass / WordPress / ActionScript / Flash / PHP / grunt / gulp / webpack

Permalink | 記事への反応(1) | 19:30

ツイートシェア

■遊戯王をCSSでいえば

遊戯王って生のままだと滅茶苦茶扱いにくいんですよ

現実の紙でやるのは頭の体操にはなるけど入り口にはしたくないな

• 紙: Pure CSS
• マスターデュエル: Sass

Permalink | 記事への反応(0) | 16:25

ツイートシェア

■anond:20220120010619

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ？分かってるのか？

Permalink | 記事への反応(0) | 01:10

ツイートシェア

■疲れてるんご

sassとsaasが逆に見えた。

aかsだけどぜんぜんちげーじゃん

Permalink | 記事への反応(1) | 18:30

ツイートシェア

■Web業界の中年エンジニアです。法人向けSaas開発の魅力を教えて。

転職先を探していたら法人向けSass開発の求人が多くて驚いた。

業界知識もないしそんなに興味が持てない。

例えばバックオフィス系Sass。モダンな機能を提供して利用者は便利なのかな？。そういうところにやりがいを感じる？それともやりがいとか求めるエンジニアって少ないんだろうか。

実際に法人向けSaas開発をしてる人で

「こういうところが開発してて面白いぞ」とか

働いてみて良い意味で感じたギャップとかあったら教えてください。

Permalink | 記事への反応(1) | 17:22

ツイートシェア

■

学習初心者だけど、atomだと環境を作らなくてもlessが使えて便利なのになんで世の中はsassなん？

Permalink | 記事への反応(0) | 08:24

ツイートシェア

■CSSはレガシーだから新しいソリューションがほしい

・CSSセレクタとかいう万能すぎて容易に共通化スパゲッティを生むターゲット指定方法

・レイアウト(外枠のデザイン)と色味や画像の指定（中身のデザイン）が分離しきれておらず可読性が低い

・ついでにアニメーションまで入ってきてカオス（アニメーションが指定できる事自体は素晴らしい）

・しかもアニメーションの文法なんか無理やりCSSに合わせててとっつきにくい（繰り返すがアニメーションが指定できる事自体は素晴らしい）

・SASSだとかSCSSだとか色々でてきたけど根本はCSSなので辛いところは辛い

・エコシステムがJSにどっぷりなのもなんか気持ち悪い

Permalink | 記事への反応(0) | 15:46

ツイートシェア

■でた！ビルド後のファイルをPUSHするやつ

SASSビルド後のCSSをリポジトリに入れるなよゴミデザイナー

Permalink | 記事への反応(0) | 21:36

ツイートシェア

■

SaaSがさ、sassに見えた。ちょっと休むわ。

Permalink | 記事への反応(0) | 08:06

ツイートシェア

■anond:20200607045358

web系に進むなら追加でcss終わったら

• プリプロセッサであるsass（基本的にCSS直書きするケースは少ない）
• cssフレームワークのbootstrap4(5もそろそろ出る)（デザイン知らなくてもそれっぽくなる．あとデザインに出てくるUIの部品名がわかるようになる）
• webpack使うためのnpmとNodejs(commonjs)の基礎（サーバーサイドならNodeJSもあり，JSでフロントエンドとサーバーサイドを統一できる，実際はほぼ別物だけど）
• sassやTypescriptを自動変換・設定してくれるwebpack（それぞれでコンパイルできるが，今は基本的にこいつでまとめて使う）

Permalink | 記事への反応(1) | 05:01

ツイートシェア

■anond:20200521200119

レンタルサーバーなので削除した。いつまでも鯖代払いたくないからね。

Railsで作ったよ。

ActiveRecordはUserとTweetとProfile。

belongs_toやhas_many使ってデータベースを関連付けして

ApplicationControllerで@current_userにログインしたユーザを格納して、ツイートの削除権限とか、トップでの表示内容管理したりした。

ProfileはCSS（Sass）やプロフィールの説明の部分や画像を管理できるようにしたよ。

当時はRails4だったから、SprocketsやTurbolinksも使ったよ。

Permalink | 記事への反応(1) | 20:11

ツイートシェア

■未経験の応募者をバカにしたツイートがあった

wantedlyの応募、今のところ８～９割くらいが未経験でプログラミングスクール通っています系

よくみて！うち、XRとかやってるよ！？

HTMLとかCSSでなんとかなる仕事じゃないよ！？

ツイート主のサイトの採用情報をみたら

あると望ましいスキル・経験 ・Node.js ライブラリを利用した開発経験

・HTML の知識や HTML テンプレート言語の知識

・CSS の知識や Sass などの CSS 拡張言語の知識

・Gitを利用した開発経験

・コードレビュー（する/される）の経験

・PHPフレームワーク上での JavaScript コードの保守運用面の改善経験

Permalink | 記事への反応(0) | 23:56

ツイートシェア

■

最近はCSSに代わってSASSという…

最近っていつ?

Permalink | 記事への反応(0) | 12:49

ツイートシェア

■教えてエンジニア

sassの@importみたいに複数のjsファイルをただ結合する方法って無い？

gulpfile.jsとかで結合する方法はすぐ見つかるんだけどそういうのじゃなくて、コンパイル前のjs側で管理したい。

レガシーなJsだからモジュール化とかそういう話ではない。

index.js

├import(_a.js);

├import(_b.js);

└import(_c.js);

って書くとindex.jsにa〜c.jsの内容がそのまま入ってくるイメージ。

Permalink | 記事への反応(1) | 14:15

ツイートシェア

■作ったものを公開できない問題

こんなのあったらおもろいなーと思ってwebアプリ？みたいなやつ作ってたんだけど全然公開できない。

【公開までの見積もり甘すぎ問題】

8割はできたって所から公開しようって状態まで持っていくの大変すぎ。

感覚的には8割から先がそれまでの2倍の負担はある。

【デザインめんどくさすぎ問題】

デザインなんてどうでもいーと思いつつも触りだしたら「せっかくだから」と触り出しちゃう。

さすがに最低限それっぽくしたくなっちゃう。

CSSフレームワーク使ってみたら結局上書きしまくりで使い物にならない。

もうさ、本当になんでもいいんだよ。レスポンシブとかどうでもいいんだよ。

けどそれくらい対応してないとダサいみたいな空気感じちゃう。

なんでsassの使い方なんて調べてるんやー

compassってなんやー

lessってどうなったんやー

【サーバー準備めんどくさすぎ問題】

どのサーバーを使えばいいかわからん。

VPS？heroku？AWS？

こんなものを公開するのにサーバー代を払う事を想像すると手がすくむ。

AWSは便利みたいな風潮なんなの普通に構築大変なんだけど。何のサービスあるかよく分からないし。高いし。

herokuは操作がないと止まるらしいし。

操作ってなに？デプロイ？WEBアクセスでもいいの？定期的にリクエスト投げておけば止まらない？

cloneとか使えるの？nginxの設定いじったりとかできる？apache？

使ったこと無くてわからない。

得体が知れなくて怖い。

結局VPS借りたよもう！

【話が大きくなっていく問題】

最初は1つの機能だったのが深夜のテンションであれしたいこれしたいってどんどん出てくる。

超人気サービスになって超有名人になってインタビューに答える姿まで想像しちゃう。

ブツブツ独り言言いながら予行練習もしてる。

最低限作る機能がどんどん増えていく。

【みんなに知ってもらえない問題】

ある程度有名人ならTwitterとかでつぶやくだけで認知してもらえるだろうけどさ。

全く有名でもない自分が、作りました〜って言って誰が見てくれるのさ。

最初の広めるハードル高すぎない？

意外と誰かが見つけてくれるものなの？

白馬の王子様を待っていればいいの？

お金払えばいいの？誰に払えばいい？

作ってる時は超人気サービスになる事を想像してムフムフやってたけど、いざ公開しようという段階まで来ると「どうせ誰にも見てくれない」とか考えてどんどん自信がなくなってゆく。

カッコいい事言ってるけど、作ったサービスが全くウケなくて誰にも使われなかったら..とか、失敗した自分を想像して動けなくなってるんだと思う。

あーーー寝る前にスマホで1時間掛けて書いた。

何を書きたいのかもよく分からなくなってきた。

書くってこんなに時間かかる？

自分だけ？

文章書くの大変すぎ問題...

もういい！寝る！

のび太さんのエッチ！

Permalink | 記事への反応(0) | 03:09

ツイートシェア

■xyzzy 使いに 50 の質問

01. ハンドルネームは?

　　増田

02. ご職業、年齢はいくつですか?

　　なんでも屋さん、アラサー

03. xyzzyについて何かwebサイトを持っていますか?

　　持っていません

04. 現在使用中の xyzzy のバージョンは何ですか?

　0.2.2.253

05. xyzzy 使用暦はどれくらいですか?

　　15年くらい

06. xyzzy を使うようになったきっかけは何ですか?

　　昔のことすぎて忘れましたが、学校の UNIX 演習で Emacs を使っていたので、Windows でも使おうと思っていて見つけたんだと思います

07. xyzzy 以外に使っているテキストエディタはありますか?

　　Atom, McEditor

08. xyzzy を使う前に Emacs 系のテキストエディタを使ったことはありますか?

　　はい

09. xyzzy を主に何に利用していますか?

　　プログラムを書いたり設定ファイルをいじったり、テキストに関することならだいたい

10. xyzzy が関連付けされているファイルタイプは何ですか?

　　txt, md, log, ini, bat, html, xml, css, less, scss, sass, styl, js, coffee, pl, php, py, rb, java, sql ほかにもあるかも

11. xyzzy を他人に勧めたことはありますか? また、結果はどうでしたか?

　　使い始めた当時同級生が何人か使っていました

12. xyzzy がフリーじゃなかったとしたらいくら位の値段になると思いますか?

　　今なら3000円くらいなら買う

13. xyzzy を何と呼んでいますか?

　　じじー

14. xyzzy の好きな点・嫌いな点はどこですか?

　　好きな点：動作をほぼ自在にカスタマイズできる点

　　嫌いな点：動作をカスタマイズするときに不自由なところがある点

15. パソコンを立ち上げている時間の内、xyzzy をどのくらい使っていますか?

　　業務のときは3割くらい？

16. キーバインドは Windows風ですか? Emacs風ですか? オリジナルですか?

　　Emacs風

17. .xyzzyに書く派ですか? .siteinitに書く派ですか?

　　必要に応じてそれぞれに

18. 拡張Lispはバイトコンパイルしますか?

　　してます

19. セレクションとリージョン、どちらを多く使いますか?

　　リージョン

20. xyzzy を使っていて挫折したことはありますか?

　　はじめのころ五目並べになかなか勝てなくて挫折しました

21. xyzzy の使い方をどうやって学びましたか?

　　実際にさわりながら。Lisp は Google 先生さまさま

22. xyzzy を使うにあたって一番苦労したことは何ですか?

　　xyzzy 自体の Lisp API がマニュアル化されていないところ

23. xyzzy を使って目からウロコだった機能は何ですか?

　　Buffer Menu

24. 今の xyzzy に望むことはありますか? またそれは何ですか?

　　矩形機能に影響が出そうだけどプロポーショナルフォントへの対応と、絵文字など最近 Unicode に追加された文字への対応

25. Lisp はある程度読み書きできますか?

　　xyzzy を自分の使いやすいようにできる程度には

26. Lisp のほかに読み書きできるプログラム言語はありますか?

　　JavaScript, ES 2016, Coffee Script, Action Script 3, C, C++のごく一部, Objective-C, Rust, Swift, Perl, PHP, Python, Ruby, bash, xyzzy lisp

27. 自分で作った 拡張Lisp を公開していますか?

　　GitHub や Gist にあるので探してください

28. 拡張Lisp で導入しているものは何ですか? (多い方は代表的なものをお答えください)

　　clickable-uri, jscript-mode, markdown-mode など

29. これは外せない! という 拡張Lisp はありますか? またそれは何ですか?

　　いろいろやるので今ある拡張機能がないと無理

30. NetInstaller を利用していますか?

　　はい

31. 拡張DLL を導入していますか? またそれは何ですか?

　　popup-dododo のための Cairo とか？

32. ドキュメント(info,reference等) は使っていますか? また、それは何ですか?

　　使っていません。自分で改造してキーワードを全部 Web で検索するようにしています

33. ネット関係の 拡張Lisp(www-mode,kamail等)を使っていますか?

　　xyttr

34. アウトライン系のLispは使っていますか? またそれは何ですか?

　　使っていません

35. メモ系(changelog-memo,howm等)Lispは使っていますか? またそれは何ですか?

　　使っていません

36. xyzzy の五目並べはやったことがありますか? また、結果はどうでしたか?

　　今なら結構勝てます

37. キーボードマクロは使いますか?

　　たまに。テキストの整形処理なら正規表現でゴリゴリやるほうが多いです

38. 辞書機能は使いますか?

　　使っていません。国語、英和・和英、英英辞典は iPhone のアプリを使います

39. xyzzy のファイラは使いますか?

　　毎日の仕事に欠かせません。便利にカスタマイズしすぎてむしろファイラだけのために新しく xyzzy 自体を起動することもあります

40. フレームは使いますか?

　　あまり使いません。新しく（Windows における）ウィンドウ

41. セッションは使いますか?

　　使っていません

42. メーリングリストには参加していますか? また、メールを送信したことはありますか?

　　ありません

43. 2ch の xyzzy 関連スレッドに書き込みをしたことはありますか? また、その頻度はどのらいですか?

　　大昔にどうしてもわからないことがあって書き込んだ記憶があります

44. xyzzywikiに書き込みをしたことはありますか? また、その頻度はどのくらいですか?

　　拡張機能の実装に関してちょろっと書き込んだ記憶があります

45. xyzzy のメニューは表示していますか?

　　たまにほしくなるので表示しています

46. xyzzy のツールバーは表示していますか?

　　隠しています

47. xyzzy のファンクションバーは表示していますか?

　　表示していません

48. xyzzy のバッファバーは表示していますか?

　　表示していません

49. 色、フォントなどは変更していますか? またそれは何ですか?

　　色は暗い背景色、ハイライトカラーはできるだけ色相を離したパステルカラーです。

　　フォントは Consolas に源新ゴシック Regular を組み合わせています。

50. 最後に、一言お願いします。

　　まだまだ xyzzy は不滅です

Permalink | 記事への反応(0) | 16:44

ツイートシェア

■anond:20180626091249

他社がらみの場合は、ちょっと教育するのきつい。

jpegしか知らないWebデザイナは他社の人間だし。

まあ「要望」という事で、技術的な情報は共有していってるつもりだけども。

TypeScriptで作ったプロジェクトを、部分的に他社に引き継ぐにも

「tsよく分からないんでjs直接いじっちゃいました」とか笑いながら言って来るし。

SASSだと言ってるのにCSS直接いじってヘラヘラ笑ってるし。

無能が金ばっか要求してくる。

Permalink | 記事への反応(0) | 09:27

ツイートシェア

■https://anond.hatelabo.jp/20171204113430

＞サーバのセットアップからアップデートにチューニング、

まあやれる

SIerでもWin鯖の面倒みたりするじゃんね

＞CSS,JavaScript,HTML5,PHP,Ruby,node.js,SASS,LESS,

サーバサイドは主にPHPまれにC#だが、フロントは一通り

スマホのネイティブ開発もやるかな

SIerだとJava,C#,VBとJSか？

＞Photoshopで画像処理、AIでデザインカンプ

デザインはデザイナがやるから、エンジニアはクリッピングと縮尺操作程度じゃない？

SIerだとデザイン行程が無いけど、エンジニアはあまり関係が無い気がする

＞要件定義から動作テスト、マニュアル作成まで

やりますな

SIerでもやるじゃん

なるほど、SIerだと、一つの現場で全部やる人は居ないね

ただ長い人なら、どれも経験あるんじゃないの？

Permalink | 記事への反応(0) | 00:42

ツイートシェア

■anond:20171204085129

サーバのセットアップからアップデートにチューニング、

CSS,JavaScript,HTML5,PHP,Ruby,node.js,SASS,LESS,

Photoshopで画像処理、AIでデザインカンプ

要件定義から動作テスト、マニュアル作成まで満遍なくなんでもできると、

特に技術的に目立った何かなんてどこにもない。

Permalink | 記事への反応(1) | 11:34

ツイートシェア

■CSSの設計云々言えるのは恵まれた環境にいるからだろ

Web制作において持論がある。CSSの設計云々で議論できるのはまともな営業が居てまともなクライアントをつかまえてきてまともに意見を言えるからだ、そうでなければCSSの設計云々は話にならない、お話にならない。

OOCSSにBEMにSMACCS、そんなもんできるかよ。クソみたいな、デザインを破壊する修正が大量に来て統一性もなにもあったもんじゃないし、セマンティック? 知るかくたばれ。アニメーションすらバラバラに指定されてっからAnimate.cssすら使えねえ。そもそも統一させてもらえないからクラスの意味がほとんどねえ、全部IDでも変わんねーよ。

頑張ったよ。SASSで綺麗に書こうとしたし、Smartyみてーなテンプレートエンジンが効率良いってのも分かってるよ。でもヘッダーすら変えろとか言われたらどこを共通化すればいいんだよ。

俺は確信した。Bootstrapの"mt-2"とか"display-inline-block"みたいにクラスを付けてってそれにスタイルを適用してくのが正解だって。ってかBootstrapのクラスばっかりでスタイル作ってる。だってクラス見るだけでスタイルが分かるし、共通化は一切されてねーからな。

あいつら、グラフィックデザインと同じだと考えてやがる、くたばれ。ポスターじゃねーんだよ。

俺はもう闇のWeb製作者になり客にはバキバキに嘘をつくようになった。SEOがだとかデバイスの保有率のデータだかなんかを持ち出して出来るだけ頑張らなくて良いサイトを作る。だって頑張ったってそれはカオスを作るだけの技術が上がるだけでコーディングの技術が上がる訳じゃ無いからな。

かと言って外注に出したらクソみたいに思いCSSフレームワーク使ったサイトが上がってくる、くたばれ。しかもグリッドシステムぐらいしか使ってねーじゃねーか、skeletonでも使っとけ、ふざけんな。

おかげで俺は毎日Web2.0的なデザインとレスポンシブ対応が混合した、パラレルワールドみたいなサイトを作ってる、スチームパンクだろ、お前営業やめろよ。単価安いんだよ。俺が営業行くから。元営業だからお前より喋れるから。

とにかくモジュール化だとかクラス命名手法だとか議論出来るお前らは幸運だ。全部の国がそれぞれ違う大陸にいるようなもんだ、クラスいらないからな。誰かWebpackであいつらの前頭葉をパッキングしてくれよ。

Permalink | 記事への反応(1) | 23:57

ツイートシェア

■web系の専門用語多すぎ問題

門外漢からするとこんな風に聞こえてる。（所々適当に書いてるし書いてる内容は嘘デタラメ）

「gulpでbowerしてsassをgruntでビルドすれば、cssがストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWSと連携させてWebGLとTensorflowやらchainerやらと組み合わせればブラウザでDQNとかA3CとかDCGANも動かせるスクリプトがリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsでカスタマイズしたりタスクランナーでプロセスをマネージメントできるからもはやjsでtensorflowを含めたpythonのラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinのマインングをサポートしていてブラウザ上でウォレットからマイニングのセットアップまでできるんだって、ブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータを分散してサーバーに保存できるみたいなこともあるんだって。」

どうしてweb系は専門用語が肥大化するんだ。

Permalink | 記事への反応(1) | 03:50

ツイートシェア

■webサイト作成したいだけなのに何でファイルを沢山作らないといけないのか

webpackの設定ファイル

gulpの設定ファイル

sassの設定ファイル

ライブラリを使うとどんどんファイルが増えていく

設定に関する仕様を策定して統一できないものかね

設定ファイルを1つにまとめられたら良いんだけどね

↓こんな感じで1ファイルにカテゴリ毎に設定したほうがディレクトリがきれい

[webpack]

[gulp]

[composer]

[phpmd]

Permalink | 記事への反応(0) | 14:23

ツイートシェア

■プログラマー共ちょっと来い、神アイディア思いついたから作ってくれ

完全に単一のHTMLファイルで動作するMarkdownエディタ作った

http://qiita.com/tatesuke/items/225b51b270faf8b10923

Qiitaのこの記事見てて思ったんだけどさぁ、

これ絶対単一HTMLじゃなくてAtomのプラグインで作るべきだって思ったんだよね

使ってみた感じやっぱ更新→保存周りが弱いんだよね、発想は良いんだけど

あとその他のMarkdownエディタに比べてデザインがあんまかっこよくない

エディタ部分とかほぼ単純なtextareaだし

例えばhogehoge.md.htmlみたいな名前のファイルをatomで読みこめば.mdファイルみたいな

感じ（実際はscriptとかCSSとかいろいろ書かれてるわけだけどMarkdown部分のみ）で読み込まれて、

で、それを編集した奴をそのままブラウザで開いたらJS側でレンダリングされたドキュメントとして表示される感じ

簡単にSassでスタイルを当てたりリアルタイムプレビューできればなお良い

実質完全に単一ファイルだしエディタ部分をAtomパワーに依存させることができるから

ええ感じのアイディアと思うんだけどどうやろか

Permalink | 記事への反応(0) | 22:48

ツイートシェア

■

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います。

p.4

• HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
• gulpのgは小文字なのでよろしくです。

p.5

• ん〜非常に大きな枠での話をしてますけど、これから出てくる項目がそれらを解決できるのかなぁと、不安がつのりますね
• むしろ「なんでそんなルールを？」という質問が噴出しそうですが！？

p.6

• こういうアジェンダの書き方、斬新ですね

p.8

• EditorCodingってなに

p.9

• コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
• npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです？
  • まぁ、この後gulpタスクについて出てるんでしょう……
    • 出てこなかった

p.10

• ちょっとだけ違和感のあるディレクトリ構成

p.15

• FixとかAddとかはいいと思うっていうかみんなやってることなんですが、黒括弧はないでしょう。
• 日本語モードと英語モードを行ったり来たりするのだるいんですよ。
  • Fix - about / フッターリンクを修正
  • これなら「フッター〜」までを英語モードのまま書ける。

p.16

• 逆に考えるんだ。Thumbs.dbと.sass-cache/はバージョン管理しちゃっていいさと。

p.18

コードの品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

• HTMLの話ですよね？　コードの品質が維持されない難読化や最小化やコンパイルってなんだろう。
• あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。

p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

• その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
• いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
• あと日本語が変なんで、それも。

p.20

• NGってなってますけど、NGの理由が伝わってこないっすね。
• divの閉じタグが不正なのはスペース関わらずNGだよ！

p.21、22

• わたしはオッサンなんで、このルールは好きじゃないんですよ。
• //で始まってると、ルート相対パスと見間違えちゃうんだよね。
• それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
• 自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
• Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
  • ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
  • 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
  • なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

• .editorconfigにどう書けばいいかをだな……。

p.25

• HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
• Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
• でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

• HTMLの正しさとは？
• 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

• default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
• あと、CSSファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

• こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

• アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

• えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
• 「このスプレッドシートでは、年を行に、月を列した2010年から2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
• 気遣いではなくウェブサイト製作者の責任として。
• ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

• クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
• gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
• あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
• 正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

• いやいや、CSS”設計の”教科書ですからね、その本。
• 脱字なのかな！？

p.42、43

• その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
• それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS設計いらないんじゃないですかね。

p.44、45

• セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
• 省略していいなら、省略のルールまで決めていきましょう。
• 教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

• ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

• HEXの短縮は規定しなくていいと思います。
• ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
• gulpでできますし、ググれば出てきます。
• ちなみに、#f00よりもredの方が1バイト少ないんですよ。
• 容量削減は人が思いつきでやるには不十分なのです。
• そんなのはビルド時に機械がやればいい。
• 容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

• もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

• と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

• TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
• だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

• FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

• 冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
• https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
• 「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。

p.78、79

• 打ち消しを減らすのは悪いことじゃないっすね。
• でも、追加的なスタイルの宣言をモディファイアの仕事にさせるのは、なかなか危ないと思うんですよね。
• 決まったルールもなく大量にモディファイアが増えたCSSはコンポーネント管理されていると言えるんでしょうか。
• 再利用性？　必要になったら作り直す方が早いと思いませんか？
• 設計してても作り直すことになると思いますけどね。
• あなたはそのプロジェクトのコンポーネントがどうスケールしていくかなんて、予測できているんですか？

p.80、81

• 言ってることは概ね正しいっす。でもサンプルのCSSにタイプセレクタが入っているのはツメが甘いとしか。

p.87

• 日本語校正を。

GoogleChromeなら変換時に右側に△マーク〜

• それGoogle 日本語入力のことかな〜それともChromeにそういう機能があるのかな〜

p.96

• この手の分類で上手くいくというのは幻想。試しに次の画像のファイル名を考えてみてください。
• 「ボタンを示すアイコンで、テキストが含まれていて、背景で使うことが想定されるもの」

• コンポーネント単位で使う画像ファイルと、ページ単位で使う画像ファイルがあるのが変なんですよね。
  • 管理区分が横断しているというか。
  • 画像もすべてコンポーネント単位で管理すればいいわけなんですが。
    • でもあなたはきっと、同じファイルを別名で複数持っておくことを許してくれなそうだ。

p.98

※svgにすることで1つの画像でまかなえる場合はsvgを使用する

• 言っている意味がよくわからないです。
• インラインSVGを使用してfillプロパティーなどで色のバリエーションを管理するってことでしょうか。だったらsvgファイルとしては保持されないですが。
• もしくはSVGスプライト？　スプライトならpngでよくないですか？　なんでわざわざsvg？
• 急にsvgが出て来て混乱しちゃう！

p.102

• ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
• Jadeについては何かルールは設けないのでしょうか。
• JavaScriptについては……？

• そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
• 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。

• ルールを設けるのは悪いことではないですが、穴があってはいけません。
  • あいまいな基準や不足だらけのルールに、誰が期待できるでしょうか。
• エビデンスの弱さも気になります。
• コーディングルールの半分くらいはnodeプラグイン互換のlintツールでチェック可能です。

• 結論：いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

Permalink | 記事への反応(0) | 11:26

ツイートシェア

■SCSS(Sass)とLESSってどっちがいいの！？

Web製作者のタマゴなんだけどSass使ってないとか信じられないってセミナーでよく言われるんだけど！

Sass便利そうだから使ってみようかなって思うんだけどLESSっていうのもあるらしい。

どっちがスマートなの！？

ナウいのはどっち！？

結果にコミットしてくれる方は！？

実務性、将来性、設計思想の３つで評価して！！！！！！

Permalink | 記事への反応(0) | 13:07

ツイートシェア