普通はimportとかだよ
jQueryとかで場面によってCSSの設定を変えるなら、その変えるヤツとかをインラインにするかも。が、ただ計画性がないだけの場合が大多数（笑）。
Re:3 Re:2 なるほど、ありがとうございます！意図がないんなら管理しにくいからclass付け外しに変更することにします。
バックエンドの人とか、フロントエンドを名乗るJSerは、html/cssを知らない割合が異常に高い。jsからsytle使ってcssを変更したり、インラインcssを多用したり、2が言うように、importでファイル分割したりしてる。それがどれだけバッドノウハウか彼らは知らない。たぶん、そういうこと。
Re:5 jsでcss変えるのとか当たり前じゃない？むしろ、フロントエンドはその流れでしょ。
Re:6 style要素でやるのがNGって話だと思う。cssをjsで変更するならclassの付け外しにしないと管理がややこしいかなと。見当違いだったらごめんね。
他人がかいたコードはおろか、自分が数ヶ月前にかいたコードでさえ「ん？なんだこれ？」ってなるくらいだから考えたら負けだと思ってる。
Re:7 class自体をそもそも使わずにjsでcssやる流れだね、フロントエンドは。
Re:6 変えるというか、JSからしかCSSを生成・管理しないとう流れならそうとも言える。でも、CSS(sass/stylus/less)のファイルがあって、それをJSから上書きするような行為は、単にスタイルの管理が2重になってるだけだから残念。破滅一直線。
割りとインラインで書いてるの見かける（WordPressで作ったサイトとか）けど、利点はファイルの読み込みがない＝読み込みが早くなるってだけだと思う。利便性考えれば分けた方が良い。
Re:5 ちょっと言い直すと、JSerが悪いんじゃなくて、VBとか.netとかCとかのマイクロソフト組や高級言語しか経験のない組が、近年JSerの中に混じってきて、そいつらのhtml/cssの無知っぷりが凄まじい。彼らはwebやろうとしてるのに、html/css知らなくても通用すると思ってるところがとても素敵。
Re:10 主です。詳しくありがとうございます。やっぱりそうですよね。jsとcssに両方レイアウト要素があると管理が煩雑になるなって思ってたので納得しました。（jsわからん人にはなんで上書きされたかわからんかったりするし）
Re:12 低級言語の経験者の方が圧倒的にwebは稀だと思うが
Re:14 低級言語の話はしてなくてだな、極端に言うと、TypeScriptしか知らないような人がいるってことよ。
Re:7 一番の害悪はこれよ。document.getEelementById("hoge").style.marginTop="10px";インラインスタイルでの指定にも似てるけど、こんなの量産して誰がどうやってスタイル管理するんだろうね。
CMSの管理画面にカスタマイズが発生すると、インラインかstyle要素で書いちゃうな。スクラッチなら、管理画面側も、一定のデザインスキームでCSS書かないといけないんでしょうが。
Re:9 どう考えてもclassの付け替えの方が良いと思うのだが今てそんな流れなの？
Re:19 フロントエンドと言ってもかなり幅がひろいんだけど、おそらく一般的にフロントエンドというと、JSerの領域を指すと思うよ。つまり、html/css/jQueryコーダーの領域ではない習慣の話になるんだけど、そもそもhtml/cssはすべてJSから出力する手法というのがあってね、その場合は、css(sass/less/stylus)ファイルを直接編集するということがないから、JSから管理することになるのよ。そうなると、classの切り替え以上に効率のよい方法ができるから、実質、classの切り替えの出番はなくなるよ。
19 件の回答
普通はimportとかだよ
jQueryとかで場面によってCSSの設定を変えるなら、その変えるヤツとかをインラインにするかも。が、ただ計画性がないだけの場合が大多数（笑）。
Re:3
Re:2
なるほど、ありがとうございます！
意図がないんなら管理しにくいからclass付け外しに変更することにします。
バックエンドの人とか、フロントエンドを名乗るJSerは、html/cssを知らない割合が異常に高い。
jsからsytle使ってcssを変更したり、インラインcssを多用したり、2が言うように、importでファイル分割したりしてる。それがどれだけバッドノウハウか彼らは知らない。
たぶん、そういうこと。
Re:5
jsでcss変えるのとか当たり前じゃない？むしろ、フロントエンドはその流れでしょ。
Re:6
style要素でやるのがNGって話だと思う。cssをjsで変更するならclassの付け外しにしないと管理がややこしいかなと。見当違いだったらごめんね。
他人がかいたコードはおろか、自分が数ヶ月前にかいたコードでさえ「ん？なんだこれ？」ってなるくらいだから考えたら負けだと思ってる。
Re:7
class自体をそもそも使わずにjsでcssやる流れだね、フロントエンドは。
Re:6
変えるというか、JSからしかCSSを生成・管理しないとう流れならそうとも言える。
でも、CSS(sass/stylus/less)のファイルがあって、それをJSから上書きするような行為は、単にスタイルの管理が2重になってるだけだから残念。破滅一直線。
割りとインラインで書いてるの見かける（WordPressで作ったサイトとか）けど、利点はファイルの読み込みがない＝読み込みが早くなるってだけだと思う。利便性考えれば分けた方が良い。
Re:5
ちょっと言い直すと、JSerが悪いんじゃなくて、VBとか.netとかCとかのマイクロソフト組や高級言語しか経験のない組が、近年JSerの中に混じってきて、そいつらのhtml/cssの無知っぷりが凄まじい。彼らはwebやろうとしてるのに、html/css知らなくても通用すると思ってるところがとても素敵。
Re:10
主です。詳しくありがとうございます。
やっぱりそうですよね。jsとcssに両方レイアウト要素があると管理が煩雑になるなって思ってたので納得しました。（jsわからん人にはなんで上書きされたかわからんかったりするし）
Re:12
低級言語の経験者の方が圧倒的にwebは稀だと思うが
Re:14
低級言語の話はしてなくてだな、極端に言うと、TypeScriptしか知らないような人がいるってことよ。
Re:7
一番の害悪はこれよ。
document.getEelementById("hoge").style.marginTop="10px";
インラインスタイルでの指定にも似てるけど、こんなの量産して誰がどうやってスタイル管理するんだろうね。
CMSの管理画面にカスタマイズが発生すると、インラインかstyle要素で書いちゃうな。
スクラッチなら、管理画面側も、一定のデザインスキームでCSS書かないといけないんでしょうが。
Re:9
どう考えてもclassの付け替えの方が良いと思うのだが今てそんな流れなの？
Re:19
フロントエンドと言ってもかなり幅がひろいんだけど、おそらく一般的にフロントエンドというと、JSerの領域を指すと思うよ。つまり、html/css/jQueryコーダーの領域ではない習慣の話になるんだけど、そもそもhtml/cssはすべてJSから出力する手法というのがあってね、その場合は、css(sass/less/stylus)ファイルを直接編集するということがないから、JSから管理することになるのよ。そうなると、classの切り替え以上に効率のよい方法ができるから、実質、classの切り替えの出番はなくなるよ。