Prettier 1.15: HTML, Vue, Angular and MDX Support · Prettier
This release adds support for HTML, Vue, Angular and MDX. It also respects decorator position, adds an option for JSX single quotes, allows parser inference via shebang, adds support for several new syntax features, and has a few formatting tweaks. Highlights HTML/Vue/Angular Support HTML, Vue, and Angular (#5259 by @ikatyang, #4753 by @evilebottnawi, #2083 by @azz) Prettier can now format HTML, V
Web 関連仕様 日本語訳
このページは、 Web プラットフォーム関連の様々な仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。 これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、
ブラウザでビジュアルテストをするreftest-runnerを作った
概要 reftest-runnerというブラウザで描画内容やレイアウトといった表示結果をテストするためのライブラリを作りました。 要素技術としてはブラウザ、WebDriver API、レンダリングキャプチャ、画像Diffという感じです。 azu/reftest-runner 時間が無い人向け 以下のスライドに簡単にreftest-runnerやreftestとはなにか、どういうユースケースがあるのかが書いてあります。 reftest-runner-overview.pdf reftestとは reftest(Referrence Test)とは、2つのHTMLの表示結果(スクリーンショット)を比較することで表示結果が意図したものかをテストする方法です。 用意するHTMLとして以下の2種類を1セットとして用意して利用します。 テスト用HTML テストしたい機能を使って実装したHTML リファ
HTML&CSS フロントエンド 何度も読み直したい資料・ツールまとめ - 酒と泪とRubyとRailsと
HTML5/CSS3などのフロントエンドもWeb上の資料が充実しすぎていて、ついつい今までなんとなく作って体系的な知識が不足していました。知れば知るほど奥が深いフロントエンド・コーディングを少し手も効率的にするために、いくつか書籍を購入したり、ネット上の資料を読み込んでみたので、備忘録がてらまとめていきます。 (02/05 20:10) 定期見直し 🎂 [Style Guide]「Google HTML/CSS Style Guide」の和訳 Googleが作ったStyle Guide『Google HTML/CSS Style Guide』を和訳していただいた『Google HTML/CSS Style Guideを適当に和訳してみた』。HTMLのベーシックな書き方から、CSSの書き方まで一貫している。個人的にはCSSのプロパティがアルファベット順というのは合理的だと思う！ 🐰 [S
とあるソシャゲのHTML/CSS設計話
【Frontendアドベントカレンダー19日目】 Xboxに釣られて転職してから２年半…あっという間だった…。 関与したもの： スマホ版ピグ（リニューアルして面影無し） ピグファンタジア（11月末クローズ） 新規ゲーム ←今ここ 今は新規ゲームでコーディングの人としてjoinしてます。 新しいサービスを立ち上げる時に必要なHTMLとCSSの土台作りを全部やるということが、 「HTML/CSS設計」という言葉で装飾されることを知ったのは割と最近です。 マークアップだけで一人据えるのは珍しいと思うので、今やってることなど含めてつらつら書きます。 ここが変だよソシャゲ開発 依頼を受けてサイトを作る場合は次のようなフローだと思います： クライアントと打ち合わせ 仕様が決まる デザイン決まる 値切られる 価格が……決ま…る コーディング クライアントチェック 突然の無理難題に戦慄走る テスト・修正
続・よくある3つのデザインから考える、マークアップの最適解
マークアップシリーズの第2回は、前回のよくある3つのデザインから考える、マークアップの最適解と同じく、html5jマークアップ部主催のイベント「MarkupCafe」で出題された3つのお題から最適なマークアップを探ります。 イベントではAからDの4つのチームにわかれてマークアップを考えました。それぞれのチームごとに違ったマークアップへの考えが表れていてとても興味深いです。また今回はイベント終了後に「HTML5 Experts.jp」のエキスパート兼マークアップ部の部長でもある村岡正和氏に、氏自身ならこうするといったマークアップを公開してもらいました。 本記事ではWebサイト制作の際にありがちな”ページング”、”フォーム”、”データテーブル”の3つについて要素の使いどころや仕様、アクセシビリティやユーザビリティといった観点からマークアップを考えていきます。 1.ページングの中身と重要度 最初
事前レンダリングでウェブページの表示時間を高速化
[対象: 上級] 事前レンダリングと呼ぶ技術を使って、ウェブページの表示時間を高速化する方法をこの記事では解説します。 事前レンダリングとは 事前レンダリング (Prerendering)とは、その名のとおり、ページの読み込み（正確にはレンダリング）を前もって実行する仕組みです。 Google検索で採用されている「インスタントページ」には事前レンダリングが使われています。 下のキャプチャは、Googleで「Amazon」を検索したときのChromeのタスクの状況をタスクマネージャで確認したものです。 「事前レンダリング」でAmazon.co.jpが出ています。 「Amazon」で検索したユーザーはかなり高い確率で（1位に出てきた）Amazonのホームページをクリックするはずです。 Chromeは先回りして、ユーザーがクリックしなくてもAmazonのホームページを取得および描画、つまりレンダ
PythonでElementTreeを使ってXMLを処理する方法 - hikm's blog
ElementTreeはpythonでXMLを扱うためのライブラリです。バージョン2.5からはpythonに標準で内蔵されています。 このライブラリを使うと、XMLをパースしてプログラム内で利用しやすい形に変換したり、XMLファイルを生成したりすることが出来ます。そこで今回は、XMLをパースして利用する方法についてまとめたいと思います。 準備 Python2.5以降にはElementTreeが標準で内蔵されているため、パッケージを個別で入手する必要はありません。 以下のようにインポートするだけで利用できます。 from xml.etree.ElementTree import * Python2.5より古いバージョンを利用している場合は、 http://effbot.org/zone/element-index.htm からパッケージを入手し、以下のようにインポートして下さい。 from
これは凶悪……コーディングのヤバいバグ＆仕様 Best5 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは。LIGフィリピン支社代表のせいとです。 コーディング中にバグやブラウザ仕様のせいで、「なんじゃこりゃアア」ってなること、皆さんありませんでしょうか。 今回は、その中でもとりわけ「なんじゃこりゃアア具合」が激しいトラブルを、僕の独断と偏見のランキング形式でお話しさせていただきます。 なんでランキング形式にしたかというと、そっちの方が面白いと思ったからです。面白くなかったらごめんなさい。 第5位 IE9.jsを入れると、IE7で謎の隙間が発生しまくる IE9.jsを採用したサイトをIE7,8で見ると、 <class="ie7_anon ie7_class6" id="ie7_pseudo2" style="overflow: hidden; display: block;"/> こんなものが追記されていたりします。 こいつに高さがあるせいで、隙間が生まれてしまいます。が、こいつがな
メールのためのレスポンシブWebデザインフレームワーク·Antwort MOONGIFT
AntwortはレスポンシブなHTMLメールを実現するスタイルシートフレームワークです。 HTMLはWebブラウザを使って閲覧するのに用いるのが基本ですが、他にも使われることがあります。その一つがHTMLメールです。独自の知識が必要になることもあるのですが、Antwortを使えばそのエッセンスだけすぐに得ることができます。 サンプルデザインです。 スマートフォンではこのように見えます。 デスクトップ、スマートフォンに対応しています。 Antwortはレスポンシブなデザインになっています。デスクトップで見た場合もスマートフォンで見た場合もカラムの構成は違っても情報は正しく伝達できるようになっています。Appleのメール（iOS/Mac OSX）、Gmail、Androidのメール、Outlook 2000/2003/2007、Hotmail、Outlook.com、Yahoo! Mail、A
スマートフォン対応でよく使うhtml、css、javascriptのまとめ
スマートフォン(ios、android)向けのウェブサイト・ウェブアプリを作る際に個人的によく使うhtml、css、javascriptの備忘録。 html関連 headタグ内での設定<!-- //デバイスサイズにあわせて表示領域を変更する --> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <!-- //電話番号のリンクを無効化 --> <meta name="format-detection" content="telephone=no"> <!-- //ホーム画面用アイコン --> <link rel="apple-touch-icon" href="icon.png"> <!-- //ホーム画面用アイコンの光沢を無効化する --> <link rel="apple-touch-icon
can I use... Support tables for HTML5, CSS3, etc
Test a feature Our partnership with BrowserStack now lets you test your website for compatibility across 2,000+ real browsers and devices. Test on: Did you know? Next If a feature you're looking for is not available on the site, you can vote to have it included. Better yet, if you've done the research you can even submit it yourself! You can import usage data from your Google Analytics account and
ist-jo.in - ist jo リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ケータイサイト制作前にコーダーが確認しておきたいところ │ これからゆっくり考L +α
モバイルサイトの制作前に、もしくは打ち合わせに行った場合は必ずチェックしておきたいところをまとめてみました。 こちらから積極的に確認しないと、何も詳細が分からないままデザインだけぽーんと渡されてしまうことがあるので、自ら前のめりでチェックしておきたいところです。 個人的に「ここだけは外せない！」という項目は以下の6つ ・xhtml？html？ ・文字コードは？ ・tableは使ってOK？ ・絵文字は？ ・カタカナの扱いは？半角？全角？ ・VGA対応は？ xhtml？html？ 最近は基本xhtmlで作成という流れに（私の場合は）なってますが、それでも念のために一応聞いておきたいところ。 昔、xhtmlで作成してほぼほぼ終わった段階で「アップするサーバーでxhtmlが使えないのでhtmlに変更してください！」と言われてやり直したことがあります...。 文字コードは？ 携帯サイトといったらSh
携帯サイト（html）の制作に入る前に確認しておきたいチェック項目 │ これからゆっくり考L +α
「デザインは素敵なんだけど、携帯でこれはちょっとできないなー」とか、「無理ではないけどできれば避けておいた方がいいよなー」っていうデザインがあがってくることが多い今日この頃。 モバイルコーディングをやり慣れている人じゃないとモバイルでできることできないこと、cssを使わないと実現できないこと、table使わないと実現できないこと、などが分かりにくいと思うので当然だとは思うのですが。 ですが、知っているのと知らないのとでは工数がかなり違ってきます。 一旦デザインして、コーダーにそれを見せて「ココとココとココは実現不可能。やり直してください。」で差し戻され、デザインをやり直してってなると、デザインも2度手間、デザインをチェックして無理な項目を洗い出すコーダーにも余計な手間がかかります。 今回洗いだした項目は、なんせ自分がコーダーなので、コーダーがデザインファイルをもらった時にバーッと見てチェッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アウトラインチョットデキル
GitHub - bendc/frontend-guidelines: Some HTML, CSS and JS best practices.
http://www.hp-stylelink.com/news/2013/10/20131001.php
Loading...
ウェブ制作者のためにメンテナンスと拡張に重点をおいたフロントエンド用の軽量フレームワーク -UIkit