[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails

TAK(@tak_dcxi)です。今回もCSSに関する投稿です。 以前このようなツイートをしました。 メインビジュアルなど、画面いっぱいに要素を表示するためにheightやmin-heightに100vhを指定する。そして、iOSで表示確認した時に以下のような問題が起こるわけです…。 iOSのSafariでの100vhが気に食わない問題 iOSのSafariでは100vhの計算にアドレスバーが考慮されていないため、アドレスバー分押し出されて格好悪く表示されます。ちなみにiOSのGoogle Chromeは中身SafariなのであれもSafariです。 この問題に立ち向かうために、実装者はJavaScriptを利用して高さを指定したり、height: 100%;のバケツリレーを行ってアドレスバーまで考慮した画面いっぱいの表示を実現するために頑張ってきたわけです。 そんな中、先程のツイートから
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
この前非情報系の友人と飲んでいて話題に出そうとして出せなかった話。 その友人は以前HTMLがプログラミング言語だとうっかり情報系の先輩の前で口にしてしまい、当然のごとくそれは間違っているとツッコミを受けたそうだ。 そこで「実はHTML(+CSS)はチューリング完全と言えなくもないからプログラミングはできるんだよ!」というこの前聞いた話を振ろうとしたものの、相手はチューリングテストとチューリングマシンの違いも分かっていなかったので諦めたのだった。ウカツ! チューリングテストとチューリングマシン Ⓒ Duane Wessels 2012 どちらも計算機科学の発展に大きく寄与したアラン・チューリングによって考案された概念。 (でも中身は月とスッポンくらい違う) チューリングテストとは チューリングテストはある機械が知性を持つかどうかを判定するためにチューリング先生が考えだしたテストのこと。 どう
趣味で会社の人のサイトを作った。縦書きでレスポンシブなブログ。prismic.ioとNext.jsで作った。 ウェブデザインに縦書きを活かすことは難しい。部分的に取り入れることはできても、縦書きの文章を主要な要素として扱うのはかなり難がある。というのも、ウェブサイトは縦にスクロールするのが当たり前だけど、普通に縦書きで実装すると横スクロールになるからだ。 横書きでは文章は上から下に流れ、ページは縦スクロールになる。対して縦書きの場合、文章は右から左に流れるため、横スクロールになる。スクロール操作が不自然だと目に見えてユーザービリティが低下するので、どうしても当たり前のスクロールができるようにしたい。 幸い、縦書きにしながら縦スクロールにする方法はひとつある。新聞や雑誌のように段組にすることだ。 それはcolumnsを利用すれば、一見簡単にできそうな感じはする。けど、僕が望む仕様を実現しよう
Joel Spolsky氏の新サービス「HyperDev」ベータ公開。アカウント不要、Git不要、サーバ申込不要、OSやミドルウェア不要。超簡単なフルスタックのWebアプリ開発環境 元マイクロソフトのプログラマで、エンジニアのコミュニティStackOverflowを立ち上げたジョエル・スポルスキー(Joel Spolsky)氏が、新サービス「HyperDev」をベータ公開しました。 HyperDevはWebブラウザから使えるWebアプリケーションの統合開発環境です。バックエンドにはNode.jsも立ち上がっています。 スポルスキー氏はHyperDevの特長を次のように説明しています。 アカウント作成不要 Git不要、そのほかのバージョンコントロールも不要 ネームサーバなどの操作不要 ホスティングへの申し込み不要 サーバのプロビジョニング不要 OSやLAMPやNode.jsサーバなどあらゆる
完成品になれない溝をどう埋める あたかも完成品に見えてしまうデザインカンプには、様々な暗黙の了解が存在します。グラフィックツールで Web ブラウザ上での見た目を再現しようとしても、実際 HTML / CSS で組まれたデザインの見た目と同じになることはありません。どこまで静止画を作り込んでも、実際の完成品には成り得ない大きな溝が存在します。この溝が大きな誤解に繋がることがあります。 例えばレスポンシブ Web デザインの場合、幾つかの大きさで静止画のデザインを用意したとしても、その間(可変状態)でどうなるか想像するのが難しい場合があります。また、レスポンシブ Web サイトにおける表現は多彩になってきています。要素の順番を Flexbox で変えることもできますし、画像の配置の仕方もより柔軟で表現豊かになってきています。知識や経験がある方であれば静止画では表現されていない「実はこうなる」
機種変更では、このような失敗をする方がとても多いです。 有料オプションを契約させられ料金が高くなった。。 待ち時間や契約時間が長くて、半日かかってしまった。。 キャンペーンや割引がきちんと適用されていなかった。。 スマホを乗り換えるときには、 → おとくケータイ で乗り換えをするとキャッシュバックがもらえます。 スマホの機種変更するときは、 →ソフトバンクはこちら →ドコモはこちら →auはこちら キャリア公式オンラインショップがおすすめです。学割や限定キャンペーンなどがもっとももおとくな時期です。 最も人気の言語、JavaScript Redmonkの調査によると、人気言語のランキング第一位はJavaScript (2015年6月発表のデータ,Redmonkより引用) これはGitHubとスタック・オーバーフローというサービスのコミュニティを分析した結果で、見にくいですが1位がJavaS
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか? 今後、この呼び出しを変更したり削除したりしても安全でしょうか? // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
2014年3月18日に発売される、Sass and Compass in Actionの邦訳版である『Sass&Compass徹底入門 CSSのベストプラクティスを効率よく実現するために』を監修した。 Sass&Compass徹底入門 CSSのベストプラクティスを効率よく実現するために Wynn Netherland, Nathan Weizenbaum, Chris Eppstein, Brandon Mathis, 石本 光司 (株式会社サイバーエージェント) 翔泳社 2014-03-18 Amazonで詳しく見る by G-Tools 監修の依頼を受けて音速でハイと答えたのだけど、監修って何するんだろうねって感じだった。いや、原書の『Sass and Compass in Action』は以前から購入していて、Sass/Compassの開発者であるNathan Weizenbaumや
このテーブルの番号は 1 Byte になっているため、0-255 の 256 個しか登録できません。そのため、画像で使用されている色が 256 個より多い場合は、なんとかして 256 個にしなくてはいけません。 この「なんとかして 256 色にする」というのが減色処理で、なるべく元の画像からの変化を分からないようにしながら色を減らしていくためのアルゴリズム実装です。(この記事では減色アルゴリズムについての説明は省略します。) テーブルを作成したら、画像のそれぞれのピクセルを RGB 形式からテーブルの何番目の色を使うかに置き換えます。 上図のように、1 ピクセルあたり 24bit 必要だった画像が 1 ピクセルあたり 8bit になったので、データサイズは大体 1/3 になります。 (パレットのデータに最大 3 Byte * 256 = 768 Byte 必要とか、同じように圧縮されないと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く