- 1 名前：デフォルトの名無しさん [2020/09/07(月) 18:56:51.64 ID:4fn7uU/g.net]
- スレ立てるまでもない質問はここで 154匹目
- 48 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 09:58:18.35 ID:Ln963FmW.net]
- 全部できないゴミエンジニアが多すぎなんだよ
htmlとcssを使えばクオリティ高いUI/UXを作れるのにそもそもセンスなさすぎて
昔のボタン配置したUIみたいなのしか作れず画面は崩れる
そのくせhtmlとcssをバカにする
- 49 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 10:40:58.32 ID:+npDkJjj.net]
- cssはゴミでしょ
webの世界でもコンポーネント指向が主流になってきてる
コンポーネント指向だとスタイルもコンポーネントに閉じ込めるからcssなんていらん
cssを無くしてelementの視覚属性を拡充すべきだった
- 50 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 10:53:00.71 ID:F8eJvx/w.net]
- CSSとコンポーネントは併用して使うものなんだが
HTMLの本質である文書と視覚の分離を理解してるか？
- 51 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 12:07:22.32 ID:Xp7zp8nz.net]
- コンポーネントごとに見た目がバラバラだったりすると再利用もしたくないなぁ。
- 52 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:02:28.70 ID:JiEeR27v.net]
- >>50
君はまず先に文章とアプリケーションの区別をつけたほうがいい
セマンティクスな文章構造を装飾するにはcssがフィットするがアプリケーションでは逆にやりにくくなる
アプリケーション開発に最適化するためにコンポーネントという概念が生まれてスタイルもコンポーネントに埋め込むようになった
>>51
見た目を調整したいならコンポーネントのスタイルをオーバーライドするだけだ
cssだと逆にUIフレームワークが定めた見た目を部分的に変更することが難しい
なぜならcssは継承やコンポジションをサポートしないから
- 53 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:09:14.64 ID:C1zUubdH.net]
- > セマンティクスな文章構造を装飾するにはcssがフィットするが
手のひらクルックルｗ
- 54 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:11:08.06 ID:C1zUubdH.net]
- > 見た目を調整したいならコンポーネントのスタイルをオーバーライドするだけだ
じゃあユーザースタイルシートで変更する方法を書いてみて
- 55 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:25:18.52 ID:I60CiHSB.net]
- >>53
もう一度いうよ
文章とアプリケーションの区別をしろ
>>54
アプリケーションではそんな需要はまずない
- 56 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:37:54.61 ID:d/ryA4WH.net]
- >>52
>見た目を調整したいならコンポーネントのスタイルをオーバーライドするだけだ
おいおいw
- 57 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 13:59:21.00 ID:Xp7zp8nz.net]
- >なぜならcssは継承やコンポジションをサポートしないから
cssのそこを直接改善すれば済む話だと思うが、それ以前に
>cssだと逆にUIフレームワークが定めた見た目を部分的に変更することが難しい
アプリケーション開発者の立場でそれが難しいとは思わんのだが。
もしコンポーネント開発茶の立場で言っているのだとしたら何をやりたいのかよくわからん。
- 58 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 14:08:40.06 ID:lqAY86+l.net]
- 板違いなんだがここは雑談スレなのか？雑談スレならスレごと板違いなんだが
htmlの見た目を部分で変えたいとかHTML5やJavaScriptでできるんだからその手の板でやれ
- 59 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 14:22:35.07 ID:jqobtGhf.net]
- >>57
難しいというか面倒くさい
せっかくコンポーネントに隠したhtml構造とcss class名を調べて、それに合わせてカスタムcssを作らなきゃいけないじゃん
まるで、メタプログラミングでプライベート変数にアクセスするような気持ちの悪さを感じる
コンポーネントの構造を変えたくなった時にもカスタムcssが壊れないか注意を払わなきゃいけない
コンポーネントが直接スタイル属性をサポートしてれば、たとえば幅を変えたいならコンポーネントのwidth属性を変えるだけ
使う方は内部のhtml構造もcss classも何も知らなくていい
こっちのほうがわかりやすいしメンテナンス性も高い
- 60 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 15:08:38.71 ID:C1zUubdH.net]
- ウェブの大半はアプリケーションではない
CSSはウェブの大半で有効に使える
それが証明されましたねｗ
- 61 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:22:03.28 ID:Ln963FmW.net]
- >>52
sassがあるんですが？無知乙
あと部分的に変更はclassをあてるんだよ無知野郎
>>59
width属性を変えるだけとかいう阿部寛の時代感覚だからそういう回答してるんだよ
今はレスポンシブなのでwidthは変えなくても幅に合わせて可変デザインなわけ
- 62 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:31:14.83 ID:24n75C+P.net]
- >>61
sass頼りとかネイティブじゃ欠陥品と認めたようなもの
部分変更のためにまたclass追加すんのか
そうやって管理対象をばかすか増やすなよ
メンテナンス性も考えろ
ただの例示に噛み付いて本質を見失うアホの典型例
コンポーネントの描画パラメータをインターフェースとして定義してクライアントに提供できることがコンポーネントの利点だと言っている
widthに限った話ではない
- 63 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:36:01.82 ID:8aNWh6BR.net]
- > sass頼りとかネイティブじゃ欠陥品と認めたようなもの
せやな。JavaScriptフレームワークに頼るのはやめような
- 64 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:43:40.14 ID:Ln963FmW.net]
- >>62
お前はまともにUI作れないゴミクズのくせに随分偉そうだな
メンテナンス以前にセンスゼロじゃんwww
口だけ野郎が
- 65 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:45:31.52 ID:24n75C+P.net]
- >>64
ハイ罵倒するしかできなくなった
お前の負け〜
- 66 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:51:39.99 ID:8aNWh6BR.net]
- >>62
ちゃんとレスポンシブデザインに対応したコンポーネント作ってるか？
- 67 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:54:23.85 ID:24n75C+P.net]
- >>66
そりゃ対応するだろ
そしてしない場合もある
コンポーネントならそれらを切り替えるのもコンポーネントの属性を指定するだけだ
- 68 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 17:59:40.45 ID:Ln963FmW.net]
- >>65
いやお前実際にUI作れないじゃん
全部コンポーネントの中にパラメータとかアホか？
コンポーネント間で共有するのにパラメータ化すんの？
クライアントはいい迷惑だな
しかもゴミのようなセンスだし
- 69 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:07:56.68 ID:24n75C+P.net]
- >>68
本当にアホなんだなあ
パラメータにデフォルト値があるってことすら思い至らないんだ
まさかクライアント側で全てのパラメータを一個一個指定するとでも思ったのかね
それに違和感を感じないとかセンスを疑うワ
酷いインターフェース作りそうだなこいつ
一緒に働いてる同僚が可愛そう
- 70 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:18:44.33 ID:Ln963FmW.net]
- >>69
そもそもお前みたいな時代遅れ野郎に付き合ってやってる俺に感謝しろよ
デフォルト値とかの話じゃねえんだよ
css側にUIの状態を持たせるのはフロントの処理と分けるためだ
フロントの状態が変わればcssが勝手にUIが変更されるんだよ
widthのパラメータを変えなくても勝手に変わるわけ
これは他のcssプロパティでも同じ
その設計ができないからお前は的外れなゴミクズ発想しかできないんだよ
コンポーネント内にパラメータやデフォルト値を持たせたらカオスになるだろ
わかったか
- 71 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:26:17.77 ID:24n75C+P.net]
- やっぱフロント屋ってセンスねんだな
コンポーネントの基本中の基本すらわかってない
クライアントにはそのコンポーネントの仕様を表現したインターフェースを提供せよ
クライアントがコンポーネントを利用するのにその実装に依存した記述をしなければならないならそのコンポーネントは欠陥品である
CSSってのはまさにその欠陥品そのものなんだわな
CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
htmlの構造を変えるにはCSSを詳しく調べないといけない
それを怠るとデザインが簡単に崩れる
アホくさ
クライアントがコンポーネントの中身のhtml構造とcssまで把握しなきゃならないならメンテナンス性を著しく損ねてるってことだ
クライアントはコンポーネントの提供するインターフェースに従って属性を変更すればそれでいい
クライアントはコンポーネントの詳細を知る必要はない
コンポーネントはクライアントにハックされて調和を乱される心配をしなくていい
それが正常な世界のあり方だ
- 72 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:27:26.44 ID:8aNWh6BR.net]
- >>67
レスポンシブに対応するかは、コンポーネント側で決めることではない
- 73 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:31:35.99 ID:8aNWh6BR.net]
- >>71
根本的に考えがずれてる
CSSというのは文書構造に対して後から適用するものだ
HTMLというのは構造化された情報の集まりだ
そこにCSSを適用することで、自由にデザインを変更することができる
お前は適当に作ってるから情報の集まりであるHTMLが構造化されていない
HTMLというデータの仕様がまったくない
いきあたりばったりで生成するHTMLを作ってる
まず生成するHTMLの仕様を定義しろ
> CSSをカスタムするにはhtmlの構造を詳しく調べないといけない
HTMLの仕様が最初に定義されてるんだから、これは依存関係が逆になる
htmlの構造が詳しく定義されてる のだからCSSをカスタムするのは容易だ
- 74 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:31:41.98 ID:Ln963FmW.net]
- フロント屋ってなんだ？フロントできないゴミエンジニアのお前はバックエンド屋なのか
当たり前だがバックエンドもインフラもやれてフロントもやれるのが当然なわけ
つまりこのゴミクソ野郎は無能だから吠えて何も解決策は出していない
そもそもUI作れないからクライアントに納品できないからな
- 75 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:33:54.66 ID:24n75C+P.net]
- まあCSSが全てにおいて悪センスなわけじゃない
たとえば、Markdownの生成するHTMLのようにある程度決まりきった単純な構造を持ったドキュメントに対して、クライアントの好きなデザインを適用したい、などといった場合には少ない労力で対応できる
が、これをより複雑で実装の変化も速い構造になりがちな、アプリケーションで同じ手法でやろうとするのは馬鹿げてる
- 76 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:36:18.02 ID:8aNWh6BR.net]
- コンポーネントが生成するHTMLが定義されない状態で
どうやってテストできるというのか
HTMLの構造は詳しく調べるものではない
仕様書として定義するものだ
- 77 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:38:51.05 ID:Xp7zp8nz.net]
- >>71
結局これ、コンポーネント開発者が用意したカスタマイズポイントしか触らせないという発想だろ？
やっぱり見た目のちぐはぐなコンポーネントの寄せ集めになる未来しか見えない。
- 78 名前：デフォルトの名無しさん [2020/09/13(日) 18:43:14.83 ID:lu6eiMc4.net]
- ちぐはぐにならないようにグローバルなスタイルは外部から注入する形
にすればいいんでないか？
- 79 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:44:26.17 ID:24n75C+P.net]
- >>76
はぁ┐(´д｀)┌ﾔﾚﾔﾚ
出力されるhtmlは仕様じゃない
実装だよ
コンポーネントの仕様ってのはいいか？
そのコンポーネントのカスタムタグ名はなんですか
そのタグをおいたらどういった物が描画されるんですか
クライアントがコントロール可能なパラメータはなんですか
それらをコントロールするにはどの属性を変えればいいんですか
どの属性にどんな値を設定したらどうなりますか
そういうことを厳密に定めた文書のことを「仕様」と言うんだ
仕様にはHTMLなんてものはどこにも出てこない
なぜならHTMLは仕様ではなく実装の詳細だからだ
ま、肌感覚でテキトーな仕事ばっかしてるウェブ系キッズじゃ、正しい仕様とか言われても理解が難しいだろうけどな
- 80 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:50:44.01 ID:8aNWh6BR.net]
- >>79
HTMLを実装とか意味不明ｗ
コンポーネントの仕様ってのはいいか？
このコンポーネントを配置したら
どういうHTMLが生成されるかって話なんだよ
そのHTMLがどういうレンダリングがされるかっていうのは
OSやブラウザによってバラバラだろ
HTMLがどう描画されるかHTMLの仕様ではない
- 81 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:52:30.01 ID:Ln963FmW.net]
- ゴミクズバックエンド脳が時代に取り残されてることにすら気づかず全世界の誰もが望まない欠陥方法をお披露目しているわけだがいつまで続くんだろうな
- 82 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 18:57:23.09 ID:24n75C+P.net]
- >>77
君は話を理解してるようだな
そのとおりだ
で、あるからして
どこからでも使われるような汎用的なコンポーネントは、より充実したカスタムポイントを提供するべきだろう
しかし、特定の組織、グループ、プロジェクト、システム内で共有できればよい
そのドメインに特化したコンポーネントは、要件を満たすのに必要十分なカスタムポイントを提供すればよい
要件の変化が生じて、新しいカスタムポイントが必要になったのなら、必要になった時点で追加すればいい
クライアントはコンポーネントのインターフェースに従って利用しているはずなので
後方互換性を維持したまま内部構造を柔軟に変えたり、インターフェースを拡張することは容易だ
ようするにYAGNIの法則だな
- 83 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:01:40.33 ID:24n75C+P.net]
- >>80
それは実装
クライアントがコンポーネントの内部構造まで厳密に知ってる前提では、タグブロックをコピペして使いまわしていた時代とほとんど大差がない
まさにWEB原始時代の方法論だ
- 84 名前：デフォルトの名無しさん [2020/09/13(日) 19:13:59.60 ID:lu6eiMc4.net]
- >複雑で実装の変化も速い構造になりがちな、アプリケーション
単純な構造をもったものの組み合わせなんじゃないの？
結局の所は
- 85 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:18:57.12 ID:8aNWh6BR.net]
- >>83
> それは実装
理由は？ 単におまえて主張してる過ぎない。
どういうHTMLを作るかは仕様できめること
好き勝手にHTMLを生成してはいけない
なぜならテストできないからだ
- 86 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:21:27.96 ID:8aNWh6BR.net]
- 生成するHTMLを仕様として定義しない場合は、実際に問題が発生する
それは既に書いてあるとおり書いてあるとおり
htmlの構造を変えるにはCSSを詳しく調べないといけなくなる
- 87 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:26:54.59 ID:24n75C+P.net]
- >>84
業務システムでは単純に見える項目でも内部が複雑化することはある
- 88 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:28:19.81 ID:8aNWh6BR.net]
- コンポーネントが生成するHTMLを仕様として定義すると
デザインを別の人が担当できるというメリットが有る
また生成するHTMLは仕様として決まってるわけだから
コンポーネントが完成する前から
デザイン担当者はデザインを作ることができる
- 89 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:31:29.63 ID:24n75C+P.net]
- >>85
HTMLは実装
仕様とは>>79のような物を言う
このような仕様を満たすために出力されるHTMLは実装にほかならない
仕様が先にありその仕様を満たすHTMLを実装するんだ
- 90 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:32:24.15 ID:Xp7zp8nz.net]
- >>82
だからスタイルはそれに当てはまらないだろう。
動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
それを変更できるようにしてもらうなら、それを使う側からしてみれば扱うカスタマイズポイントが
1つ増えるわけで、何のことはない結局内部構造を把握するのと手間は変わらないわけだ。
コンポーネント開発者側の手間が増えるだけで何もいいことはない。
- 91 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:33:22.59 ID:8aNWh6BR.net]
- >>89
> HTMLは実装
はい、また理由を言えない（笑）
- 92 名前：デフォルトの名無しさん [2020/09/13(日) 19:33:37.71 ID:qg7N5frC.net]
- ヤンクミの法則。
- 93 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:35:00.54 ID:8aNWh6BR.net]
- HTMLは仕様であり、先に定義することで
デザイナーとの分担作業が可能になる
どうせ大規模プロジェクトを経験してなくて
自分でデザインまで作ってるんだろうな
- 94 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:38:23.37 ID:8aNWh6BR.net]
- >>90
> 動作が同じだからといって内部で新しいエレメントが追加されたらそこだけ見た目が変わってしまう。
これ、フロントエンドを理解してないやつがよくやる間違い
内部で新しいエレメントを追加・削除しないと変えられないと思ってる
実際は状態（class属性等）に応じて表示状態（displayスタイルなど）を変更すればいいだけなのだ
class属性等に応じて表示状態を変えるだけだから
JavaScriptはシンプルになるし、速度も軽くなる
コンポーネントが完成していなくても静的なHTMLとして記述しclass属性等を
変更するだけで状態に応じたデザインを作ることができる（分担作業）
- 95 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:39:29.29 ID:8aNWh6BR.net]
- 状態（≒見た目）が変わっても内部構造は変わらない
これがシンプルな設計において重要な点
- 96 名前：デフォルトの名無しさん [2020/09/13(日) 19:42:49.59 ID:qg7N5frC.net]
- 単一の情報に対して複数の表示法を与えようとするのは、ウェブ作成者の多くがまともな大学を出ていないことと関係あるのでは？
- 97 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:46:07.97 ID:8aNWh6BR.net]
- 例えばタブインターフェースなんか、タブ1枚目、タブ2枚目、タブ3枚目があったとき
1枚目を表示するときは、1枚目だけを表示して、2枚目、3枚目は非表示にするだけでいいのだ
そのために必要なのはタブの表示ページ番号を示す属性を変更するだけ
あとは簡単なCSSですべてできる
JavaScriptはほんの3行程度、ラジオボタンを使えばJavaScriptゼロにだってできる
これをわざわざクリックされたときに1枚目を作成して
2枚目、3枚目は削除するなんてJavaScriptの処理を書いて
HTMLとCSSをJavaScriptに埋め込んで
わざわざして遅く面倒にしてるのが（アホな）コンポーネント厨
- 98 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:46:13.31 ID:24n75C+P.net]
- HTMLを仕様として定めると、そのHTMLを前提としたCSSが無秩序に量産されるというリスクがある
そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる
内部実装であるHTMLに、クライアントであるCSSが依存しているからだ
今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない
そういった変化があった場合に、コンポーネントのソースコード以外を変更する必要があるなら、そのコンポーネントはインターフェースと実装の分離ができていない証拠だ
HTMLを仕様と定めて、クライアントにCSSの実装を許すと、このような変化には耐えられなくなる
実装であるHTMLを外部に漏らしてはいけないのだ
- 99 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:47:46.26 ID:8aNWh6BR.net]
- >>96
お前の願望を言うのはお前が低学歴なのでは？ｗ
- 100 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:48:19.46 ID:8aNWh6BR.net]
- >>98
> HTMLを仕様として定めると、そのHTMLを前提としたCSSが無秩序に量産されるというリスクがある
ないよ
どこから出てきたんだか（笑）
- 101 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:48:57.79 ID:8aNWh6BR.net]
- >>98
> そうなると、既存のCSSを変えずに、コンポーネントの構造を変えることが難しくなる
コンポーネントの構造を変えようとするな
複雑になるだろ
- 102 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:49:06.63 ID:Xp7zp8nz.net]
- >>94
お前htmlの構造を変えるって言ってたじゃん。>>71>>86
- 103 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:49:59.28 ID:8aNWh6BR.net]
- >>98
> 今日はインプットテキストだったコンポーネントが、要件変更で明日にはリストボックスになっているかもしれない
だからそれ仕様変更ですよね（笑）
- 104 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:51:40.17 ID:8aNWh6BR.net]
- >>71は俺じゃねーよ
>>86にちゃんと書いてあんだろ
> 生成するHTMLを仕様として定義しない場合は、
> htmlの構造を変えるにはCSSを詳しく調べないといけなくなる
だからHTMLをしようとして定義し、HTMLの構造を変えるときは
仕様変更になると
- 105 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:52:24.50 ID:24n75C+P.net]
- >>97
単純なお遊びのアプリケーションしか作ったことがないとこういう発想になりがち
転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない
- 106 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:53:45.51 ID:8aNWh6BR.net]
- >>105
> 転送量やセキュリティの観点から非表示にするだけでなく要素そのものを取り除くことは珍しくもない
だからそういう理由があるときだけ複雑にしろよ
なぜやらなくていいときまで複雑にするのか→考える脳が無いから。全部同じやり方しますアポポッポポポｗ
- 107 名前：デフォルトの名無しさん [2020/09/13(日) 19:54:11.08 ID:qg7N5frC.net]
- 複数のビューとか、Excelで要らんってわかったんじゃないのか。
もう20年以上前にわかってるもんを、いまさらやってどうなるというのか。
やっぱウェブ系は頭悪いな。
- 108 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:54:39.72 ID:24n75C+P.net]
- >>101
遊びで作るようなちゃちいアプリケーションならそういうことを考えなくていいんだろうな
簡単そうな要件の仕事してそうで羨ましいよ
- 109 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:57:27.38 ID:24n75C+P.net]
- >>103
重要なポイントはその仕様変更の影響がコンポーネントの外部に漏れるかどうかだ
コンポーネントの内部実装としてスタイルを閉じ込めておけばコンポーネント以外は修正しなくていい
- 110 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:57:29.54 ID:8aNWh6BR.net]
- >>107
複数のビューが何を言ってるのか知らんけど、
コンポーネントの状態によって見た目が変わるのは普通の話
それをJavaScriptを使って状態によって構造を変化させて
CSSを適用しづらくして、うわーっとなって
全部JavaScriptにしてやるーって叫んでテストの工数を増やすか
状態が変わっても構造を変化させずに、同じ構造だから
CSSが適用しやすく、状態によっての見た目の違いはCSSでやれるから
JavaScriptコードが少なくなって、処理速度も速く
宣言的な記述でバグもテストも少なくなるかの違い
- 111 名前：デフォルトの名無しさん [2020/09/13(日) 19:58:05.27 ID:qg7N5frC.net]
- HTMLは文書ではない！データのコンテナなのだ！などと、グーグルの受け売りが正義とか思わないでほしいのだが。
ウェブ系の馬鹿は考える頭が付いていない。
- 112 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 19:58:06.54 ID:8aNWh6BR.net]
- >>109
HTMLの構造を変化させなければ、なにも外部にもれない
お前のやり方が根本的に間違ってるんだよ
- 113 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:02:13.75 ID:24n75C+P.net]
- >>106
理由が出来た時に容易に対応できるようにコンポーネントにするんだよ
- 114 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:03:05.61 ID:8aNWh6BR.net]
- >>113
YAGNI（それは必要にならない）
KISS（シンプルにしておけボケ）
- 115 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:08:02.62 ID:24n75C+P.net]
- >>112
いやいや
HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ
いざHTMLの構造を変える時に、無駄な調査工数がかかる
HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
なのでCSSを気軽に追加するバカもいなくなる
コンポーネント内部のHTML構造の変更のために、バカバカしい調査をする必要もなくなるわけだ
- 116 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:08:11.90 ID:bz2S3zJv.net]
- オンライン会議の参加者それぞれにexeファイル渡し、マイクから発言時間をリアルタイムで記録して会議の進行役が盛り上がり具合を見れるものを作ろうと思ってます
とりあえず触ったことのあるc#で音声認識ライブラリを使って時間を記録し、それをデータベースに送信して管理する形を考えているんですが
、言語とか使うデータベースこんなのがいいってありますか？
ズブズブの素人なので的はずれなこと言ってたらごめんなさい
- 117 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:08:45.61 ID:8aNWh6BR.net]
- >>115
> HTMLの構造はこうですって、仕様にしちゃったらそれはもう外部に漏れてんだよ
それは仕様なんだからインターフェースだ
デザイナと共同作業をする場合に必要なことだ
- 118 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:09:13.68 ID:8aNWh6BR.net]
- >>115
> その仕様を前提に、どこのだれがどんなCSSを書いたかなんてわからねえぞ
デザイナーの仕事だ、お前には関係ない話だ
- 119 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:09:31.03 ID:24n75C+P.net]
- >>114
した結果がコンポーネント
- 120 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:10:06.72 ID:8aNWh6BR.net]
- >>115
> いざHTMLの構造を変える時に、無駄な調査工数がかかる
いちいち変えるな。仕様として決めないで
いきあたりばったりで作業してるから、変えることになるんだろ
無駄な調査工数がかかるのも、いきあたりばったりで仕様を残してないからが一番の理由だな
- 121 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:10:48.20 ID:24n75C+P.net]
- >>117
インターフェースは軽々しく変えてはならない
HTML構造はインターフェースほど安定したものではない
ちょっとした要件の変化に応じて変えていくものだ
HTMLはインターフェースにはなりえない
- 122 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:11:24.96 ID:24n75C+P.net]
- >>118
関係ないで無視したらデザインがぶっ壊れるだろ
- 123 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:11:57.70 ID:8aNWh6BR.net]
- >>115
> HTMLは仕様ではなく実装である、とすればHTML構造はいつでも変化しうるんだ、ということが誰にでもわかる
HTMLの構造は要求が変わったときだけ変化する
見た目が変わっただけでは変化しない
逆に言うならば、見た目を変えるだけならば、HTMLの構造は変化しない
それはすなわちコンポーネントを変更する必要がないということだ
見た目は容易に変わるが、コンポーネントの機能はさほど変化しない
お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まで入るんだろうなｗ
- 124 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:12:48.01 ID:8aNWh6BR.net]
- >>122
> 関係ないで無視したらデザインがぶっ壊れるだろ
HTMLの構造を勝手に変えるからだ
仕様なんだからちゃんと連携とってかえろ
お前のように見た目とコンポーネントが強く結合してしまってりゃ
見た目の変更でコンポーネントに修正まではいってそれどころじゃないんだろうがなｗ
- 125 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:12:49.66 ID:24n75C+P.net]
- >>120
だから何度目だ
変えなくてもいいようなド単純なオモチャアプリケーションならHTMLは固定、で許されるのかもしれねーが
そんなオモチャは学生の課題ぐらいでしか通用しないよ
今はエンタープライズの話をしてるんだが
- 126 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:13:54.80 ID:8aNWh6BR.net]
- > 変えなくてもいいようなド単純なオモチャアプリケーションならHTMLは固定、で許されるのかもしれねーが
どんなものでも要件が変わらないならばHTMLは固定でよくなる
状態によって、HTMLの構造が変わることはない
- 127 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:14:19.93 ID:24n75C+P.net]
- >>123
だから何度目だ
エンタープライズでは機能が変わっていくんだよ
オモチャアプリケーションを前提に話すのいい加減やめたら？
- 128 名前：デフォルトの名無しさん [2020/09/13(日) 20:14:59.29 ID:e9EK7dt7.net]
- ガワ変えられない設計はあかんやろ
- 129 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:15:04.33 ID:8aNWh6BR.net]
- エンタープライズっていうのなら、コンポーネントの開発者と
デザイナーは担当者が別だ。
別々の人が並行して作業できなければ役に立たない
- 130 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:15:45.05 ID:8aNWh6BR.net]
- >>127
> エンタープライズでは機能が変わっていくんだよ
機能が変わるってことは要件が変わるってことだ
お前はまったく別の話をしている
状態によってHTMLの構造は変わらないという話をしてる
- 131 名前：デフォルトの名無しさん [2020/09/13(日) 20:18:12.95 ID:lu6eiMc4.net]
- >>116
一定時間ごとに画面のキャプチャを収集して画像の差分を追いかけて
サボってるやつ検出するやつ作ろうぜ
- 132 名前：デフォルトの名無しさん [2020/09/13(日) 20:18:49.06 ID:lu6eiMc4.net]
- いや、やっぱやめて絶対に作らないで
- 133 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:19:06.00 ID:24n75C+P.net]
- >>124
話を理解してくれ
連携を取れというがその連携が大変だと言ってるんだよ
HTMLを仕様として周知してしまったから
他の開発者やデザイナがそのHTMLを前提にCSSを開発することが合法になってしまった
各CSSの開発者に新しい仕様を説明してすべての箇所を間違いなく修正させる必要がある
それは大変な作業だ
一方でコンポーネントが可変部分をインターフェースとして提供していれば、内部HTMLの変化をわざわざ再周知する必要がなくなる
クライアントはもとのインターフェースに従って利用しているわけだからコンポーネント側が後方互換を維持すればいいだけ
連携なんぞ必要ない
- 134 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:20:33.74 ID:8aNWh6BR.net]
- > 連携を取れというがその連携が大変だと言ってるんだよ
> HTMLを仕様として周知してしまったから
> 他の開発者やデザイナがそのHTMLを前提にCSSを開発することが合法になってしまった
> 各CSSの開発者に新しい仕様を説明してすべての箇所を間違いなく修正させる必要がある
> それは大変な作業だ
ああ、他の開発者との連携して開発すること全く考えてないｗ
大変だから、一人でやる。小さなプロジェクトしか経験してない証拠だな
他の開発者との連携して開発するのはやることとして大前提なんだよ
- 135 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:21:55.75 ID:24n75C+P.net]
- >>130
は？要件が変わるって話をずっとしてんだが
- 136 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:22:53.84 ID:8aNWh6BR.net]
- >>135
要件が変わったなら、それを仕様にまとめろ
かってに作業すんな
- 137 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:28:05.21 ID:24n75C+P.net]
- >>134
オモチャ屋さんにはわからないかもしれんが
連携しなくてうまく行くようにできるなら、それが最も安全で効率的なのでそうする、ってのがシステム屋の常識なんだよ
で、システム屋はそれをどうやって実現するかっていうと
安定したインターフェーのみをクライアントに公開して、変化しやすい内部実装は隠して触らせない、って方法で実現してんの
お前はみたいに変化しやすいHTMLをクライアントのインターフェースとして提供してしまうと、しなくてもいい連絡が増えて、みんなが苦労することになる
- 138 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:31:19.42 ID:8aNWh6BR.net]
- >>137
今はHTML構造とデザインの話をしてる
HTML構造は仕様であり、デザインは別のものが担当する
大前提を理解しろ
HTMLはデザインの変更程度では変化しない
複雑なものを作るから、頻繁に変えなくちゃいけなくなるんだよ
複雑なものは単機能を持つ基本的なコンポーネントの集まりとして作れ
どんなにアプリが変わっても、単機能のシンプルな基本ライブラリが変わらないのと同じことだ
お前が今苦労してるのは、複雑なものを作るからだ
- 139 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:33:57.58 ID:24n75C+P.net]
- >>136
だからさぁ
仕様はまとまってるし変更があれば修正するよ
でもな仕様変わってもインターフェースまで変わるとは限らねえんだよ
コンポーネントにスタイルを閉じ込めとけばインターフェースは安定すんの
だからクライアントの変更なしにコンポーネントを更新できんの
お前はみたいにHTMLを仕様ですなどと言い張ると
ちょっとした要件変更のためにインターフェースとしたHTMLが変化して
それを大多数の開発者に周知しなきゃならなくなる
- 140 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:35:35.43 ID:8aNWh6BR.net]
- > コンポーネントにスタイルを閉じ込めとけばインターフェースは安定すんの
ほらまた、コンポーネントとスタイルを結合させて
メンテナンス性を下げてるｗ
そこはデザイナーが担当するの
HTML構造をインターフェースとして定めてるから安定してんの
- 141 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:36:53.97 ID:8aNWh6BR.net]
- > ちょっとした要件変更のためにインターフェースとしたHTMLが変化して
> それを大多数の開発者に周知しなきゃならなくなる
まさか口伝でもしてんのか？ｗ
- 142 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:40:17.52 ID:24n75C+P.net]
- >>138
変化は必然なんだよ
最初はインプットテキストだったものがシステムの成長に伴ってリストボックスやオートフィルに
さらに育って検索用のリッチな小窓を出すようになる
変化がないのはチュートリアルみたいなしょぼいシステムだけ
- 143 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:41:36.47 ID:24n75C+P.net]
- >>140
メンテナンス性を上げるためにコンポーネントを作ってる
HTMLに伴って変化しうるCSSを分離して遠ざければメンテナンスは難しくなる
- 144 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:42:51.29 ID:24n75C+P.net]
- >>141
なわけねーだろ
ドキュメントを更新して通知すんだよ
- 145 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:45:13.10 ID:sgNcOqc1.net]
- 構造とデザインだとXML+XSLもアリかとも思うけどほとんど見ないな
それとも知らないだけで使われてる？
- 146 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:45:47.84 ID:8aNWh6BR.net]
- >>144
じゃあ周知はそれで終りましたねｗ
- 147 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:46:29.91 ID:8aNWh6BR.net]
- >>145
> 構造とデザインだとXML+XSLもアリかとも思うけどほとんど見ないな
XSLはセンスが悪かった
今はHTMLとCSS
- 148 名前：デフォルトの名無しさん mailto:sage [2020/09/13(日) 20:47:55.64 ID:8aNWh6BR.net]
- >>142
だから仕様が変更になってデザインを変更する必要が出たら
デザインを変更するだけだろ、何いってんだお前ｗ
|
 |
