きれいなソースとそうでないソースの具体的な違いってなんですか？要素に規則性を持たせるとか、一つのdivに複数のclassを指定するとか、とにかく具体的な違いを知りたいです(特にhtmlとかcss,javascriptのフロント周りで)。あとここのサイトのソースがきれいだから参考になるよ、っていうのがありましたらそういうのも教えていただきたいです。
合理的かどうかじゃない？複数classだって、一つずつ役割があるから複数なんだし。
わかりやすいところでいうと、Wordでつくった(Webページとして保存)HTMLを見ればわかる。人間には理解不能。不必要なコードがほとんど。きれないソースとは、どんなにわかりやすく、シンプルにまとめられているかということではないかと。冗長的に書かれたコードは、管理するのも大変だし、綺麗には見えない。
margin padding width hightで書くのが好きだけど、参考リンクみたいなやつもある。displayが一番上とか、自分的には好みじゃないしなぁ…
オリジナルでも書き順が統一されていれば、キレイと言えるんじゃないかな、とか
あと、無駄なものは書かないのも…。難しいけどね
好みに口出すわけじゃないけど、javascriptを使うとdisplay:noneのタグが頻繁に出てくるから、ひと目でそのタグが初期状態で表示されてるかどうかを把握できるかは結構重要。
誰にでもわかるを考えるとアルファベット順が一番わかりやすい。独自ルールは何時でも独自。
gzip圧縮することを考えるとcss combがソートする順がベストじゃないかな
コードがきれいとかを気にするのは制作者だけコードがきれいなほど制作料金が上がるならきれいなほうがいいがお金を出す人もユーザーも表面しか見ない。
個人的には、検索エンジンからペナルティを受けないことだけ気をつければよいと思ってる。あくまで個人的な感想ですが・・・
ちなみになんでこう思ったのかというと超有名なサイトで同ページにH1タグが複数使用されていたのだがコードに間違いがあっても人から必要とされるサイトはやっぱり上にいるんだよねこういうの見てたら細かいこと気にするよりもユーザーに使いやすいUI等に力を注いだ方がいいと思ったね。
SEO的に見てもh1は普通に複数使用できる
そもそもコードの綺麗さとSEOに関係ないってGoogleさんが言っちゃってるし、なにをいまさらというか。
HTML5だったとか？
時間的な制約もあるから、できるだけ時間内に機能を盛り込むことが優先で、コードの綺麗さは後回しかな。納品前に余裕があったら整理はするけど。個人的な意見だけど、Webを仕事としてやっている以上、コードがキレイだけど、機能が足りない（中途半端な出来）なものよりも、多少コードが読みにくくても機能が補完されているものを提供したい。
コードがキレイだとユーザーに何かメリットがある（表示や処理が早くなるとか）なら考え直すけど、結局は作り手の更新や引き継ぎの手間を省くためのコードのキレイさだし。
ほぼ自分ぐらいしか更新しないサイトで、「誰にでも分かるようなコード」を書いても労力の割にメリットがないとも思う。
メリットデメリットよりも制作者の矜持なのかもしれない。
1ミリ秒でも早くロードさせることと、アクセシビリティを意識したら自然と綺麗になっていくと思うけど？イマドキSassの@extendなんかで共通部分はいくらでも節約して書こうと思えば書けるし。何より綺麗に作らないと後々手間増えるんだから製作者なら先々に無駄な工数出さないように努力するのは当然では？外注先とか決めるときは当然ですけどソースの綺麗さとか命名規則とかがいい加減じゃないところにするよ。ヘッダーだろうがフッターだろうがclass="box01" class="box02"とかやっちゃうところとか論外だしｗ
class="box01" の何が悪いのか知りたい。
「ヘッダーだろうがフッターだろうが」、これはやはり分かりにくいですよ。管理上よろしくないと思います。
何でもかんでも「box」は良くないだろうけど、逆に何でも名前つけりゃいいってモンじゃないとは思う。一時期スタイル名は内容じゃなくて役割でつけるみたいなのが流行ったこともあったけど、今は必ずしもそうじゃない気がする。OOCSSという考え方もある。汎用的な部分と、そうじゃない部分の切り分けを考えていく必要があるのでは。んで汎用的な部分は名前に特長ない方がいいんじゃない？タグで言うと、headerとsectionの違い、みたいな。
例えば、「.companyTable」みたいなのTableタグ用のスタイルが、全く関係ない別のページで流用されてたら少し気持ち悪いし、かとプロパティが同じ場合に、「.companyTable,.formTable{}」っていちいち書いて行くのも、複製したもので「.companyTable{}.formTable{}」ってするのも、どっちもスッキリしない。だったら「.tableStyle1」とかのがいいんじゃない？
↑それもスマートじゃないよね。だったら<table class="company">で、cssは.companyに基本的なものを記述してcss側でtable.company{}とかtable.formってやって記述にして不足箇所を補ったりオーバーライドすればいいでしょ。なんだよ.tableStyle1って（笑）だったら <table class="company style1">にしてstyle1は寄せておけばいいでしょ
そもそも、高速化とアクセシビリティの向上とコードの綺麗さは関係ないだろ
最近は綺麗にコンパイルしてくれるツールゴロゴロあるし、時間の節約なんかの効率を考える方がいいのでは？
みんなの回答 7 件
合理的かどうかじゃない？
複数classだって、一つずつ役割があるから複数なんだし。
わかりやすいところでいうと、Wordでつくった(Webページとして保存)HTMLを見ればわかる。人間には理解不能。不必要なコードがほとんど。きれないソースとは、どんなにわかりやすく、シンプルにまとめられているかということではないかと。冗長的に書かれたコードは、管理するのも大変だし、綺麗には見えない。
margin padding width hightで書くのが好きだけど、参考リンクみたいなやつもある。
displayが一番上とか、自分的には好みじゃないしなぁ…
オリジナルでも書き順が統一されていれば、キレイと言えるんじゃないかな、とか
あと、無駄なものは書かないのも…。難しいけどね
記述する順番を考慮したCSSの書き方
http://css.microrza.com/csstips/css_order/コードがきれいとかを気にするのは制作者だけ
コードがきれいなほど制作料金が上がるならきれいなほうがいいが
お金を出す人もユーザーも表面しか見ない。
個人的には、検索エンジンからペナルティを受けないことだけ気をつければよいと思ってる。
あくまで個人的な感想ですが・・・
時間的な制約もあるから、できるだけ時間内に機能を盛り込むことが優先で、コードの綺麗さは後回しかな。納品前に余裕があったら整理はするけど。
個人的な意見だけど、Webを仕事としてやっている以上、コードがキレイだけど、機能が足りない（中途半端な出来）なものよりも、多少コードが読みにくくても機能が補完されているものを提供したい。
コードがキレイだとユーザーに何かメリットがある（表示や処理が早くなるとか）なら考え直すけど、結局は作り手の更新や引き継ぎの手間を省くためのコードのキレイさだし。
ほぼ自分ぐらいしか更新しないサイトで、「誰にでも分かるようなコード」を書いても労力の割にメリットがないとも思う。
メリットデメリットよりも制作者の矜持なのかもしれない。
1ミリ秒でも早くロードさせることと、アクセシビリティを意識したら自然と綺麗になっていくと思うけど？
イマドキSassの@extendなんかで共通部分はいくらでも節約して書こうと思えば書けるし。
何より綺麗に作らないと後々手間増えるんだから製作者なら先々に無駄な工数出さないように努力するのは当然では？
外注先とか決めるときは当然ですけどソースの綺麗さとか命名規則とかがいい加減じゃないところにするよ。ヘッダーだろうがフッターだろうがclass="box01" class="box02"とかやっちゃうところとか論外だしｗ
最近は綺麗にコンパイルしてくれるツールゴロゴロあるし、時間の節約なんかの効率を考える方がいいのでは？
関連するトピックス