タグ付けされた質問 「html」

HTML(HyperText Markup Language)は、Webページの作成に使用される主なマークアップ言語です。

6
FacebookのReactとWebコンポーネント(ポリマー)の長所と短所
今後のWebコンポーネント仕様に対するFacebookのReactの主な利点は何ですか(逆もまた同様です)(または、リンゴ同士の比較はGoogleのPolymerライブラリとなるでしょう)。 このJSConf EUトークとReactホームページによると、Reactの主な利点は次のとおりです。 コンポーネントモデルを使用したデカップリングと凝集度の向上 抽象化、構成、表現力 仮想DOMと合成イベント(基本的に、DOMとそのイベントシステムを完全に再実装したことを意味します) IE 8で最新のHTML5イベントを有効にします サーバー側のレンダリング テスタビリティ SVG、VML、およびへのバインド <canvas> この仮想DOMの概念(明らかに)を除き、ほとんどすべてのことはWebコンポーネントを介してネイティブにブラウザーに統合されています。仮想DOMと合成イベントが古いブラウザをサポートするために今日どのように有益であるかを見ることができますが、ネイティブブラウザのコードの大部分を捨てて、長期的に足を踏み入れるようなものではありませんか?最新のブラウザに関する限り、それはホイールの不必要なオーバーヘッド/再発明の多くではありませんか? ここに、Webコンポーネントが面倒を見てくれるReactが欠けていると思うものをいくつか紹介します。私が間違っている場合は修正してください。 ネイティブブラウザサポート(「より高速であることが保証されている」を参照) スクリプト言語でスクリプトを記述し、スタイル言語でスタイルを記述し、マークアップ言語でマークアップを記述します。 Shadow DOMを使用したスタイルのカプセル化 代わりにReactにはこれがあり、JavaScriptでCSSを記述する必要があります。可愛くない。 双方向バインディング
521 javascript  html 

8
なぜ人々はdivでテーブルを作っているのですか?
現代のWeb開発では、このパターンに頻繁に出くわします。次のようになります。 <div class="table"> <div class="row"> <div class="cell"></div> <div class="cell"></div> <div class="cell"></div> </div> </div> CSSには次のようなものがあります。 .table { display: table; } .row { display: table-row; } .cell { display: table-cell; } *(クラス名は例示のみです。実際には、これらは要素の内容を反映した通常のクラス名です) 私も最近自分でこれを試してみました。なぜなら、みんながそれをやっているからです。 しかし、まだわかりません。なぜこれを行うのですか?テーブルが必要な場合は、ブラスト<table>を作成して完了です。はい、レイアウト用であっても。それがテーブルの目的です-ものを表形式でレイアウトします。 私が持っている最も良い説明は、今では誰もが「レイアウトにテーブルを使用しない」というマントラを聞いているので、彼らは盲目的にそれに従うということです。しかし、彼らはまだレイアウト用のテーブルを必要とします(他にテーブルの拡張機能がないため)、彼らは<div>(テーブルではないので!)作成し、とにかくそれをテーブルにするCSSを追加します。 すべての世界にとって、これはあなたのやり方で任意の不必要な障害物を置き、それらを回避するために余分な仕事をするようなものです。 レイアウトのためにテーブルから移動するための元の引数は、後で表形式のレイアウトを変更するのは難しいということでした。しかし、「フェイクテーブル」レイアウトの変更も同じ理由で同じくらい難しいです。実際、実際にはレイアウトの変更は常に困難であり、マイナーな調整よりも深刻なことをしたい場合は、CSSを変更するだけでは十分ではありません。あなたはします深刻な設計変更のためのHTMLの構造を理解し、変更する必要があります。そして、テーブルはdivよりも仕事を難しくしたり簡単にしたりしません。 実際、テーブルを使用してレイアウトを変更するのが困難になる可能性があると私が思う唯一の方法は、abを使用して、邪悪な混乱を作成した場合です。divでも同様です。 だから...これを暴言から首尾一貫した質問に変える試みで:私は何が欠けていますか?実際のテーブルよりも「偽物のテーブル」を使用する実際の利点は何ですか? 重複リンクについて:これは、別のタグなどを使用するための提案ではありません。これは<table>vsの使用に関する質問display:tableです。
269 html  css 


