アカウント名:
パスワード:
セキュリティリスク的なものは、特に感じてはいないのだけど、アプリケーションのようなリッチすぎるサイトの開発は自重してほしいですね。
最低限、コンテンツはjavascriptとiframe無効にしても閲覧できるように設計してほしいです。せっかくcssでいろんな事できるようになっているのにjavascript頼りすぎ。
開発者としては最低限JavaScriptやiframeは有効にしていただきたいのですが。
それとも開発版のブラウザでフラグを有効にして使って貰えますか？それを皆がしてくれるのならJS使わずできることが多少は増えるのですが。
あとHTML5ファイリーのAPIの多くはJSが絡んでいてこれから減る方向にはいきません。これからはWebComponentsやMVCの考え方でJSがますます必須になってきます。
そもそもWebの有り様が変わってきているのです。W3CのHTML5仕様策定完了発表によると、「HTML5は～～デバイス機能へのアクセスを行うクロスプラットフォームアプリケーションに対応するフルプログラミング環境です」となっています。今やWebサイトは見るものから使うものになってきており、Webコンテンツは立派なアプリケーションなのです。
ドキュメントとアプリケーションの概念は本当に切り分けて整理して欲しかった。アプリケーション環境を「HTML」を拡張して実現する発想は、今でも筋が悪いと思っている。
XHTMLでさえあれだったのに、そんなもの誰も使わないですしおすし。
ですがマルチプラットフォームのアプリケーション環境としてはHTML以上に適するものはないかと。また、HTML5ではリッチになるだけではなく、セマンティクスやユーザビリティを向上させる仕様も含まれています。
例えばルビの標準化、また、他のトピックで挙がっていますが、「読み上げソフトが使いやすいような配慮」の仕様も策定されています。
HTML5は無秩序に機能を増やしているわけではありません。むしろ、今まで無秩序だった独自機能や概念をきちんと標準化するのが役目です。ですから、心配するようなことはないと思いますよ。
HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなります。ドキュメントに動的に変化する要素は原則不要で、JavaScriptは無効か、強い制限を掛ける運用で問題無いでしょう。このドキュメントは、現状のWebブラウザよりもかなりシンプルな実装で、
HTML5みたいなのはあっていいと思うけど、構造化されたドキュメントが欲しい場合もたくさんありますねプログラムとデータが一体化しているメリットもあるけどデメリットも確実にあって替えがきかないことが多い
＞＞HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。ですがそのような使われ方をされるようWebが変化してきたので、HTMLも変わったのです。
UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。いいえ、例えばmeter要素やprogress要素、そしてinputの拡張等、UIが作りやすいようになっています。
＞HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなり
世界は変わっていくものです。それを受け入れるかどうかはあなたの問題です。
そうですね、私個人としては、現状のHTML5の方向性は非常に残念なものと言わざるを得ません。複数組織の思惑が絡む標準化という作業において、削ぎ落とし方向の仕様の洗練化は大変困難なものなのだろうと推察します。
ネタニマジレスカコワルイ
あなたの様な主張、例えば仕様はミニマムであるべきだと主張する人は沢山います。
しかしそれでも、これだけ普及したWebで、大きな新しい仕様を最初から絞って取り決めることは現実的ではないのです。そういう仕様は実際に搭載して長くテストしてみないと良し悪しが見えてこないこともあります。結局はニーズですから、使われる仕様が生き残り、使われない仕様は淘汰されるのが健全だと思います。
それにWebは今やブラウザだけのためのものではなく、様々な機器、環境向けのアプリケーション環境です。今はまだまだ削ぎ落とす段階ではありません。圧倒的に機能が足りないですし、模索の段階なのです。
残念と言いますが、このようなやり方のほうが最終的に多くの意見や実情に揉まれた良い仕様ができます。HTML5は「生きている仕様」であり、それがもっともよい今流の洗練化の方法なのです。
ミニマムは良いと思っていますが、本論はアプリとドキュメントの分割です。
開発者が苦労しない、ユーザーの利便性を損なわない、セキュリティ問題が発生しづらい、そんな素敵な仕様にまとまる事を期待しますよ。
分離する必要がない頭かたいんじゃない？
メリットの問題です。
メリット？誰かさんの違和感がなくなるってことでしょそれ
プログラムを書かない・書けない人にはピンとこないと思いますが、ドキュメントとアプリがべったりくっついていると、オートメーション化する場合にサイトが適切なAPIを提供しなければかなり(しかもアドホックな)苦労してドキュメントを再構成しなければなりませんね
オートメーション化、それだけ？そもそも分離していたとしてもアプリである以上ドキュメントをどう利用してるかわからないし同じ事なんだけど
なるほど、オートメーションをそれだけと言ってしまえる人なんですね技術サイトではちょっと恥ずかしいですよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
アプリケーションとコンテンツ (スコア:0)
セキュリティリスク的なものは、特に感じてはいないのだけど、アプリケーションのようなリッチすぎるサイトの開発は自重してほしいですね。
最低限、コンテンツはjavascriptとiframe無効にしても閲覧できるように設計してほしいです。
せっかくcssでいろんな事できるようになっているのにjavascript頼りすぎ。
Re:アプリケーションとコンテンツ (スコア:1)
開発者としては最低限JavaScriptやiframeは有効にしていただきたいのですが。
それとも開発版のブラウザでフラグを有効にして使って貰えますか？
それを皆がしてくれるのならJS使わずできることが多少は増えるのですが。
あとHTML5ファイリーのAPIの多くはJSが絡んでいてこれから減る方向にはいきません。
これからはWebComponentsやMVCの考え方でJSがますます必須になってきます。
そもそもWebの有り様が変わってきているのです。
W3CのHTML5仕様策定完了発表によると、
「HTML5は～～デバイス機能へのアクセスを行うクロスプラットフォームアプリケーションに対応するフルプログラミング環境です」
となっています。
今やWebサイトは見るものから使うものになってきており、Webコンテンツは立派なアプリケーションなのです。
Re: (スコア:0)
ドキュメントとアプリケーションの概念は本当に切り分けて整理して欲しかった。
アプリケーション環境を「HTML」を拡張して実現する発想は、今でも筋が悪いと思っている。
Re: (スコア:0)
XHTMLでさえあれだったのに、そんなもの誰も使わないですしおすし。
Re: (スコア:0)
ですがマルチプラットフォームのアプリケーション環境としてはHTML以上に適するものはないかと。
また、HTML5ではリッチになるだけではなく、セマンティクスやユーザビリティを向上させる仕様も含まれています。
例えばルビの標準化、また、他のトピックで挙がっていますが、
「読み上げソフトが使いやすいような配慮」の仕様も策定されています。
HTML5は無秩序に機能を増やしているわけではありません。
むしろ、今まで無秩序だった独自機能や概念をきちんと標準化するのが役目です。
ですから、心配するようなことはないと思いますよ。
Re: (スコア:0)
HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。
UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。
HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を
適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなります。
ドキュメントに動的に変化する要素は原則不要で、JavaScriptは無効か、強い制限を掛ける運用で問題無いでしょう。
このドキュメントは、現状のWebブラウザよりもかなりシンプルな実装で、
Re: (スコア:0)
HTML5みたいなのはあっていいと思うけど、構造化されたドキュメントが欲しい場合もたくさんありますね
プログラムとデータが一体化しているメリットもあるけどデメリットも確実にあって替えがきかないことが多い
Re: (スコア:0)
＞＞HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。
ですがそのような使われ方をされるようWebが変化してきたので、HTMLも変わったのです。
UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。
いいえ、例えばmeter要素やprogress要素、そしてinputの拡張等、UIが作りやすいようになっています。
＞HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を
適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなり
Re: (スコア:0)
世界は変わっていくものです。それを受け入れるかどうかはあなたの問題です。
そうですね、私個人としては、現状のHTML5の方向性は非常に残念なものと言わざるを得ません。
複数組織の思惑が絡む標準化という作業において、削ぎ落とし方向の仕様の洗練化は大変困難なものなのだろうと推察します。
Re: (スコア:0)
ネタニマジレスカコワルイ
Re: (スコア:0)
あなたの様な主張、例えば仕様はミニマムであるべきだと主張する人は沢山います。
しかしそれでも、これだけ普及したWebで、大きな新しい仕様を最初から絞って取り決めることは現実的ではないのです。
そういう仕様は実際に搭載して長くテストしてみないと良し悪しが見えてこないこともあります。
結局はニーズですから、使われる仕様が生き残り、使われない仕様は淘汰されるのが健全だと思います。
それにWebは今やブラウザだけのためのものではなく、
様々な機器、環境向けのアプリケーション環境です。
今はまだまだ削ぎ落とす段階ではありません。圧倒的に機能が足りないですし、模索の段階なのです。
残念と言いますが、
このようなやり方のほうが最終的に多くの意見や実情に揉まれた良い仕様ができます。
HTML5は「生きている仕様」であり、それがもっともよい今流の洗練化の方法なのです。
Re: (スコア:0)
ミニマムは良いと思っていますが、本論はアプリとドキュメントの分割です。
開発者が苦労しない、ユーザーの利便性を損なわない、セキュリティ問題が発生しづらい、
そんな素敵な仕様にまとまる事を期待しますよ。
Re: (スコア:0)
分離する必要がない
頭かたいんじゃない？
Re: (スコア:0)
メリットの問題です。
Re: (スコア:0)
メリット？
誰かさんの違和感がなくなるってことでしょそれ
Re: (スコア:0)
プログラムを書かない・書けない人にはピンとこないと思いますが、ドキュメントとアプリがべったりくっついていると、オートメーション化する場合にサイトが適切なAPIを提供しなければかなり(しかもアドホックな)苦労してドキュメントを再構成しなければなりませんね
Re: (スコア:0)
オートメーション化、それだけ？
そもそも分離していたとしてもアプリである以上
ドキュメントをどう利用してるかわからないし同じ事なんだけど
Re: (スコア:0)
なるほど、オートメーションをそれだけと言ってしまえる人なんですね
技術サイトではちょっと恥ずかしいですよ