  |
はてなキーワード: スタイルシートとは
あのさ、HTML+CSSっておかしいんだよ。もちろん表でしかないtableでレイアウト組むのがもっと変だけど、スタイルシートでデザインってのも所詮ワープロのスタイル機能でしかないわけで。
GデザイナーにMSWordでかっこいいフライヤー作ってくださいって言ったらすっごい嫌がられるでしょ？ボク忙しいからポータルZの挑戦ネタはよそに頼んでよって。
それはマイクロソフトに恨みがあるとか使いたいフォントが無いとかそういう脇の理由じゃないんだよね。
自由に使えないから。自由なデザインはヘッダーとか見出しとか本文とか勝手に決まってないから。デザインを思いついてそれをWordの形式に再解釈しないといけないなんて二度手間はおかしいでしょ？
そう、Webでは未だに表現作業の大部分がUIで処理されずコーディングとして外部に残ったままなんだ。これは汎用メディアとしては失敗だとはっきり認識しないといけない。
そういう意味では抽象概念でなく「見たまま」のtableが妙に粘っているのも理解しやすい。
あまつさえ構造化された内容とデザインを分離したって、実は最初っからデザイン否定なんだよね。
上手いとか歴史に残るデザインってのは内容を表していたり複雑な関係をデザインで一つにまとめたりと抽象化とか還元とかそういう作業をして「きれい」「テーマがわかりやすい」「印象深い」ってなるんだよ。だからCSSとか策定してる人たちはデザインを理解していないんだとおもう。
あくまでWebの仕組みはワープロで、ワープロでできる範囲で見栄えよくするにはアレコレソレの工夫がある世界。
あまりにも出来が悪いからデザイナーが1日掛けて絵を起こしてHTML技術者が1日掛けてワープロのスタイル機能で全部表現しなおそうとしてる最初から失敗した世界。
プログラマ崩れでない素のデザイナーというのはセンスは良くてもあまりオツムはよろしくない。弁も立たない（黙ってるか意味不明のことを叫ぶか）。だからネットであまり発言しないが、問題はそびえたつクソのように巨大だと思う。
めも。
HTMLに見た目を指定することを書いてはいけないとよく言われるが、それだけでなく、user agentの動作を指示することにも慎重でなければならない。動作を指示する記述とは、例えばtarget属性や、HTML 5のlink typeのprefetch、sidebar、nofollowなどのことである。
これらがあまり有用でないのはuser agentに柔軟な対応をとる余地を与えないということが一番の理由である(当然ながらuser agentにはIEやFirefoxなどの「ウェブブラウザ」だけでなく、検索エンジンのロボットやダウンロードツールなども含まれる)。target属性について考えよう。あなたは何故そのリソースを新しいウィンドウで表示して欲しいと思うのだろう。自分とは違う人や組織によって作成されたリソースだからだろうか。ならば「自分とは違う人や組織によって作成されたリソースだ」と書くだけで良い。user agentは新しいウィンドウで表示するかもしれないし、「別の人によって作成されたリソースです」とアラートを出すかもしれない。あるいは本文と平行して見るべき図だからだろうか。ならば「本文と平行して見るべき図だ」と書くだけで良い。user agentはユーザの設定によって新しいウィンドウで表示したり、サイドバーに表示したりするだろう。「sidebar」についても同じようなことが言える。サイドバーに表示して欲しいのは何故だろう。もしそのリソースが目次ならば、目次と書くだけで良い。(「nofollow」がおかしいというのはHTML 5を策定している人たちもわかっていて、ただ互換性を考慮したようだ。しかし、厳密に言えば、"nofollow"はlink typeとして実装するべきものかどうか疑わしい。一例ではあるが、私のようなiTunesユーザなら、<a rating="0">などと書くことも容易に思いつくだろう)
このように、著者は自分が望む動作ではなくその動作を望む理由だけを書くのが理想的なのである。
付け加えれば、<a href="javascript:...">という記述も不適切だ。これはしばしばJavaScriptが無効な環境にあるユーザに混乱をもたらすとして批判されるが、一番の問題はスクリプトのスイッチは論理的にはリンクではなくボタンだということだ。これはtarget属性や不適切なlink typeでリンクの動作を規定しようとすることと同じ誤解が原因だと思われる。リンクは原理的に動作のスイッチではなく、あくまでリンクなのだ。従って、見た目でそれがa要素かbutton要素かを決めるべきではない。見た目はスタイルシートで指定しよう。
理想的には、クライアントサイドスクリプトも今ほど必要ではないのかもしれない。HTMLのフォームの仕様とuser agentのUIがここまで貧弱でなければ、今日我々がスクリプトでやっている、合理的で、ただの飾りではないことの90%以上はHTMLだけで記述できるのではないだろうか。ウェブのバージョンがいくつになればそれが可能になるのかはわからないが……。
画像とか動画とか音声とかにHTMLを埋め込むことができたら楽しそうじゃね? HTMLに画像や動画を埋め込むんじゃなくて。逆に。写真やイラストを展示するサイトでありがちなのが「リンクはHTMLにお願いします」ってやつで、画像に著作権表示とかコメントとかを添えるには現状そうするしかない。でもやっぱり画像そのものに書き込みたいだろうし、リンクするほうもリンクしたいリソースは画像そのものであって、「おまけ」のほうではないんだよね。俺も友達のバンドのサイト作ったことがあるんだけど、MP3のタグじゃ貧弱だし、ハイパーリンクも使えないし。そういうのもうある?
あー！ なるほど！ そういうことか。
文中に*つかってないよ。 ほんとに記だからね。
スタイルシートでびじぶるもディスプレイも弄った記憶がなかったのでテーマによって反映されないんだとおもってたよ。
文中*で初めてでてくるのね。にゃるほど。
スタイルシートをさわらないと消せない
↓
消しているのはスタイルシートさわっている人
↓
自己責任で消したんですよね？
↓
ってことか？
スタイルシート一つで消せるようなものなのだから、
はてなは設定に消す機能ぐらい簡単に置けるはずなのに置いてない。
公式サイトでどしどし文句を言ってくるような人以外には、
消せることだって気づいて欲しくないと思ってるんでしょう
俺はそこが問題だと思ってる
明らかにわかっててやってるところが汚いというか
確かにそれはあるだろうね。
囲い込んだユーザすべてに機能を実装すれば、一気にある程度のシェアをもてて、その一部が使えば周知された新サービスとなれる可能性は大きい。
でも、その考え方は営利企業として当然じゃないかな？
それが問題だと言うなら他のブログに行けばいいと思う。
はてなのブログの機能がいいからはてなに居る訳で、嫌なら他に行くのは今回に限ったことじゃない。
今回の反対派の問題点は、新サービスのリリースに問題があると言うよりも、自分が気に入らないからと言う内容の反発にしか見えない事だと思っている。
営利企業としてこれはやっちゃ駄目だろ的な反論があればよろしく。
http://anond.hatelabo.jp/20070712164506
スタイルシート一つで消せるようなものなのだから、
はてなは設定に消す機能ぐらい簡単に置けるはずなのに置いてない。
公式サイトでどしどし文句を言ってくるような人以外には、
消せることだって気づいて欲しくないと思ってるんでしょう
俺はそこが問題だと思ってる
明らかにわかっててやってるところが汚いというか
http://anond.hatelabo.jp/20070712163744
http://anond.hatelabo.jp/20070712163817
http://anond.hatelabo.jp/20070712164126
今までどおりやれますけど。何が問題なんでしょうか？
現にスタイルシートの設定で出ていない人が居ます。
http://anond.hatelabo.jp/20070712164728
星が全く見えなくてもまだ問題があるようならトラバよろしく。
そこまで来ると何がまずいのか逆に興味あり。
それは一般的には sendmail の900何バイトで強制改行問題を回避するための仕様だと思うが。見やすさを実現するために自動改行するMUAというのが存在するのであれば、後学のために教えてほしい。
これはまだスタイルシートが普及する前、ブラウザのサイズによって見栄えが大きく変わってしまう問題があって、その回避策として大体７０文字８０文字（あるいはサイトのデザインポリシーに準拠）で改行するようにすると言う物があった。
ああ、それか。俺はそれに反対する立場で、ことあるごとに否定していたし、今も認めていないので、マナーとして確立したなどとはまったく思っていない。
判りやすい事例として、某掲示板で長文発言を改行無しでしてみよう。
掲示板文化においては、本文をpre要素で表示する暗黒時代が結構長かったから、今でもそれを引きずっているとすれば分からないでもない。
某掲示板はよく知らないが。
http://anond.hatelabo.jp/20070317135224
一部MUAのように引用領域の左端にタテ傍線がつくとかもじら表示系のように単にインデントされるとか
そんな君のためのスタイルシート
<style type="text/css"> blockquote { border:none; padding-left:20px; background-image:url(/images/common/icon-arrow.gif); /*なんか＞な画像*/ background-repeat:repeat-y; } </style>
あれ、もしかしてここに書けば効く様になるのかな？
てすとてすと。
<style type="text/css"></p> <p>blockquote {</p> <p>border:none;</p> <p>padding-left:20px;</p> <p>background-image:url(/images/common/icon-arrow.gif); /*なんか＞な画像*/</p> <p>background-repeat:repeat-y;</p> <p>}</p> <p></style>
先日「target="_blank"として別窓で開かせたほうが良い。Strict DTDにtarget属性が無くて困る」と言い出した人がいて、ひどくがっかりした。表面的にはちゃんとしたHTMLを書いてる人だっただけに。
それはauthorではなくuserやuser agentの仕事だろう。authorがやるとしても、HTMLではなくスタイルシートに書くのが筋だ。別窓とtarget属性を混同してはいけない。
もっとも、その人が混同してしまった原因は我々にもある。ユーザビリティやアクセシビリティの問題とHTML的な問題とをごちゃまぜにして説明していた。
正しいHTML方面の人の書いたHTML入門にあまり良いものが無くて、根本的な「思想」(大げさな言い方で、好きではないのだが)の部分がしっかり伝わるものを自分で書こうと思って、書き始めてみたのだが、どうも一般人に通じるとは思えなくて、自信を失って破棄してしまう。プログラマに通じれば良いということにすれば簡単だが、それなら既にあるもので足りるわけで。
スタイルシート ソース理解クイズ - ［ホームページ作成］All About
まあ「仕様書で規定されていない部分については、IEおよびFirefoxの実装に従うものとします」などといった注意書きをもっとしっかりつけてくれれば大体は間違ってない。
しかし、Q7に関しては明らかに間違っている。選択肢の中に正解がない。
'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + scrollbar width (if any) = width of containing block
CSS 2.1では通常フローにあるブロックレベル非置換要素の幅の算出に上の等式が使われる。しかし、問題の例では、この等式の左辺のすべての項がauto以外の算出値を持っている。この状態を「制約しすぎ」（over-constrained）であるといい、（包含ブロックのdirectionプロパティの値がltrならば）margin-rightプロパティの指定値が無視され、上の等式を基にmargin-rightの値が再計算される。よって正解は「包含ブロックの幅に等しいピクセル数」だ。
それから、Q9にも大きな不備がある。「同じ位置」「移動する」と回答中にあるが、これらが何に対してなのかが明言されていないのだ。固定配置の要素はスクリーンメディアにおいて、表示領域に対しては同じ位置にあるが、通常フローの要素に対してはスクロールに応じて移動するといえるので、このままでは正解をひとつに絞りきれない。
パラグラフはパラグラフだから、見た目が読みにくいと思ったらユーザースタイルシートでどうにかするべきだろ。もしくは自分のブラウザの幅を小さくして、自分で読みやすいようにするべき。
と、原理主義っぽく書いてみたものの、実際は増田を読んでる人の環境も多種多様だから難しいのだろうな。増田の過去にはこんなのも。
http://anond.hatelabo.jp/20060927022345
SXGAで画面幅いっぱいにブラウザを開いて増田を読んでる人もいれば、縦QVGAな携帯電話のフルブラウザで読んでいる人もいるだろうし、高解像度の画面で文字を大きくして読んでいる人もいるだろうし、低解像度の画面で文字を小さくして読んでいる人もいるだろう。
固定幅がいいのか可変幅がいいのか、という点とかもあろうけど、IEも7.0になるんだし、はてなの方でmax-width使ってくれればOK？
たとえば www.hatema.jp とかとって、そこにログイン画面作ってフィッシングサイトを作る。
捨てアカとって、JavaScriptつかってリンクがそこへ飛ぶ様にしておくエントリを書く。
http://anond.hatelabo.jp/20061227145016
使いやすいからJsってだけで、悪意をもって振舞えば別にJavaScriptつかわないでも現状のもと実現できるよね。
まちちゃんの可愛いところはマグロの解体ショーを人前で実践してくれるところ。
切り身のトロがメバチマグロなのか黒マグロなのか気にせずにショーとして楽しめるところ。
そもそも今回はJsなんか使われてないよね？
クライアント側に何をするのかより、サーバー側になにをするのかだと思うんだ。
鍵をいくつもつけまくるのは確かに抑止力にはなる。だけど不便じゃない？
いろんなブログパーツがあるけどはてなでは自由に使えないじゃない？
<a href="javascript:alert('こんにちはこんにちは！');">マグロの解体ショー</a>
こんな簡単なスクリプトからcss/expression()まで弾くぐらいJsをガチガチにブロックしている理由はさすがに少し技術的な固執じゃないかなと思う。スタイルシートをタグに適用するのも禁止とか……。
そのわりに肝心なアカウント認証の部分が緩いからこういうことになるんじゃないかな。
ドアには普通の鍵でいいから金庫の鍵だけはもうすこししっかりしてねという所感。
特にブログなんて公開するためのものだから、お店のドアが鍵だらけっていうのもどうなのかな。
金庫室って書いた鍵の緩いニセのドアを設けてそこを開けたお客さんをマークしておくとかすればいいと思うんだ。
戯言。
