Mozilla Foundation設立 72
ストーリー by yourCat
トカゲは独立不覊 部門より
トカゲは独立不覊 部門より
btm 曰く、 "mozilla.orgは現地時間7月15日付けで、Mozillaの開発、公開、導入を推進する新しい非営利団体、Mozilla Foundationの設立を発表した (プレス・リリースの和訳)。Mozilla FoundationはAOLから今後2年で200万ドルの援助を受け、さらにRed HatやSun Microsystemsなどからも援助を受けるらしい。
これでmozilla.orgはAOLから半独立状態になる。やはり、背景にはAOLとMSとの連係があって、AOLは早くmozilla.orgを切り離したかったんじゃないかなと疑ってしまう。ただ、独立した組織として動ける事はOSSの流れから見てもうれしい。以前、中国市場でシェアを伸ばすという理由でmarqureeをサポートし、W3C標準準拠がAOLによって崩されてしまった事がある。今回の独立で、内部にあった政治的問題もクリアになって欲しい。"
Anonymous Coward曰く、" これと同時に、Mozilla.orgも見違えるように更新されている。本家/.の記事もどうぞ。"
Netscape社 (スコア:2, 興味深い)
非営利団体 (スコア:2, 興味深い)
非営利団体ということですがAOLから2年間の手切れ金を受け取った後は、どうやって維持していくのでしょう。
Mozilla Foundation 自体は、
> Mozilla Foundation は、カリフォルニア州の公益企業として法人格を取得し、非営利組織として 501(c)(3) ステータスの取得を模索しています。また、カリフォルニア州マウンテンビューを本拠地としていきます。
また、
> Mozilla Foundation の新代表に就任した Mitch Kapor は、30 万ドル (およそ 3,500 万円) の個人的な寄付をおこなっています。
豪快ですね。
> また、Red Hat、Sun Microsystems をはじめとする各社も、Mozilla プロジェクトに対する出資を続ける方針です。
ということですから、Mozilla が普及することで利益を得る団体にスポンサーになってもらうという感じでしょうか。
- Ryuzi Kambe -
Re:非営利団体 (スコア:1)
引用元は、プレス・リリースの和訳 [mozilla.gr.jp] です。
- Ryuzi Kambe -
Re:非営利団体 (スコア:1)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:非営利団体 (スコア:1)
Mozilla.orgへの寄付のことは書かれていませんが、OpenSourceなプロジェクトとの関わりについて答えています。
Re:Mitch Kapor (スコア:1)
Re:非営利団体 (スコア:0)
そんなあなたが書いたコメントのひとつ先のコメント(#360033)で示されているプレス・リリースの和訳 [mozilla.gr.jp]に、そう書いてますね。
Re:非営利団体 (スコア:0)
Groove -> オープンソース系の団体(忘れた) -> Mozilla Foundation
ですか。なかなか面白い動きですね。常にフロントラインにいるというか。
Chandler のような個人で抱えているコードもどう打ち出していくのか興味津々です。
marquree ふたたび (スコア:1, 参考になる)
微妙に違ったニュアンスで受け止められそうなのでちょっとコメント。
・中国圏では marquree 使用率が他の地域に比べて多かった。
・サポートしなかった場合に発生する問題とサポートした場合の問題+利点を天秤にかけたけっか、サポートするほうを選んだ。
・一時は中国向けNetscapeだけでサポートする案もあったが、紆余曲折を経て mozilla/netscape共に全バイナリでサポートすることとなった。
ぶっちゃけた話、W3Cで定められた標準要素をサポートしていないという問題に比べれば独自拡張をサポートした場合の問題の方が軽いという見方も影響したようですけどね。(もちろん、その独自拡張が標準要素に弊害を及ぼさないという前提で、ですが)
私のコメントをどう受け止めるかはご自由にどうぞ。
Re:marquree ふたたび (スコア:2, 興味深い)
理由はそうですが、かなり反発があり、bugzillaではたしか反対意見の方が多かったと覚えています。 結局、上位の意思決定が絶対であった事には変わりはないでしょう。
marqureeだってblinkだってjavascriptとcssで再現できるからそれで良いじゃんみたいなノリになってくれないもんですかね。結局、Netscape/AOLはそういう啓蒙をする余地がなくて、ただ呑まれただけ。ある意味チャンスだったと思うんですけど、現実って厳しいね。
三日風呂に入らなかったら、あなたはすめるまんです。
Re:marquree ふたたび (スコア:1, すばらしい洞察)
そういう理由からも、JavaScriptを要求しなければならないくらいなら marqureeを実装して欲しいと考える人もいるかもしれません。
Re:marquree ふたたび (スコア:1)
marqueeはjavascript要求してるから [mozilla.org](javascriptで実装してるから)結局Onになってないと動かないという罠。ってかCSS3でmarquee [w3.org]あるんだねぇ...早く実装して駆逐してくれぃ
三日風呂に入らなかったら、あなたはすめるまんです。
Re:marquree ふたたび (スコア:1)
だったら無駄なレスだ。
#このレスも無駄なのでAC
--労使曰く、ひとごとを尽くして神頼み--
Re:marquree ふたたび (スコア:1)
#ってな無駄レスなのでID
ところでACになってませんよ> ADさん
#ってさらに無駄なのでやっぱりID
#一瞬、「マーキュリー属性かあ。何世代前のオタだよ」とか思ったけど、それこそとっても無駄なのでどうしてもID
Re:marquree ふたたび (スコア:1)
IE独自拡張をサポートすることで特に問題がなければ、
ユーザを獲得することや作成者の意図通り表示できるので、
プラスになると思いますけどね。
#日本でも結構使われていると思いますよ
Re:marquree ふたたび (スコア:1)
もじら組web標準プロジェクト [mozilla.gr.jp]とその前身のウェブテストプロジェクトでは そういう方にIE以外では動かないと伝え、代替案を提供していました。比較的アクティブに動いているサイト運営者は代替案を受け入れ、そうでない方は放置というのがほとんどでした。(もう二年前の話かぁ、懐かしいなぁ~)
で、この報告はmozilla.orgへしたはずなんですけどねぇ...(汗
# しかし、タレコミでtypoは恥ずかしいなぁ、俺...まぁ、組長なんで恥さらしにしといてください(わら
三日風呂に入らなかったら、あなたはすめるまんです。
部門名が読めません (スコア:1)
>ふき【不覊】
> 縛りつけられないこと。
> 束縛されないこと。押さえつけにくいこと。
> 才識すぐれて常規で律し切れないこと
と言うことでした。
新鮮な用字例その3 [nifty.com]より
Re:部門名が読めません (スコア:0)
それは (スコア:0)
#「俺のこの手が光って唸る!」
ダウト(激しくオフトピ) (スコア:1, 参考になる)
某格闘G○NDAMは氏の小説に多くの影響を受けています(登場人物とか)。
一度読んでみることをお勧めします。
mozilla.org見やすくなってますね (スコア:1)
飛ぶ方法を、訪れるたびに忘れてしまうので、わざわざFirebirdの
ページのブックマークを作ってたんですが、これからはその必要も
無さそう。
Tableレイアウト (スコア:1)
と思ってるのは僕だけでしょうか?
gy0
Re:Tableレイアウト (スコア:1)
見栄えがどうとか、可読性がどうとかではなく、mozillaなんだからもう信条的に止めようや、ってことではないかと。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:Tableレイアウト (スコア:1)
わからないことはないし、この前ちょっとしたページを
いろんなサイトを参考に、CSSでレイアウトして作ってみたんだけど、
ちょっと腑に落ちない部分がある。
CSS2で段組っぽいレイアウト、
メニューと本文に別れるようなレイアウトって、
つくっちゃって良いものなの?
結果としてmenu部分をfloatにして、
本文部分にmargin-leftをつけたら、それっぽいものができたけど、
ほんとにこういう作り方でいいのかなあ。
Re:Tableレイアウト (スコア:1)
No-Style [sakura.ne.jp]とPurple [sakura.ne.jp]のレンダリング結果を見比べてみて、素の状態でのただの箇条書きと、全く同一のソースに対するスタイル適用だけで実現しているレイアウトと、それらを実現している各CSSの内容を見てみましょう。
最終的な見栄えを元にレイアウトを作るにしても、一度ただの箇条書きのレベルに組み直して素のHTML文書を作り、そこにCSS等でどのように味付けするかを再定義していくってのがよろしいかと。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:Tableレイアウト (スコア:1)
いいんじゃないでしょうか。 [w3.org]
あとアクセシビリティ [zspc.com]の面から言ってもそっちが推奨されると思います。
Re:Tableレイアウト (スコア:1)
CSSを用いた段組の作成のコツ [fromdfj.net]によると、
とあるものですから。
それに、CSS3で段組レイアウトのための属性関係が追加されると聞いたような気もしたもので。
つまり、floatで段組っぽいものを作るのは、
tableで段組っぽいものを作るのと大して変わらないのではないか、
という不安ですね。(50歩と100歩に違いがあるのかもしれないけど)
Re:Tableレイアウト (スコア:1)
>つまり、floatで段組っぽいものを作るのは、
>tableで段組っぽいものを作るのと大して変わらないのではないか、
w3cの勧告ではどうかとかそういう事は実は全然詳しくないのですが、
明らかに前者より後者の方がずっと良いと僕は思います。
CSSは"見かけ"しか定義しない訳だから、
「本来の使い方」も糞もあるかい、というのが個人的見解。
まあ、実は僕がテーブルレイアウトを嫌うのは、
「自分はテーブルレイアウトが出来ない」からだったりします。
逆恨みというか逆ギレというかなんというか。
WYSIWYG式エディタの恩恵なのかもしれませんが、
「あんなややこしいこと良くやってられるなあ」、と
むしろ感心してもいます。
つーか、初めにテーブルレイアウトを考えた人は偉いと思いますです、はい。
"ヴァージョン4ブラウザ"時代を知らないからこんな事言ってられるのかもしれないけど。
gy0
Re:Tableレイアウト (スコア:1)
CSSのfloatとtableと、どちらが段組に「望ましいか」とかでなく、webを視覚的に利用しない人たちにとって、何が現実的に使えるか、という話です。レイアウトのためにtableを用いれば、スクリーンリーダーを通すと意味不明になってしまうでしょう。float方式ならば、単なる段落として処理される事が期待できます。
それは本来的な使い方じゃないしね、っていうのはこの場合、あくまでも補足です。
Re:Tableレイアウト (スコア:1)
> CSSは"見かけ"しか定義しない
これは間違いです。
少なくともCSS2からは、そうでない事を志しているはずです。
本家のCSS(特に末尾) [w3.org]とかCSS2の@mediaのお話 [w3.org]を参考にされてはいかがでしょうか。
Re:Tableレイアウト (スコア:1)
CSS3 multi-column layoutモジュール [w3.org]ですが、文字通りの段組を実現するもののようですね。これをレイアウトに流用するのは、テーブルを流用するのよりも難しそうに感じます (段落のbreak位置を指定する特性が見当たらないし)。
少なくともfloat特性でレイアウトするようにしておけば、より好ましい方法を知ったときに修正が容易である、というのはメリットにはなりませんか? テーブルレイアウトでは必ずHTMLから修正しなければならないわけですし。
まぁとか言っても、サイト利用者層としてPCを想定すれば、テーブルレイアウトを採るというのも現実的な解かも知れません。旧いUA (mozilla.orgの場合はNetscape4も含まれるでしょう) に対する対処法としては未だに有効だと思います。逆に携帯端末を考慮すればfloat特性でのレイアウトの方が好ましいでしょう。
# position:absoluteという選択肢も… どこでも配置モード?(w
Re:Tableレイアウト (スコア:1)
そういうことについて一番大きい声で話をしているのが
IBMのアクセシビリティ関係 [ibm.com]かな、と思って見に行ったら、
tableレイアウトで作ってありましたよ。
さすがに、自分たちがリリースしている音声ブラウザのページまで
まともに読めないようには作っていないと思うので(現在体験版をダウンロード中)、
適切に作ればtableでも問題ない、ってことかしら。
Re:Tableレイアウト (スコア:1)
>というのはメリットにはなりませんか? テーブルレイアウトでは必ずHTMLから修正しなければならないわけですし。
どうせ、そういうタイプのページを作る際にはテンプレート作って
流し込むだけなので、あんまり変わらないです。
ところで、確かに頂いたリンク先を見ると、メニュー+本文な構造には
ちょっと使いにくそうですね。段組な属性。
Re:Tableレイアウト (スコア:1)
ソース見ましたが、怪しそうですね。自分も昔、sun.comのアクセシビリティのページに言ったら、フォントが固定サイズになっていて愕然とした事があります。
(これだとうちの親父のような老眼の人間は文字を拡大できません。ここら辺はブラウザ側でも対処すべきかも)
> 適切に作ればtableでも問題ない
これもある程度、受け入れられると思います。#360595 [srad.jp]でも書きましたが、ブラウザがCSSをサポートしておらずレイアウト用tableを使わなければならない時の工夫として、線形化されたテーブル [zspc.com]があります。
Re:Tableレイアウト (スコア:2, 参考になる)
#360407 [srad.jp]も参考にして頂きたいのですが、「レイアウトのみのための<table>」について、アクセシビリティの観点からだとACさんはどうお考えになりますか?
「Webとは、目で見るものとは限らない」というのはピンと来ない考え方かもしれませんが、もしCSSを用いた少しの工夫で、Webを「読んで」いる視覚障害者の方々が普通にページを読めるとしたら、望ましい事とは思いませんか?
そのために使える現実的な解としてたまたま、CSSがあるというだけで、自分はそれ以上の(悪い意味での)原理主義を主張する気はないです。
# うちのディスプレイとキーボードはちゃんとテーブルの上にあります ;)
# また一応書いときますが、アクセシビリティ・ガイドライン [zspc.com]では、
# 本来の表としての意味の<table>までは否定していませんし、
# そういう<table>はむしろ推奨されています。
# さらに、ブラウザのCSSサポートが想定できない時は、
# 線形化されたテーブル [zspc.com]という代案を推奨しています。
Re:Tableレイアウト (スコア:1)
いやいや、とんでもないです。むしろゆっくりした議論も、自分は好きです。
間が空くと議論に取り残されるとか、気になさらない方がいいと思いますよ。
その点、fjとかの方がゆっくりしてていいなー。
(相違点は多々ありますけれど…)
> そして、たぶん、Meyerさんもそう思っているからこそ、
>「次善の策」と書いていると考えます。
なるほど、おそらくMeyer氏も認識されているわけですね。
自分が議論していた内容も、「次善」の一言に尽きます。
> 法律が制定されているので
ここらへん [section508.gov]が詳しそうです。
このページの「固定px文字サイズが選択可=Accessible」というのは、
ユーザが選択肢を作れないという点で、ちょっと疑問ですね。
またあまり関係ないですが、自分はこれが何の508条かなのか存じません…。
> 近い将来、今の手話を使わずとも、誰でも意思疎通ができるような、
> そのようなツールを、Web の技術に携わる開発者の方々には
> 作っていただきたいものです。
より賢い音声ブラウザ、という以上のものを指していらっしゃるのでしょうか。
情報化社会最大の問題(言いすぎかな)である「後方互換性との戦い」に
打ち勝てるツールが将来もし、出現すれば理想ですね。
オフトピご容赦 (スコア:0)
スバルってあちらのアレゲな人たちにはpoorman'sポルシェみたいな位置にいるんでしょうか?
Re:オフトピご容赦 (スコア:2, 参考になる)
# 今は売られてんのかな?<WRX
なおMozilla1.4のスクリーンショットはスカイラインクーペですな。
かなり趣味が入っていると思われます(笑)
-- sun burst.
Re:オフトピご容赦 (スコア:1)
ランエボ/インプ共に、現在は正規に欧米に輸出されているようで、
アレゲなくるま好きの間では、「プレミアム・カー」として、立派に
認知されているようです。
Mozilla のアレゲな人々も、そんなくるまに Clarion Auto PC など
積んで、Windows CE 版の Mozilla なんかを密かに作って積んでたり
…ってことはないか…???
# 小生、Windows 系は疎いので、よく解からんのでしが…(^_^;;
自称・アレゲな幌車莫迦(^_^;;
Re:オフトピご容赦 (スコア:1)
インプはちっとも「poorman's」ではないらしいですね。欧州側から見たら日本車は当然「輸入車」で、値段が倍近くになってしまう(インプだと600万前後)とのこと。
これが流通の少なさの一因だそうです。
加えて、モータースポーツは向こうの方がはるかメジャーなわけで、そこで活躍する「高級」日本車は「ポルシェやフェラーリのように見られる」そうです。
というわけで、mekaさんご指摘の通り「プレミアム・カー」なわけです。
(インプの話として聞きましたが、ランエボも同様の事情と思います)
# ただ排ガス規制に厳しいEUの事、欧州正規ルートのインプは
# 日本のと比べて相当パワーダウンしてる…のは秘密らしいです
なぜまだmarquee問題を引っ張る (スコア:0)
http://bugzilla.mozilla.org/show_bug.cgi?id=159839#c8 [mozilla.org]
これと
http://srad.jp/comments.pl?sid=36706&cid=140210 [srad.jp]
これに尽きると思うけどなあ.
Re:なぜまだmarquee問題を引っ張る (スコア:2, すばらしい洞察)
ぶり返すようでわるいとおもうんですが…
タレコミ文のコメントに異議あり。
W3Cの規格というやつは勧告であるはずです。標準として遵守すべき努力義務ではあると思いますが、ブラウザが規格を超えた機能をサポートしてはいけないというのはおかしなお話ではないでしょうか。
Mozillaのサポートは、(政治的な理由があったにせよ)利用者に考慮した必要悪としての実装だと個人的には思ってるんだけどなぁ。もちろん、好きではなかったけど。(Mozillaは、「marquree要素は今回仕方なくサポートしたけど、次回はないと思うから代替手段を考えてよ」って啓蒙を進めれば良いわけだし…。
--労使曰く、ひとごとを尽くして神頼み--
ZDNetの記事 (スコア:0)
“Mozillaプロジェクトは方向性を変えてプログラムの軽量化を目指し、将来版ブラウザの基盤として、OS固有のコードではなくWeb標準を選んだ(4月4日の記事参照 [zdnet.co.jp])。この変更が行われる前の最後のメジャーリリース [mozilla.org]は、6月後半に開発者コミュニティに向けてリリースされた。”
とあるが、OS固有のコードではなく~って、Mozilla Classic(Netscape5.0)の破棄の事だよなぁ?
何か、此の記事間違ってないか…?(まぁ、何時もの事なのかも知れんが)
Re:ZDNetの記事 (スコア:1, 参考になる)
ZDNet-Jの4月4日の記事 [zdnet.co.jp]は mozilla seamonkey から mozilla phoenix(後の mozilla firebird)への切り替えの話なので Mozilla Classic という理解は誤りです。
でね、あなたが引用している ZDNet-Jの記事「”AOL、レイオフでNetscapeをさらなる苦境に [zdnet.co.jp]」の記述がへんてこなのは、その記事の記者が4月4日の記事 [zdnet.co.jp] を読み間違えているからです。
4月4日の記事 [zdnet.co.jp] で「プラットフォーム固有のコンピュータコーディング言語ではなく、標準的なWeb技術によるブラウザ設計を実現する」といっているのは「NetscapeとMozillaのエンジニアが4年前に導入したXULという言語」に対する説明です。
Appleが mozilla(gecko)ではなくKHTMLを選んだできごとの後におこった mozilla.org のイベントは、mozilla seamonkey から mozilla phoenix(後の mozilla firebird)への切り替えですからね。
まぁしょうがないですよ、ZDNetですから。
Re:基本的なお話 (スコア:2, 参考になる)
という事はXULの部分を改良すればボトルネックはかなり解消されるって事です。別にその仕組みが絶対に重いってわけじゃないんですよ。それ以外にもいろいろチューニングされてるようですが、基本はそこですね。
三日風呂に入らなかったら、あなたはすめるまんです。
Mozilla Firebird雑感 (スコア:1)
0.6は常用レベルに達していると僕は判断しています。
一度ためしてみてはいかがでしょうか?(布教モード)
IEの出番が完全に無くなるということはありませんが...。
こちらの売り文句も、おおむね正しいかな?と
http://jt.mozilla.gr.jp/projects/firebird/why/ [mozilla.gr.jp]
Re:バージョンアップしづらい (スコア:3, 参考になる)
この手の悩みは万人共通ですね。私はMozilla FirebirdやMozilla Thunderbirdを使ってるんですが、以下が私が採用しているプロファイル移行手順です。実際に移行時に行う作業は3番以降ですね。
大体こんな感じで。一番問題がありそうなのがXULキャッシュファイル(Windowsで言うところの XUL.mfl)で、最低限これを削除すればいいようにも思います。プロファイルデータのインポート・エクスポートが実装されていない [mozilla.org]のは確かに敷居を高くしていると思います。が、vote数を見ると…。
Re:バージョンアップしづらい (スコア:1)
バージョンを上げる時には念のためと云うコトで「bookmarks.html」「cookies.txt」「cookperm.txt」「history.dat」「localstore.rdf」「panels.rdf」「prefs.js」「user.js」を別ディレクトリにコピーして取っておき、上記以外のファイル・ディレクトリを全部消します。更に私は、バージョンを上げたあとにPreferencesメニュー内の全ての設定は見直すことにしてますので(機能確認とかより良い設定への変更のためとかが理由)、「prefs.js」の設定ファイルも消してしまいます。
更に、心配性、かつ、Windowsユーザな私は、使用しているmozillaをアンインストールしてから改めて新版をインストールします。
インストール後は、普通に起動すれば今まで使っていたプロファイルはだいたいそのまま使えます。
たまにあるバギーなビルドやファイルの内部構造変化でマズいことになったりしたら、逆の手順でバージョンを落とし、バックアップを取っておいた各種ファイルを差し戻して復旧します。
という感じで、勘所さえ掴んでおけばそんなに手間ではないかと。
最近はかなり馴染んできているのか、「prefs.js」はそのままでも結構平気ですし。
#もし、上記程度の手間さえ厭だというなら、mozillaは使うべきではないですし…
なお、各種ファイルを格納してある「セキュリティ対策としてのランダムな文字列.slt」ディレクトリはそのまま使い回します。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:バージョンアップしづらい (スコア:1, すばらしい洞察)
シェアを拡張しようと思うなら、現ユーザーには必須でなくてもある程度戦略的に機能を実装していくべきかも。
バージョンあげるたびにファイルをいじるんじゃ普通の人は引いてあたり前だよなあ。
Re:バージョンアップしづらい (スコア:1)
ですので、互換性が乏しくても仕方ないです。
ちなみに私もbookmarkのみ受け継いで後はやり直す派です。
理由は、さほど設定をいじらないことと、せっかくなのでデフォルトで動かして見たいから。
ただ、駄目元で、古い設定ファイルを一つずつコピーしてみたりはします。
手を入れてるのはせいぜいプロキシ周りだけなので、大概は上手く動いているように「見えます」(^^;
#でも気持ち悪くて、結局消してやり直すことに…