5
同じid属性を持つ2つのHTML要素:どれほど悪いのでしょうか?
Googleマップのソースコードを参照するだけです。ヘッダーには、id = "search"の2つのdivがあり、一方にはもう一方が含まれ、jstrack = "1"属性もあります。次のようにそれらを分離するフォームがあります: <div id="search" jstrack="1"> <form action="/maps" id="...rest isn't important"> ... <div id="search">... これはグーグルなので、間違いではないと思います。 それでは、このルールに違反することは本当にどれほど悪いことなのでしょうか?CSSとDOMの選択に注意している限り、クラスのようなIDを再利用してみませんか?誰かがこれを意図的に行っていますか?

6
<b>および<i>タグが非推奨になったのはなぜですか?
この質問は、私の大学の授業で出てきました。教授は、それがより説明したという答えを与えたが、それがあるかのように思える&lt;b&gt;し、&lt;i&gt;その意味ではなく、明示的であり、より入力しやすい&lt;strong&gt;と&lt;em&gt;。 これらのタグの廃止の公式の議論は何でしたか?
98 html  deprecation 

8
なぜ適切に意味論的にマークアップする必要があるのでしょうか?
私は見た目や感じが好きなので、可能な限り意味的にマークアップしようとしますが、他の素晴らしい利点を知っているからではありません。私の質問のポイントは、他の人を教育できるようにすることです さて、私は多くの記事やチュートリアルを見てきましたが、「セマンティックな方法でこれをマークアップしましょう」ということがよくあります。 しかし、奇妙な考えが私に来ました、なぜですか? なぜ正しいセマンティックな意味を伝える特定の要素に煩わされる必要がある(またはしたい)のでしょうか?具体的には、私のような、新しいHTML5要素を参照しています&lt;time&gt;、&lt;output&gt;または&lt;address&gt;。特に、ページが「機能する」場合(すべてのブラウザで適切に表示されます)。 なぜ、&lt;time&gt;またはのような要素を使用したいのでしょうか?&lt;address&gt;&lt;span&gt; こういったいわゆるベストプラクティスに従わない(非常に人気のある)Webサイト(このサイトを含む)が多数あるので、これを求めています。
55 html  html5  semantics  markup 

5
なぜXHTML5ではないのですか?
だから、HTML5は大きな前進だと言われています。私が気づいた最後の一歩は、XHTMLの導入でした。利点は明白でした。単純さ、厳格さ、標準のXMLパーサーとジェネレーターを使用してWebページを操作できることなどです。 それでは、HTML5がそのすべてをロールバックするということは、どれほど奇妙でイライラするでしょう。ここでも、非標準の構文を使用しています。繰り返しになりますが、過去の荷物と解析の複雑さを処理する必要があります。繰り返しますが、標準のXMLライブラリ、パーサー、ジェネレーター、トランスフォーマーは使用できません。そして、W3Cが10年かけて正当な理由で推し進めたXMLによってもたらされたすべての利点(拡張性、名前空間、標準化など)は失われます。 XHTML5がありますが、HTML5エンコーディングのように人気が出ていないようです。たとえば、このSOの質問を参照してください。HTML5仕様でさえ、XHTML5ではなくHTML5が「ほとんどの著者に推奨される形式」であると述べています。 事実が間違っていますか?そうでなければ、なぜこのように感じるのは私だけですか?XHTML5ではなくHTML5を選択するのはなぜですか?
53 html  html5  xml  xhtml 

10
インラインスクリプトを避けるべき理由
最近、知識のある友人が私が立ち上げたウェブサイトを見て、「非常にクールなサイト、ソースコードのインラインスクリプトについての恥」などのコメントをしました。 私は間違いなく、インラインスクリプトが発生する場所を削除する立場にあります。私はそれが「悪いこと」であることを漠然と認識しています。私の質問は、インラインスクリプトの本当の問題は何ですか?重大なパフォーマンスの問題がありますか、それともほとんど良いスタイルの問題ですか?インラインスクリプティングの前線で即座にアクションを実行することを上司に正当化できますか?Webサイトにアクセスしてソースコードを覗いてみると、どのような要因が「うーん、ここでのプロフェッショナルな仕事」と言ってしまうでしょうか。 さて、その質問は執筆中に複数の質問に変わりました。しかし、基本的に、インラインスクリプティング-契約は何ですか?


