ウェブの黎明期である2000年頃と比べてはるかにHTMLはコーディングしやすくなりました。10〜20年前のHTMLコーディングはどのようなものだったのでしょうか。 この記事では、NetscapeとIEのブラウザ戦争に決着がついた後の、IE6が全盛期となった2000年代のウェブサイト制作を振り返ります。懐かさに浸たり、現代のウェブの成り立ちに通じる温故知新な情報として参照ください。 テーブルレイアウト / spacer.gif XHTML・CSSが普及するまではテーブルレイアウトが一般的でした。テーブルレイアウトとはtableタグを使い、格子状にレイアウトしていく手法です。テーブルレイアウトは、デザインファイル（Image ReadyやFireworks）から画像を切り出す「スライス機能」と相性のいい方法でした。 <table border="0" cellspacing="0" cellp
二〇一三年 長月 廿五日 水曜日 ■ たぶん、ほとんどの人は viewport meta タグの指定をまちがえてる [/links] この記事は書かれてから1年以上経過しています。内容が古くなっている可能性があります。コメントの受付は終了しました。 この記事は古くなっています。改訂版があります。 ウェブサイトをスマートフォンに対応させるために <meta name="viewport" content="..."> と指定することは、多くの人が知っていると思う。しかし、content の中身を何にするべきか本当に理解している人は、日本ではごく少ないようだ（かくいう私もつい最近まで理解していなかったのだから、大きなことは言えない）。 試しに「meta viewport」を Google で検索すると、以下のページが上位に出てくる。 Quick Tip: Don't Forget the Vi
こんにちは、開発部の渡辺です。 「最近、パスワードインプットのautocomplete属性周りが盛り上がってるよ、ちょっと調べてよ」という話を頂いたので、現時点での各ブラウザの挙動をさっくりと調べて結果を記します。 背景 6月にリリースされたFirefox 30の対応によって、ほとんどのモダンブラウザではautocomplete=offにしてもパスワードマネージャへの保存を禁止することはできなくなりました1。 しかし、保存されたパスワードがインプットにフィルインされる挙動はブラウザごとに微妙に異なります。すでに幾つかの記事2で言及されている内容ではありますが（二番煎じ感に溢れててごめんなさい）、複数のブラウザで動作を確認する中で、様々な条件があったので、それらをまとめてみようと思います。 調査内容 今回調べる具体的な内容は、「ブラウザに保存されたパスワードが自動フィルインされる条件」です。
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
お断り：この記事はInternet Explorer Advent Calendar 2013、あるいはYet Another Internet Explorer Advent Calendar 2013のゲリラ投稿、ではありません。 Internet Explorer 9以降といえば、HTML5やCSS、SVGといったものへの対応が注目されがちですが、他のブラウザーが長い間対応してこなかった基礎的な部分への対応も進んでいます。この記事ではInternet Explorer 11（IE11）におけるtitle属性について書きます*1。 title属性 HTMLにはtitle属性という謎の属性があります。多くのブラウザーではtitle属性を設定した要素にマウスを重ねると値をツールチップとして表示します。しかし、ほとんどのブラウザーは、キーボードだけを使ってtitle属性を表示する方法をユーザ
Internet Explorerはエンタープライズでの利用が想定されるため、Microsoft製品で広く適用されているサポート ライフサイクル ポリシーを確認すると、最低でも10年のサポートが受けられると考えている人も多いでしょう。IE8も9も10も、みんなそうなると信じて疑わないIT管理者の方も多いのではないでしょうか。 しかし、これは「誤り」です。 本記事では、最近やたらと複雑化の進んだIEのサポート期間の真実について解説します。 サポートライフサイクルポリシーとは？ そもそもですが、Microsoftの「サポートライフサイクルポリシー」とは何でしょうか。公開しているドキュメントを参照すると、以下の通りです。 マイクロソフトはビジネス、開発用製品に対して最短でも 10 年間のサポートを提供します。ビジネス、開発用製品に対するメインストリーム サポートは、製品発売後 5 年間または次期
IE 8 で文字列から動的に script 要素を生成したい時もあると思います。 オフラインにキャッシュしておいた文字列を JavaScript として評価したい場合などです。 こうすると動作します IE6 ～ IE8 専用です。 var script = document.createElement("script"); document.getElementsByTagName("head")[0]).appendChild(script); script.outerHTML = ' <script defer="defer">' + jsExpression + '</script>'; document.createElement("script") でダミーの(プレースホルダの) script 要素を作り、そのあとで outerHTML で上書きしています。 これでも良
更新: 2012年2月24日23時20分頃 SVGというものはずっと昔からありました。かつてはブラウザ側の対応がいまいちで、プラグインを入れたりしないと表示できなかったりもしており、あまり使われていませんでした。しかしIE9がSVGに対応したことで、かなり使えるようになってきた印象があります。最近では仕事でもガチでSVGを使うことが増えてきています。 SVGの特長のひとつは、ベクターグラフィックなので伸び縮みに強いという点です。サイズ可変の領域にうまい具合に背景を敷きたいときには便利です。そして、最近はサイトのコンテンツ全体がサイズ可変ということも増えてきました。というか元々可変ではあると思うのですが、Media Queries (www.w3.org)を使った派手な変更を伴うパターンが増えてきて、画像のサイズを大幅に変更したいケースが増えてきています。 写真などはJPEG画像を拡大・縮小
IE6 への対応が一段落した昨今、 IE7 もいよいよ事実上市場から姿を消す日が近づいてきたようです。flickr が今年以降リリースする新機能にて IE7 をサポートしないことを表明しました。私の勤務先でも、今ものすごい勢いで IE7 のシェアが低下しており、今年の夏から冬にかけて、今の IE6 と同じくらいのシェアになるかもしれない勢いです。 というわけで、 IE の最低動作保証バージョンが 7 から 8 になったら何ができるようになるのか、僕らの caniuse.com を見てざっと洗い出してみましたのでご参照ください。 CSS inline-block display:inline-block が使えます。IE 6/7 では "display:inline; zoom:1;" で代用していたと思います。 Table Display display:table 、 display:t
Microsoft is holding an AI Agents Hackathon, and we want to see what you can build with Python! We'll have 20+ live streams showing you how to build AI agents with Python using popular agent frameworks and Microsoft technologies. Then, you can submit your project for a chance to win prizes, including a Best in Python prize!
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
本の虫: QuirksBlog: HTML5のドラッグ＆ドロップはクソだ
QuirksBlog: The HTML5 drag and drop disaster QuirksBlogで有名なPeter-Paul Kochさんが、HTML5のドラッグ＆ドロップに関して、酷くののしっている。かなり好い文章で、興味深かったので翻訳してみた。記事が長いので、blockquoteを使うのは御免を被る。 一日半もテストして、HTML5 drag and drop moduleはクソなばかりか、ゲロみてえな臭いがプンプンするってことが、いやというほど分かったね。 コイツはHTML5規格から、ソッコーで消すべきだし、もっとまともな規格が制定されるまでは、現行ブラウザは、この機能を、一刻も早く無効にするべきだ。 Web開発者は、HTML5のドラッグ＆ドロップを使うな。絶対使うな。RFC2119で規定されているMUST NOTの意味で使うな。使いたきゃ、従来通りのスクリプトで実装
米Microsoftの次期Webブラウザ「Internet Explorer 8 (IE8)」の正式提供がスタートした。同ブラウザは今年内にも登場が噂されるWindows 7の標準ブラウザとして搭載が決まっている。MicrosoftではIE8のリリースに合わせ、従来のIE7との互換性情報のガイドラインを紹介している。 IE8では標準準拠をさらに推し進めたのが1つの特徴となっているが、それと同時に、従来のIE7の動作に依存したサイトの一部にはIE8での互換性に問題を持つものが存在する。特にスクリプトやCSSの実装を絡めてがっちりとコーディングが行われたサイトほど互換性の問題に直面することになる。 IE8ではこうした問題に対処するため、標準に準拠したIE8 Standards Modeと従来との互換性を重視したCompatibility Viewの2種類を用意しており、可能な限りIE7準拠のサ
さて、Internet Explorer 8 ベータが現在公開されている訳だが、 既にチェックをしているクリエーターさんは、このIE8の表示モードには「3モードレンダリングエンジン」機能があるのは知っていることだろう。 ここれは知らない人の為に・・・そして自分のやってる講義用にメモ書きしときたい。 内容は、先日のCSSnite in Shinjukuの五寳さんのプレゼンのをまとめ。 IE8においては、強制的にレンダリングモードを切り替えられ、 今後はレンダリングモードを変えて互換性をとっていこう、というモノだ。 具体的には以下のような方法で切り替えることができる。 DCTYPE宣言とmeta要素によるモード変更 HTTPヘッダーでのモード変更 この構成は、IE8の表示を基準としたデフォルトの“IE8レイアウト”と、互換性のための“IE7レイアウト”の２つに大きく分かれる。 そして、“IE7
Apr 12, 2008 某所で行われたIE8 Beta 1についてのセミナーで、DOCTYPEスイッチとIE8の複数のモードの話を聞いていたら、頭の中がごちゃごちゃしてきたのでざっくりとまとめてみる。 レンダリングモードの使い分け まず最初に、IE8には以下の3つのレンダリングモードがあることを覚えておきます。 IE8標準準拠モード (デフォルトのレンダリングモード) IE7標準準拠モード Quirksモード (いわゆる互換モード) IE8のデフォルトでのレンダリングモードは一番上の「IE8標準準拠モード」になります。これらのレンダリングモードを覚えたら、次にIE8が備える「IE7エミュレート機能」について知っておきましょう。エミュレート機能とは「IE7とまったく同じレンダリングをする」ための機能です。つまりこの機能を有効にするとデフォルトのレンダリングモードが「IE7標準準拠モード」に
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
参考にしたのはココ。IEのメモリリーク問題DOM オブジェクトとメモリリーク: Days on the Moon Internet Explorer 繝ェ繝シ繧ッ 繝代ち繝シ繝ウ繧堤炊隗」縺励※隗」豎コ縺吶ｋ Googleさんに「IE メモリリーク 循環参照」で聞いた結果の上３件ってだけやけど・・。 「念のため」も含めてやったのもあるので全部が効果あったのかはわからないが、俺が気をつけたポイントは以下の通り。 DOMオブジェクトは生成後すぐにDOMツリーに追加する今まではcreateElementして、スタイルやイベントハンドラ設定した後で親ツリーに追加してた。これを生成後すぐにツリーに追加し、スタイルやイベントハンドラはその後で落ち着いてやるように変更した。 //↓こんなのを var img = document.createElement('img'); img.onmousedown
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
