元スレ+ JavaScript の質問用スレッド vol.133 +

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

701 = :

ちょｗｗｗ俺おもしろすぎｗｗｗ
ギャグのセンスはんぱないｗｗｗ

702 = :

おっと誤爆失礼

703 = :

contenteditableな要素の中に作られるタグについてですが
chromeでは一行ずつdivで囲んでるんだな、と思っていました
実際ただキーボードから文字を入力していった時に作られるタグはそのようものです
しかし文字列をペーストすると、
<div><div>1行目</div><div>2行目</div></div>
みたいな、複数行を包含する無用で意味不明なdivが出来ることに気づきました
一体どんなアルゴリズムがこんなタグを生成するのでしょうか？
キャレットのある行を知る時には一番外側のdivを見つければいい、と思っていたのですが、
このくそアルゴリズムの生成するくそタグだと正しく検出できません
キャレットのある行を見つけるにはどうすればいいですか？

704 = :

一番外側のdivでなく、一番内側のdivなら検出できそうです
chromeではselectionの境界は必ずテキストノードの中をポイントするようなので。
それはそれで合理的な挙動ですが、
他のブラウザだとそのあたりの挙動も違います
divとdivの間をポイントしたりします
・生成されるタグがくそ
・生成されるタグがブラウザによってまちまち
・selectionの境界の取り方もブラウザによってまちまち
何重にもひどい条件をかいくぐってまともに動くものを作るのはなかなかヘビーですね？

705 = :

>>699
それは知ってるが、作者がどう言ってるかが全てではないだろう
君は親から、お前のココが失敗だったと言われたらずっとそう思い続ける残念な人なのか？
実際その時はそこだけ取り上げると客観的に見て欠点だったとしても、
そいつが成人して、世の中の流れも多少変わってるし、別に取り上げて何か言うべきことで無くなってる可能性もあるだろう

俺は君が考えた君だけの考えがあるなら大いに聞いてみたいが、
そんな聖書にそう書いてあるから！みたいな淡白な意見は何の発展性もないし関心がない
人が言ったことを自分の意見にするなという意味ではないぞ、むしろそれは良いこと
つまりその作者がどうしてそう言ったのかを、色々な視点から捉えて、
その意図を自分の中で消化して、君自信の意見として君の言葉で解説して欲しいと思う

706 = :

>>705
要約すると、お前がそう言ってるだけでなので、
お前の言うことなんか無視すべきってことだな

707 :

バカ：
箱を落として中のケーキがグチャグチャになったが、もう戻らないことを嘆いても仕方ない。
このグチャグチャのケーキのいいところを探そう！
俺はこのグチャグチャのケーキも結構イケてると思う！

天才俺：
このケーキがグチャグチャなのは、移送中に箱を落としたから。
移送者の証言があるからこれは間違いない。

708 = :

>>707
俺は確かにいいところを探して良いように使うのはJSにおいてとても重要だと思うが、
今回はそういったことを言ってるんじゃないぞ

そもそも横向きに他の食べ物と一緒に入れられていて
箱を落として無かったとしても潰れて混ざってて綺麗に食えたもんじゃない
どっちみち細かく切ってそういう食べ物ですと言って誤魔化して出すくらいしかなく、
落として無かったら切り方がちょっと大雑把で済むくらいのもの

だから綺麗に食べられないことに関して箱を落としたことを悔やむのはバカなこと
だがそもそも本当にパーティの賑やかしとして必要なものはピザの方じゃないのか
ってことを言ってる

709 :

例えを中心に論をくみたてるやつはたいていばか

710 = :

ピザに話題を反らそうとも、ケーキがグチャグチャな事実は変わらない。

typeof nullが仕様バグであるという事実は、typeof nullの重要性の多寡によっては覆せないのだ！

711 = :

typeof null限定の話ではなく一般論の話をしよう
一般論ではどんな人でも言ってることが間違っていることがあるだろう？
だから、間違いなんだよ

712 = :

ここまで読み飛ばした

713 = :

ピザポテトを管理するjsでも作ってろよ

714 = :

一般人「typeof nullは仕様バグ(ﾎﾞｿｯ)」
バカ「俺はtypeof nullが仕様バグとは思わない！」
天才「いや作者が仕様バグと認めてるんだけど…」
バカ「typeof nullが仕様バグかどうかはどうでもいい。他のことの方が重要！」

他のことの方が重要なのはそうかもしれないのだがこれじゃ思い違いをゴマかすために話題そらしたみたいにしか見えないｗｗ

715 = :

バグ、仕様バグって言葉の認識に差がありそう

本当に頭悪いバカはバグとか言わずに糞言語と100回連呼するのだと思う
そんで使用者を罵倒して煽る

716 = :

バグって10回言って

バグバグバグバグバグバグバグバグバグ

9回しか言ってないじゃん

717 = :

>>711
「だから、間違っていることがあるんだよ」が正しい(確定ではない)

718 = :

ハゲって10回言って

719 = :