7
面接中に候補者のHtml / CSSの知識を評価するにはどうすればよいですか?[閉まっている]
私はHtml / CSSの仕事に来る人々の能力を評価するためにいくつかの良いインタビューの質問を決定しようとしていますが、そのトピックは非常に広範であり、誰かのHTML / CSSの知識。 面接中に候補者のHtml / CSS能力を評価するには、どのような質問をすればよいですか? 理想的には、いくつかの質問をしてから、実際の生活シナリオを提示して戦いたいと思います。

8
HTML5の使用を開始するにはどうすればよいですか?[閉まっている]
HTML5を学習するための推奨ワークフローは何ですか?どのツールをインストールする必要がありますか?どのSDKですか?どこから始めれば?テスト方法 デバッグ方法 私は何を読みますか? 「HTML5開発」と呼ばれることが多いのは、実際にはHTML、CSS、JSなどの混合物であることを理解していますが、より大きなプロジェクトがメモ帳で開発されているとは思いません。だからこそ、ワークフローに関するヒントやコツを明らかにするようお願いしています。
42 javascript  html  css  ajax  html5 

7
リンクする代わりにスタイル/スクリプトをHTMLに埋め込むのはなぜですか?
CSSファイルとJavaScriptファイルを連結してHTTPリクエストの数を減らし、パフォーマンスを向上させます。結果は次のようなHTMLです。 &lt;link rel="stylesheet" href="all-my-css-0fn392nf.min.css"&gt; &lt;!-- later... --&gt; &lt;script src="all-my-js-0fn392nf.min.js"&gt;&lt;/script&gt; これをすべて行うためのサーバー側/ビルドロジックがある場合は、さらに一歩進めて、連結されたスタイルとスクリプトをHTMLに埋め込みましょう。 &lt;style&gt;.all{width:100%;}.my{display:none;}.css{color:white;}&lt;/style&gt; &lt;!-- later... --&gt; &lt;script&gt;var all, my, js;&lt;/script&gt; HTTPリクエストは2つ少なくなりましたが、実際にはこの手法を見たことはありません。何故なの?

5
ウェブサイトのサーバー側を常にプログラムする必要がありますか?
私は友人のために音楽プロジェクトのウェブサイトの作成を開始しようとしています。現時点ではかなりシンプルなはずです。動的コンテンツ(ツアーの日付など)はなく、いくつかの埋め込みサンプルソングまたはSoundCloudリンクしかありません。レスポンシブグリッドには、バニラJavaScriptとBootstrapまたはFoundation以外のものを使用する予定はありません。 これで十分ですか?HTML、CSS、JSファイルをホストに単純にアップロードして完了できますか、それともNodeまたはPHPでバックエンドサーバーをプログラムするのに時間をかける必要がありますか?

14
厳しい締め切りに直面したときに他の人のコードをクリーンアップすることはどれほど重要ですか?[閉まっている]
(私は(プログラミング言語ではなく)HTML / CSSコードについて話しているが、プログラマーと同じ問題に直面していると思う。) 私はチームのシニアフロントエンドデザイナーであり、後輩の成果を厳しい締め切りで頻繁に作り直す必要があります。 私は2つの問題に直面しています: それらのコーディングスタイルは少し複雑です。 美学は良くありません。 彼らのコーディングスタイルは、適切な慣習/標準がない混合バッグです。私は、コードをクリーンアップするか、単にコードを処理する(それらがどのように動作するかをコピーする)ことで引き裂かれます。 私は悪い習慣を学ぶかもしれないと思うので、彼らのコーディングスタイルに従うのはイライラします。しかし、その後、それが期限を満たすための最速の方法です。 より多くの経験を持つ人にとって、どれがより効果的ですか?クリーンアップを後で保存する必要がありますか?または、変更の途中でクリーンアップしますか? (私は慢に聞こえたくはありませんが、それは現実です。より良いコードを書くのに何年もかかるでしょう。

6
HTMLで厳密な解析が選択されなかったのはなぜですか?
HTMLの作成時に厳密な解析が選択されなかった理由をよく考えました。インターネットの歴史のほとんどにおいて、ブラウザはあらゆる種類のマークアップを受け入れ、それを解析するために最善を尽くしています。このプロセスはパフォーマンスを低下させ、人々が意味不明なものを書くことを許可し、時代遅れの機能を中止することを困難にします。 HTMLが厳密に解析されない特定の理由はありますか?
38 html  history  parsing 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.