XSLTをWebプロダクションレベルで普通の技術にするためには(?)
@koba CSSは未知のものを無視すると仕様で明示されているのでinvalidでも問題ない。HTML4/XHTMLはDOCTYPE宣言の都合上invalidだが、text/htmlである限り現実的にはどうでもいい。
2010-02-24 21:30:01@neotag まさしく「手軽」てとこがネックなんだろうなー。セマンティクスってのがどうにも曖昧だけれども、データの意味とか表現のための無駄タグとかその辺の意味であるなら、結果的に(ユーザなりGoogleなりに)評価されるのが元データなのか出力データなのかって辺りが気になるところ
2010-02-24 21:36:21@securecat そこでXHTML5+XSLTだと思っています。UAの都合で不具合が起きる物が仮にあればXSLTで分岐処理して削除したり、別の下位的な手法(謎 で補ったりとそう言う事を考えていました。なのでこのタイミングの @koba さんのエントリにはかなり驚いたり。
2010-02-24 21:36:40@sigwyg XSLTの基本部分がすでに厳しいというなら確かにそれはダメかもしれません。。ただ、昔のように全てをXSLTに任せたいわけじゃなく最後の仕上げ(謎 だけを預ければ見え方が変わると思うんです。
2010-02-24 21:42:30@securecat あ、XHTML5だろうが xmlns 必要ですね。。。そこは間違えです。すみません。機能的に扱えるものはinvalidだろうと扱えるUAでは後からXSLTで追加しちゃえ的な事を思っていました。
2010-02-24 21:53:06@neotag わからないところ:HTML5じゃなくてXHTML5なのはどうして? XSLTはどこで動かそうと思っているの?
2010-02-24 21:55:34@securecat サーバーサイドなら別にXSLT以外でもいくらでもあるなーという思いと、DOM構築より早い段階で実行されているようなのでものによってはJavascriptより良い面がある点、何でアクセスしても理想的な構造のXHTMLを返す事が可能(っぽい)点などです。
2010-02-24 22:02:50僕がやろうと思っている事が実際に使える物だったとして、今議論に参加してくれてる人達にとっては物凄くどうでもいい価値のない事かもしれない気がして来た。でもその一方で違う界隈の人に可能性をもたらす云々。
2010-02-24 22:08:02@neotag なるほど。僕はXSLTはサーバサイドでも意味があると思っていて、それはXSLはMEが担当するという前提においてだけど。PGはHTMLの整形でない処理に全力を投じれる。これによって最終的な品質向上が見込めるのではないか、と妄想。
2010-02-24 22:10:15@securecat はい。全く同じ事も妄想しています。XSLTが当たり前になればマークアップ全てをMEやコーダーが全責任を持つ事になるので役割分担がより正しい方向に進みますよね。ただこの前の議論を見てわかるようにXSLTは皆に嫌われています[要出典]。
2010-02-24 22:15:12@securecat 続き。そのためにまずはクライアントサイドでの実行によりXSLTを知ってる人も知らない人もそのメリットに気づいてもらい、技術者が増える事でサーバサイドでの実行に移行出来るんじゃないかと思っています。
2010-02-24 22:17:12@securecat 今のままサーバサイドでやる事になると結局使いどころを見誤って使えない子認定されるのが関の山だと思うので。扱える人が増えれば技術も進歩し、もっと良い方向に進むと妄想してます。
2010-02-24 22:19:06それと、クライアントサイドXSLT実行すれば傷の少ないおいしいXHTMLを皆に提供できるよ!「mashup-readyなWebページはAPIたり得る」って @kazuhito さんも言ってました。それって綺麗なXHTMLでいけるよね。と。 http://u.nu/9che6
2010-02-24 22:23:10@securecat 「XSLTでも出来る事」、と「XSLTでしか出来ない事」では注目の集め方が違うと思います。注目が集まれば技術者は増える可能性はありますが、注目が集まらなければ増えにくいです。
2010-02-24 22:24:58