>>705
> それは知ってるが、作者がどう言ってるかが全てではないだろう
「仕様バグ」は作者でなければ、定義出来ないぞ
>>697がいっているのは「>>697の解釈」であって「仕様バグ」ではない

720 = :

ajaxって今はあんまりつかわないの?

721 = :

一般に普及しGoogleのような大企業じゃなくても誰でも普通に使えるようになったので、ajaxとかカッコつけて言わなくなっただけ。

722 = :

ajaxの代替になるもので流行り始めてるものとかもないの?

724 = :

ajax と言えば、jQuery

これだけのために、jQueryを使う人もいる

725 = :

正直、楽だからねえ……

726 = :

>>722
Axios や SuperAgent が有名だよ

727 = :

google書籍検索で引っかかってきた原書のサイ本に、日本語版に書いてないことが書いてあったので
調べてみると日本語版は、原書のリファレンス編が「JavaScriptリファレンス」という別の本になっている
ということに気づきました
紙の本だとおそろしく太くなってしまうからでしょう
電書を購入しました
知らないことが大量に詳しく書かれています
しかしそれが知りたくて買ったRangeオブジェクトとSelectionオブジェクトについては、何故か全く書かれていません
何故でしょうか？あほなのでしょうか？

728 = :

>>727
> 何故でしょうか？
全てを網羅すると途方もない文量(引いては値段)になるからでしょう。

> あほなのでしょうか？
あほです(あなたが)

729 = :

>>727
JavaScriptにはRangeもSelectionも存在しない。
ブラウザが提供しているAPIでライブラリと同等のもの
だからこのスレからライブラリの話はなくせと言ってる

730 = :

>>729
この本は「コアJavaScriptリファレンス」と「クライアントサイドJavaScriptリファレンス」に分けて説明しています
クライアントサイドJavaScriptの章では、CanvasやGeolocationやHistoryやStorageなど、
あなたが言うライブラリと同等のものが大量に紹介されています
しかしRangeとSelectionはないのです
あほとしか言い様がありません

731 = :

>>728
リファレンスの価値は、可能な限り全部を載せるということでしょう
あほとしか言い様がありません（あなたが）

732 = :

>>730
それよりもサーバーサイドJavaScriptが
まるまる抜け落ちてるのはどういうわけ？

733 = :

>>727
こんなとこで聞いて何がしたいのでしょう?
出版社に問い合わせればいいだけなのではないでしょうか?
あほなのでしょうか?

734 = :

>>733
何がしたい？もうしてますよ
あんたをイラつかせること
それがしたいことで、すでにやっていて結果もでてることですよ
出版社に問い合わせてもあなたをイラつかせることにはなりません
それもわからないあほなのでしょうか？

735 = :

もう来ないっつったんだからもう来んなよ

736 = :

そもそも翻訳の出来に左右される日本語版を買うのがあほ。
リファレンスは原著買うのが普通。

737 = :

>>727
微妙なAPIだからね
マイナーだし、HTML5になる過程で一応仕様がデファクトに合わせて整備されなおされたけど
今後の発展性もないし取り上げて面白いAPIではないだろうからね

738 = :

>>734
で、出版社はなんてこたえたの?

739 = :

>>734
この人は偽者ですよ
出版社に問い合わせたところで何も変わらないでしょう
それよりも、何故そうなったのかを公開の場で検討した方がはるかに生産的です

740 = :

>>732
Node.jsの本に任せているのでしょう
JavaScriptはそもそもの生まれがクライアントサイドスクリプトですし。
そういう意味でそこは妥当だと思います

741 = :

>>737
発展性というか、基本的な機能だと思いますが・・
特に昨今JavaScriptの役割がアプリと同一化しているので、
もっと光を当てるべき機能だと思います
エディタ的なものを作る時には必須のオブジェクトなのですから

742 = :

>>734
別にオレイライラしてないよ。
やった意味なかったね。

743 = :

>742
レスしたのが証拠ｗ

744 = :

electronで作られているVSCodeのエディタ部分はどういう実装になっているのでしょうか？

745 = :

>>739
どう生産的なの?
著者と出版社に、自分はこう思うのでコレも書けって意見送ればいいだけでは?

746 = :

>>744
ボク？オープンソースって意味わかりまちゅか？
http://github.com/Microsoft/vscode

747 = :

エディタ部はmonaco
http://github.com/Microsoft/monaco-editor

748 = :

原書は検索するとpdfでおっこちてること多いよなぁ。
公式なのか違法なのか知らんけど。

749 = :

これ著者のツイッターアカウントだろ?
http://twitter.com/__davidflanagan
とりあえずツイッターで聞いてきなよ。

750 = :

>>741
別に光を当てても選択範囲が取れますで終わりでしょ
エディタを作るのに必要でこれから考えないといけないのは
入力領域やIME制御のAPIだと思うけど

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ

類似してるかもしれないスレッド

• + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
• + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
• + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
• + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
• + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
• + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
• + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
• + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
• + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
• + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
• + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
• + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
• + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
• + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
• + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
• + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
• + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45