ADの日記: オーサリングツール云々 11
WYSIWYGなHTMLエディタは駄目です。何年たっても駄目です。なぜなら潜在的にWISIWYGなオーサリングツールのほうが手間がかかるから。某ビルダーは昔よりマシなソースを吐いていますが、WYSIWYGが必要なのはCSSエディタ、及びそのサポートプログラムとしてHTMLの要素にCLASS属性を入れるオーサリングツールなわけで。(中略)であるから、最低限度の文書構造も意識させずに駄文を養殖するWYSIWYGなHTMLエディタもどきは腹を切るべきである。【どーやって?w】
初心者が使うべきオーサリングツールってのは、Wikiのようなものでいいと思う。文書構造のお勉強をしてからの話だけれど。
実際に、私がHTML文書をマークアップする時間は短い。例えば段落の始端に*を置き、段落の終端には;を置く。それを開始タグと終了タグに置換するだけで、ほぼ80%のマークアップが終了する。予めヘッダなどを備えたHTML文書の雛形を使用しているため、タイトルの変更などの少量の記述でHTML文書が完成する。私がマークアップにかける時間は、WYSIWYGなエディタを使ってHTML文書を作り出す人間のそれと比べて格段に短い。
HTMLで普段用いる要素って、
- H?要素(見出し1~6)
- P要素(段落)
- EM要素(強調)
- UL要素(リスト)
- LI要素(リストの中身)
- BLOCKQUOTE要素(引用)
程度だと思う。初心者は殆ど使わないだろうと思うBLOCKQUOTE要素を入れても、たった6種類。これの何処が難しいのであろうか。HTMLが難しいとすれば、それは不思議マークアップのによるものだと思う。あなたは6種類のタグの意味とタグの書き方を覚えるのと、WYSIWIGなエディタの使い方を覚えることのどちらが楽ですか?──とスクリプトやテキストエディタでHTML文書を作ってしまう人間からすれば思うのですが。
如何なるオーサリングツールを使おうとも、中の人が文書構造を指定しないとならないわけで。その点を踏まえるとWikiのように特定の記述からHTMLの要素を補うシステムがオーサリングツールとしては正しい姿のように思う。
楽をしたいのが人間であるというなら、WYSIWYGなHTMLエディタは非人間的である。それと、WYSIWYGなHTMLエディタが行うべき処理は、見た目をそのままファイルに落とし込むことではなく、見た目から読み取れる文書構造をそのままファイルに落とし込むことである。これが如何に機械的処理として難しいかは言うまでもないだろう。だ~か~ら~、WYSIWYGは駄目だと(略)
因みに、某ビルダーのレクチャーを頼まれたから愚痴っているのは秘密だ【謎】
[追記]A要素、IMG要素、ついでにABBR要素を入れても9種類。それでも感覚としては、新しく9個の漢字(記号)とその意味を覚える程度かと。
Re: HTMLで普段用いる要素 (スコア:1)
a要素を忘れないで下さい(w あとimg要素 (若しくはobject要素) も。
# abbr要素を大量に使う私は変態なんでしょうねぇ。
Re: HTMLで普段用いる要素 (スコア:2)
あー、そういえばそんな要素もありましたねぇ(ぉ) ピュアに抜けてました。
ページを作ってて思うのですが、IMG使うにも画像を用意するのが惰性で延長10回【謎】な状態である私がIMGの存在そのものを意識から消去していた可能性が高いですw
abbrは私も乱用したいのですが、同じ単語に何回も使うと怒られることもあるのが不思議。TITLE属性なんぞメタ扱いだと思ってるので、何個あっても困らないと個人的には思ってるんですけどねぇ
とりあえずツッコミありがたうです^^
--労使曰く、ひとごとを尽くして神頼み--
<OL>がないのはなぜ? (スコア:1)
通りすがりのものです。興味本位なのですが、過渡期にある天国 [srad.jp]にて、<OL>をつかわなかったり親の日記エントリーに<UL>はあるものの、<OL>が挙がっていないのは何か理由があってのことなのでしょうか。
Re:<OL>がないのはなぜ? (スコア:1)
『過渡期にある天国』でULを用いているのは、その後に「1番目、2番目、3番目」という記述をしているためです。OL内部のLIのレンダリングは「1.2.3.…」のようなものばかりでなく、「a.b.c.…」や、「い.ろ.は.…」なんてのあり得ると思われます。レンダリングが「a.b.c.…」のような場合、迂闊に「1.は~」と書いてしまっては間抜けなことになります。一応「1番目は~」という言い回しですが、あの内容には本質的に順序にあまり意味はなく、特定行を指定できれば事足りたので、苦し紛れな感じですがULに「1:、2:、3:」のような記述をしました。
しかし、今思えばあれはOLでも良かったような気もしないでもないですw 一応、言い回しに気を使っていたみたいですし。あのような書き方はよろしくないかもw
あと、良く使う要素にOLを上げなかったのは、初心者が順序に意味のある列挙体を用いる機会は少ないと思ったためです。HTMLを知っている人でも、厳密にOLを用いなければ不自然な場合はそれほど多くないような気がします。むしろ、ULなら自然だが、OLでは不自然な場合も多いかと。
まあ、傾向的にリストはULのほうが良く使うと思います。良く使う要素として敢えて挙げなかったのではなく、挙げるべきか微妙だっただけです。私的にw
--労使曰く、ひとごとを尽くして神頼み--
勘違いでした ごめんなさい (スコア:1)
<OL>のデフォルトの順番付けは「1, 2, 3, ...」である、という思い込みがあったのですが、調べに行ったら [w3.org]、デフォルトはなくて、ブラウザー依存なのですね。
自身で<OL>や<UL>を多用するのと…、いや多用する、はおかしいですね。使うべきところで使うし、/.-Jでの書き込みの制限には大きな不 [osdn.jp] 満 [osdn.jp]があるくらいなので、リストのことを知っているつもりでいましたが、完全に勘違いな突っ込みでした。
おっしゃる通り、「過渡期にある天国」では後段での参照があるので、番号を<UL>で番号を振るのは、<OL>でtype指定ができない/.-Jの仕様から正しいと思います。
# ただ「1, 2, 3, ...」が『事実上』デフォルトだとは思いますが。(まだ言うかぁ!! > 己)
「よく使う要素」が初心者対象であるなら、<OL>を除外するのはリーズナブルに思います。もし私が初心者にHTMLを教えるとして、<OL>を外すその理由は、<UL>よりも<OL>の方が利用頻度が相対的に低いと思われるから、という単純な理由になるでしょう。
え~、そもそも私の勘違いが発端に、長くコメントをいただきました。どうもありがとうございます。
Re:勘違いでした ごめんなさい (スコア:1)
いえいえ、変態的な書き方をしていたのは間違いないですし、お気になさらず^^;
書き込み制限といえば定義リスト一式のほかに
とか、ちょっと不便ですよねぇ。
まあ欲をいえば、ValidなHTMLソースにして欲しいんですがw
--労使曰く、ひとごとを尽くして神頼み--
Re:勘違いでした ごめんなさい (スコア:1)
ええ、仕様制限されているタグが多いですね。制限をする理由もわかるし、こういうシステムを無料で用意してくれていることに感謝もしているのですけれど、もうすこし緩めて欲しいなというのが正直な感想です。
ADさんの日記を拝見すると、HTMLに対して確たる物をお持ちのようですし、バグレポートやFeature Request [osdn.jp]をしていたけないでしょうか。私がRequestを書いても、せいぜい「使えると便利でしょ」レベルではなかなか(改訂|運営)側の共感を引き出せませんけれど、ADさんだったらうまいことが言える、そんな気がします :) 。
バグレポートは、パッチを送れればそれが最高なのでしょうけれど、ここがおかしくてこうあるべき、ということを指摘だけでもしておけば、いつかは対応してくれるかなと(改訂|運営)側に淡い期待をしているので、私は暇な時にぽつぽつ投げています。invalid HTMLの指摘もきっと歓迎されると思うんで、お暇でしたらぜひ。
# 私がお願いするのも変かもしれませんけれど…
Re:勘違いでした ごめんなさい (スコア:1)
第一に、slashdot jp運営側の意思としてHTMLをValidにする意思があるか、ということが最大のポイントになってきます。製作者がHTMLの利点を理解し、Validすることを選択するのでなければ意味がありません。私には、製作者にHTMLをValidにする意思がないのに無理強いをするのは不可能です。
第二に、slashdot jpのシステムは仕様であって、厳密にいえば製作者の意図どおりの動作であり、バグではない可能性があるということ。HTMLのみの観点からあるシステムを批判するのは少し危険であるといわざるを得ません。
第三に、私がslash codeを記述できる製作者ではないということ。採用されるか否かを別にしても、仮に私が書くとすればある程度の時間を必要とします。私はcodeを書くことを確約はできません。故に製作者にとっては無責任な発言に感じられると予測されるということ。また、私が、自分の発言をslashdotのシステムとして実現する直接的な実行力が事実上ないということ。
上記に挙げた3点を理解してくれるのなら、Requestはしてみたいと私は考えます。
例えば、HTMLの観点から見て仕様的にバグであると思われるのはBLOCKQUOTE要素の扱いです。slashdotのシステムではBLOCKQUOTE要素のCITE属性が消されてしまいます。BLOCKQUOTE要素のCITE属性が消されるということは、BLOCKQUOTE要素が正当な引用を成さない可能性があります。なぜなら出展を明示できないからです。また、それを補うであろう出展を表すCITE要素がないのも問題ではあります。(そのためユーザが文脈上で出展を表していると思われます。)
BLOCKQUOTE要素のCITE属性の実装については、A要素でHREF属性が許容されていることから、それの応用で可能な範囲であると考えます。
slash codeの問題もありますが、私はCSSも正すべきであると思います。仮にBLOCKQUOTE要素のCITE属性が実装されたとしても、IEのデフォルトレンダラは、CITE属性を利用しません。もしCITE属性を許容するのであれば、現実的対処として出展URIをBLOCKQUOTEに付加してレンダリングするCSSを設定すべきです。云々。CSSならサンプル投げることも可能だ云々。
空気が読みにくいのが難点なのですが、Requestは投げてみたいと思います。(バグか仕様かは微妙なのでリクエストが一番適切でしょう。)
--労使曰く、ひとごとを尽くして神頼み--
気楽に投げたら良いと思いますよ (スコア:1)
どうもこんにちは。返信ありがとうございます。
どうか悪い方に取らないで欲しいのですが、いただいたコメントを読んで、少し考え過ぎでヘビーじゃないかな、と思いました。気楽に投げたらいいと思いますよ :) 。
運営側でなく、一利用者である私がADさんの質問(懸念)に答えられるわけではないですけれど、validにする気はあると思いますよ。ただし古いブラウザーへの配慮であえて正しくない、もしくは美しくない記述を変えられないところもあるようです。
きっとADさんの考え過ぎです。対外的に明示していなくても、意図的にinvalidな記述をしている部分もあるでしょうが、それを指摘することは決して批判にはなるはずがありません。また意図を汲んだ上での指摘や修正提案は、そうでない場合に比べて、よりよいものになるのではないでしょうか。
codeはパッチと読み換えてもいいですか。パッチを送れば、バグがつぶされたりリクエストが実現するまでの時間がより短いのは間違いないでしょうけれど、パッチの作成は必須ではありません。できる人ができる範囲(時間を含む)でレポートなりリクエストしたらいいと思います。
ADさんと私とで/.-Jに持っている印象が違うのは当然なので、バグレポートやリクエストすることへの気持ちの持ち方が違うのも当たり前なのですが、それでも考えすぎているように思います。
「開発者:こんなの作って便利だと思うから公開するよ → 利用者:ここおかしいよ → 開:これでどう」といううまいループが成り立っている(ことが多い)、フリーウェアやオープンソースのコミュニティーに属している人がここにはたくさんいますし、責任者のOliverさんもその一員だと思いますから、真っ当な指摘を受けてそれを非難ととることはないでしょうし、実現するかはともかくとして、まじめなリクエストはすべて歓迎されると思います。空気を読む、なーんて必要はないですよ。
Re:気楽に投げたら良いと思いますよ (スコア:1)
あー、いや、申し訳ない^^; 特別ヘビーにとらえてるつもりもないんです。SOggyさんを困らせるようなことをいって申し訳ない。
Web上には様々なコミュニティーがあり、そろぞれのコミュニティーの意思を尊重せねばならない。それは、過去のHTMLにまつわる騒動にて思い知らされているのです。HTMLの話題で指摘する場合、HTMLに興味のないコミュニティーの方々が不快な思いをされるのなら、しないほうがいいと思っているのです。HTMLの思想はWebを便利にする付加価値にすべきであって、他人を不快にする言い争いの元にはすべきではない──と思うだけなんです。それが「ヘビー」に感じられるのかもしれませんがw
HTMLみたいな道具の話をする人間は、すこし他の人間のことを疎かにしている節があります。だから、少しでも意識的にならなくては、と足掻いているのですw まあ、少し神経質に見えるかもしれませんが、本人はいたって気楽ですので、ご安心を(何)
StrictなHTMLを信仰(?)している人間には、HTMLの正しさのみに捕らわれ、コミュニティーの意思を軽視するような方が極稀に見られます。それは、独善的で、排他的で、閉鎖的で、他人に受け入れられる思想の表現ではありません。私は、そうなりたくないだけなんです^^; 要するに必要とされないなら素直に帰りますw
リクエストすることは、私にとっても利益になり得ることです。よって今すぐ勢いに任せて気楽に投げ捨ててきたい(何) しかし、リクエストが悪いパターンに嵌ってしまわないか不安なだけでw
私は基本的に気楽な人間ですが、根の気楽さを自重するように心がけておりますw わかり難い書き方ですいません(T
まあ、実際のところリクエストを言うだけ言っても、実現するだけの実行力がない自分が歯痒かったりw
--労使曰く、ひとごとを尽くして神頼み--
/.-Jなら気楽に投げたら良いと思いますよ (スコア:1)
どうもこんにちは。コメントを書くにあたって慎重にはなりましたけれど困りはしなかったです。お互いがお互いの経験や背景を知らないので、安全側に倒して書いたほうが良いかなと。私を困らせたと感じたのなら、悪い方には転ばなかったみたいですね :) 。
さて…。なるほど、指摘してコミュニティーに騒動が起きることがありますね。特に文字だけのやり取りだと、話がこじれやすいようで。そういった点から、いっそう慎重になる、または慎重でいようとする心構えはよくわかります。
私の日記を見てもらえればわかりますけれど、/.-J日記ではタグ本来の意味から外れた用法でインチキしまくっています。タグの制限はきついし、CSSも指定できない現状で、(後から見直す自分が)なるべく読みやすく使いやすいようにしようとしている結果なのですけれど、これらの制限にはすごく不満があります。ではどうするか。レポートやリクエストをしかるべきところに出して改善をお願いするか、だまって我慢するか、出て行くか、の三つでしょうか。現状で私は第一の戦略をとっているわけです。
/* 日記に「バグレポしたら」とコメントをもらったのがきっかけなんですけれどね。投げて鬱憤をはらしているというところもなきにしもあらず。 */
バグレポやリクエストをするにしても、権威ある裏付けや実施後のメリット、具体的な改善されたコードがある方がきっと通りやすいですよね。レポートやリクエストをしてくださるようお願いしているのは、strictやvalidという言葉を散りばめた日記を書いているADさんをたまたま日記で見て焚き付けているわけです。
/* はじめからこれを意図してコメント [srad.jp]を書いたのではありませんよ、これは本当に。strictと書いていているのに<OL>しないのはなぜだ、という単純な疑問からです。これは結局私の勘違いだったわけですが。 */
焚き付ける、は言葉が悪いかも…。ADさんが提案を出すなら、修正の方向はきっと私が/.-Jに期待している方向に向かっているだろう。そして私がレポートする物よりも早く通りやすい物をADさんが出してくれるのだろう、というわけです。あは、言葉が悪い上に自己中ですね。
何度かレポートとリクエストを出して、いくつかは忘れた頃に改善をされました。いずれもお気楽に投げています。気楽に投げていいと思いますよ、/.-Jなら。私の^H^H/.-J利用者全員のために、気楽に投げてください。お願いいたします。