ブラウザで:has()セレクタが実装されてjQueryの:has()セレクタの挙動が変わったの調べた - hogashi.*
Chromeに実装された疑似クラス「:has()」がjQueryの「:has()」に悪影響、一定の条件下でWebサイトが壊れる可能性 － Publickey を読んだので、調べたものとあわせてまとめる。 三行 原因 forgiving-selector-list Chrome と Safari の状況の違い されている対応と今後 感想 三行 かねてから jQuery には拡張した CSS セレクタとして :has() がある :has() Selector | jQuery API Documentation Safari 15.4 と Chrome 105 で CSS セレクタとして :has() が実装された :has() pseudo class - Chrome Platform Status :has() CSS relational pseudo-class | Can I u
Chromeに実装された疑似クラス「:has()」がjQueryの「:has()」に悪影響、一定の条件下でWebサイトが壊れる可能性
Chromeに実装された疑似クラス「:has()」がjQueryの「:has()」に悪影響、一定の条件下でWebサイトが壊れる可能性 最近リリースされたSafariとChromeで、CSSのSelectors Level 4（現時点でドラフト）仕様にある疑似クラス「:has()」が相次いで実装されました。 疑似クラス「:has()」は、カッコ内に要素を書くと、その要素を持つ親要素にのみ指定したスタイルを設定できる、という便利な機能を提供してくれます。 ところがこの「:has()」のChromeにおける実装は、jQueryで似たような機能（カッコ内の要素を持つ親要素を選択する）を提供する「:has()」に悪影響を及ぼし、このjQueryの「:has()」を使っているWebサイトでは、Chromeを利用した場合に一定の条件下でWebサイトが壊れるなどの問題を引き起こすことが分かりました（同じエ
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
canvas要素 - Wikipedia
canvas要素（キャンバスようそ、英: canvas element）とは、HTML5以降のHTMLの一部で、動的な2次元ビットマップ画像の描画のためのHTML要素。 歴史[編集] Mac OS X v10.4の内部でWebKitコンポーネントとして、DashboardウィジェットやSafariでのアプリケーションを強化するために、2004年[1]にAppleが最初に導入した。後に、Mozilla FirefoxやOperaでも採用され、WHATWGで、新しい標準規格として標準化された。 2009年の夏頃に、文字列描画のAPIとピクセル操作のAPIが追加になり、ウェブブラウザに実装された。 その後、HTML Canvas 2D Context, Level 2 が作られ、2012年12月17日[2]に最初の W3C Working Draft が発表になった。imageSmoothing
Chrome 34ではimgタグで解像度に応じた複数の画像を出し分けられるよう、レスポンシブイメージ対応に
スマートフォンのような小さな画面からデスクトップPCのディスプレイまで、Webに対応するデバイスの画面の大きさや精細度の多様性は高まってきています。 多くのWebデザイナーは、こうした多様な画面に合わせてレイアウトなどを変えることで見やすくするよう努力してきましたが、こうしたダイナミックなレイアウトを実現する上で大きな課題だったのが画像の扱いです。画面の大きさや精細度に合わせて適切な画像を表示させようにも、そのための標準的な方法がないのがその理由です。 Chrome 34ではその、いわゆるレスポンシブイメージへの対応としてimg要素に新機能を実装することを明らかにしました。。 img要素のsrcsetで、画面解像度ごとに表示すべき画像ファイルを複数指定できるようになります。 <img alt="A rad wolf." src="pic1x.jpg" srcset="pic1x.jpg 1
次世代HTMLの新仕様「レスポンシブ・イメージ（仮）」についてまとめてみた
レスポンシブWebデザインを実装する際、画像の扱いは一つの課題として残っています。現在、PHPを使用した「Adaptive Images」やJavaScriptを使った「Responsive-Images」などが現実的な対応策としてありますが、どちらもApacheの設定を必要とします。レスポンシブWebデザインが広まって標準的な実装方法の一つになろうとしている今、サーバサイド技術に依存しない解決策が早急に求められています。 そんな中、HTMLの仕様策定の一端を担うWHATWG（Web Hypertext Application Technology Working Group – ワットダブルジーと読む）で、新たな仕様が検討されています。 では、どんな議論がされていて、今どんな状況なのか？ なかなか複雑なことになっているようなので、調べてまとめてみました。 ※この記事は、レスポンシブWeb
Sphinxで素早く簡単に綺麗な日本語のPDFを作成する方法 - (DxD)∞
ドキュメントを書くのが楽しくなるPython製ドキュメント作成ツール「Sphinx」で簡単にPDFを作成する方法を紹介します。 Sphinxは1つのテキストファイルからHTMLやPDF、ePub等々をあっという間に生成してくれる素敵なツールです。 SphinxでPDFを生成する方法としては、「SphinxでPDFファイル作成」や「Sphinx & blockdiag Advent Calendar(全部俺) : ATND」の「(8日目) Sphinx から PDF を生成してみよう (rst2pdf 編)」「(11日目) Sphinx から PDF を生成してみよう (LaTeX 編)」で「rst2pdf」や「LaTeX」を使用する方法が紹介されているのですが、実際に試してみると周辺ツールの導入が大変だったり、エラーが出たりでなかなか思うようにPDFを作成できませんでした。 そこで発想を変
How Browsers Work - Behind the Scenes of Modern Web Browsers — Translation of "How Browsers Work" 0.1 documentation
この翻訳について¶ この文章は HTML5 Rocks で公開されている How Browsers Work: Behind the Scenes of Modern Web Browsers を非公式に和訳したものです. 内容の正確性は保証しません. ライセンスは原文と同じく, 文章は Creative Commons Attribution 3.0 License , サンプルコードは Apache 2.0 License です. フィードバックは Issue への登録 , あるいは Kosei Moriyama (@cou929 または cou929 at gmail.com) へ直接お願いします. GitHub に この和訳のリポジトリ があります. 以下の Preface でも言及されていますが, この文章は Tali Garsiel さんが自身のサイトで公開していたものを Pa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
