Safari 8?の機能予想 - fragmentary
WWDC直前ということでSafariの話題を。 といってもネタは3週間以上も前のもの。5月8日に「safari-538.34-branch」というWebKitのブランチが切られた。 Changeset 168485 – WebKit — New Branch 昨年も書いたのだけど、これまでの動きから考えてこれが次のSafariのもとになるブランチのはず。というわけでコミットログとかから次のSafariを予想しようかと。 WebKitのMac portで有効にされる機能は、FeatureDefines.xcconfig というファイルで管理されている。これらはビルドフラグなので、有効にされてないとナイトリーでも使えない。あと、ランタイムフラグもあるらしいんだけどこれは詳しく知らない。 Safari 8に入りそうなもの 538ブランチのFeatureDefines.xcconfigで有効にされ
Autoprefixer ― CSSのベンダー接頭辞をいろいろする - fragmentary
以前CSS-Tricksの記事で知ったAutoprefixerというの、ようやく試してみた。 ai/autoprefixer Autoprefixer: A Postprocessor for Dealing with Vendor Prefixes in the Best Possible Way | CSS-Tricks CSS-Tricksの記事読んだほうがいいと思うけど、月一のブログ更新ノルマのためここでも書いとく。 かしこい「ポスト」プロセッサ Autoprefixerはその名前からある程度想像できる通り、ベンダー接頭辞を自動的につけたりしてくれるユーティリティ。CSSファイルを作るのではなく、CSSファイルを処理するので、ポストプロセッサと言っている。 接頭辞まわりは、すでにCompassとかのライブラリでmixinなどが用意されてるので、べつに必要ないじゃんと思うかもしれない
新しいSafariについて予想する - fragmentary
追記 (2013-08-13): WWDCでの発表にて、いくつか予想が外れたのが分かったので、短い答え合わせのエントリを書いた。あわせてSafariに懸念していることも書いたので、それもどうぞ。 Safari 7予想：答え合わせなど Safariでせつなくならないために何かしたい 以下は元記事。 WWDCが近いので新しいSafariの予想をしようかと。 来週まで待って確定的な情報を書いてもよかったけど、まあいいや。 たぶん7月に出る 新しいバージョンが「Safari 7」になるのかわかんないから、Apple風に「新しいSafari」と書くね。 ここ2回のメジャーバージョン（5.1, 6.0）は、7月下旬にリリースされている。なので今回も、WWDCでお披露目＋Developer Previewのリリース、7月の同時期に正式版リリースされると予想。 ここ1, 2ヶ月のWebKitでのApple
HTMLに提案中のmain要素 - fragmentary
12月になった。HTML5とCanvas APIのCRが出る。 Transition Request: HTML5 as Candidate Recommendation Transition Request: HTML Canvas 2D Context as Candidate Recommendation MicrodataはRDFaコミュニティのキャンペーンにより遅れそう。わからんけど。altのやつとかもそうかな。やれやれだ。 さて、一緒に出るかはわからないけれど、<main>要素の提案がextension specとして公開されることは決まった。 request to publish main element extension specification as a FPWD Re: CfC: to publish main element specification as a
Chromeの新エンジンBlink ― Webプラットフォーム篇 - fragmentary
よいサブタイトルが思いつかなかった。 Blinkでは、HTMLとかCSSとかDOMなどへの機能追加について、互換性、オープン標準、透明性を重視したガイドラインが設けられ、それが強くアピールされている。 Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing a
Chromeの新エンジンBlink ― どうなるんだろう篇 - fragmentary
なぜなに篇とWebプラットフォーム篇ではBlinkに至った背景や、Blinkの互換性への取り組みについてだーっと書いた。 今回はBlinkの登場が何にどんな影響を与えるか、だらだら考えてみる。 Chrome すでに色々書いてはいるけれど。 WebKitから離れ、Chrome専用エンジンとなるので、これまでWebKitでは合意を得られなかった機能について抵抗なく入れられるのはGoogleにとってはよいことだろう。Pointer EventsとかIME APIとか。Launch Processのもとでだけど、試験実装は進めやすくなる。 WebKitから離れることでの最大の損失は、WebKitに参加している人のタレントだろう。BlinkチームのQ&Aセッションによると、BlinkとWebKitとの間に「フォーマルな関係」はないとのこと。パッチを自動的にやりとりするような仕組みは用意されないから、
Chromeの新エンジンBlink ― なぜなに篇 - fragmentary
4月3日、GoogleがChromeに使っていたWebKitをフォークした新しいエンジンBlinkを発表した。 …だいぶ出遅れたのでとても書きづらいけれど、自分の理解のために書く。ただいろいろあるので、まずはWebKitをフォークするに至った経緯と、Blinkの概要について。 追記 (2013-04-30)：別途ふたつエントリを書いたのでそちらもどうぞ。 Chromeの新エンジンBlink ― Webプラットフォーム篇 Chromeの新エンジンBlink ― どうなるんだろう篇 “Chromium port”としての負担 アナウンスしたAdam Barth曰く、Chrome開発時点でのWebKit採用は正しく、WebKitも大きく成長したと。 Chromium Blog: Blink: A rendering engine for the Chromium project ただ、開発を続け
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
