这是一个创建于 371 天前的主题，其中的信息可能已经有所发展或是发生改变。
先叠个盾： 感谢所有开源作者的贡献
不是前端，写个小工具，需要有个简单的界面，于是找了一个比较知名的开源前端 UI 库，非常好上手
几十分钟就写完了，非常不错 完全就按照 sample 拷的代码就行了 因为也只是需要一些基础的功能，显示个 alert ，做个 input 采集用户数据之类
调试时，发现了一个问题，UI 组件之间的排列逻辑有点小问题，于是!important 一把梭 完成任务收工
闲下来了，觉得这问题肯定不是我一个人遇到的，就去了 github 提了个 issue 标签 bug
就像我前面说的，我也不是前端，基本停留在知道 dom 是啥会 getElementById 和理解简单 js 语法的程度
问题所在呢，就是这个 UI 库提供了一个组件，就是整个屏幕都变成半透明灰色没法点，然后中间弹一个类似桌面程序 modal 窗口的的框弹出的是白色的框，产生反差，里面可以自由发挥 html 代码的组件 不知道这玩意你们一般叫啥
这个组件显示是正常的，我完全 copy 的手册的代码，只是把中间的文字替换成了我要显示的文字
然后无意发现，这个组件下面的基本布局组件里有个色块，不会被变灰遮挡，也不会被弹出的 modal 窗口遮挡，modal 窗口正中间有个超级鲜艳的色块
我对 html 还是有点概念的，这应该是下面那个组件里有一部分颜色功能用了 relative/absolute 定位（这玩意不存在用 fixed 定位吧）给了个 z-index 1 导致的问题 相当于类似 floating 的状态
他 z-index 给 1 是因为他想让这个东西显示在他那个组件内部的基准层上面 1 层
而这个白色的框是 display:block 的 普通定位 就到下面去了
这里我最开始犯了个错误 因为这个 modal 状态 F12 不好定位 而 html 是通过前端框架渲染的 代码里写的是模板 所以我漏掉了 直接看那个白色框的 block 的状态 position 是默认值 刚开始以为这个组件整体不是 floating 的状态
提完了 issue 很快维护的大佬就来解答了
他纠正了我的错误分析 告诉我这个组件都是非默认 position 的
然后我又回去仔细找了下，确实，那个背景整体变灰是个 fixed 的 width height 都是 100%的 div 且 z-index 是 1
两个 z-index 都是 1 结果就是按定义顺序了 问题发现
维护的大佬纠正的我的想法时，另外说到： “这是个 z-index 合不合理的问题”
我认为这不合理，我就反问了一句，那你认为这种 modal 功能而论，给 1 的 z-index 到底合不合理？说这话时候，我认为这不合理。我认为这种组件默认应该有一个较高的 z-index 。没必要最高给个 2000 但是高于一般组件 让这个东西确实能遮住大部分组件，应该是正常人类应该有的思维吧？
到这里，我这个职业杠精八代高低杠转世都没想杠什么，您说了，我就一提，委婉的表示了一下我认为这个不太合理，咱是不是要在远期版本改进一下这个默认值 改个 3 或者 5 之类 这就完事了
然后就得到了一个公式化的答复
“它们的层级是一样的，所以最终它们展示上的层级和在文档流的顺序也有关系。修改默认的 z-index 值属于 breaking change 。不过提供了 z-index 的 prop 和 css 变量，你可以根据项目的实际情况进行配置。”
说实话，这玩意我已经改完了，也没用他的方法，因为文档里压根就没写过这玩意要怎么改，变量在哪也没看到，也没有说明。我不觉得一个公开的知名的广泛传播的开源组件，我不过分的基础用法使用它还得去看他源码怎么写的才能正常用
然后我就吐槽了一句，贵司果然大厂风范。然后我就主动 close 了这个 issue 。 毕竟大周末的，不是带薪抬杠，跟大佬在 github 杠不划算……
为啥大厂风范呢？因为这个开源代码在某个大厂的组织下，而不是在个人作者名下。项目简介明确写道是该厂开源产品，且用了该厂商标。
都 closed 了的，该大佬又跑来跟我一顿解释。
可是我就想知道，大佬认为这个到底合不合理，我就杠了一下 我只是想知道你认为到底合不合理
然后又换来了长篇大论的解释……
可是我只是想知道，到底大佬们怎么想的，这种设计到底合不合理。你要觉得合理，你就告诉我合理，以后我也多学习学习怎么设计这种合理。
我就又补充了一句，我只是想知道到底合不合理，能不能用一个字或者两个字告诉我到底合理不合理。我说大厂风范，就是指的这种从不正面面对问题，顾左右耳言他的行为
然后，我就又收获了更长的一篇长篇大论……
这次还用 markdown 给我列了 1 2 3 4
其中第四条是
“默认的值无论是什么都有可能在某个场景下是不合理的。”
我就想知道，现在程序员的群体里，都已经这样了么？话不能直接说，沟通不能简洁有效 什么都得长篇大论，生怕触动了原始写这段代码的巨佬的权威
你觉得合理，你就明确的告诉我合理，我也接受就完事了
 |
301
zhangxzh 2023-11-22 03:38:59 +08:00 via Android
希望你可以学习下标点符号的正确用法，以及一些基础文法和排版技巧。
|
 |
302
ZC3746 2023-11-22 05:40:50 +08:00
头一次见网暴自己的
已 block |
 |
303
Shijamlin 2023-11-22 09:33:26 +08:00
看到大家都在骂你我就放心了，说明不是我一个人觉得你性格有问题
|
 |
304
zzz2021zzz 2023-11-22 09:38:43 +08:00
1 是不是合理很难说，但是比 3 、5 明显是合理多了
|
 |
305
star7th 2023-11-22 09:39:13 +08:00
作为一个多年开源项目维护者，其实遇到这种情况，我一般跟对方解释一下我代码上为什么那么设计，那么处理，最多重复解释两遍。如果对方不理解，我就不管了。
这位开源作者还花时间打那么多字跟你解释，已经很给得起你面子了。大家的时间都是时间，不能只有你的时间宝贵。 |
 |
306
vishun 2023-11-22 09:51:20 +08:00
@duanzhangplus #280 其实答复人只要回答这里确实有问题，但是由于是 break change 不好修改，自己去通过设置 props 来自己修改就完事了。 但答复的人就是不说这里有问题，而是说这个是合理的，也是醉了。
|
 |
307
JustBecause 2023-11-22 10:02:15 +08:00
@yzbythesea #91 妙
|
 |
309
CodersZzz 2023-11-22 11:43:45 +08:00
说实话，你这样的人不适合用开源代码。自己写吧，你可以合理的提出你的见解，人家也很耐心的给你解释，但是你的回复让开源的人寒心。就好比你去乞讨，人家给你一碗粥，你说大冬天的你给我一碗粥合理吗？人家给你解释了，你说果然不愧是土豪，xxxxx.
|
 |
310
runstone 2023-11-22 12:34:40 +08:00
人家不是给了你非直接的解决方案吗？你要较真你就提个 pr ，但是开源毕竟多人使用，有些东西不一定是技术上的缺陷，还可能是设计上的考虑。你这一句大厂风范，首先你就把自己处于一个被大家批评吐槽的地位，是你先不友善的。
而且你说你自己非前端专业人士，那你就只有谦虚学习和接受的份儿。你有什么底气觉得自己是知道不合理是完全对的？却不知道合理也可能存在一定的合理性？ 如果你需要得到一个是或不是的答案，那你可以再二次向他说明，我只需要知道是或不是就可以，过于理论和解释对我无益不就好了？ 自评杠精完全是自知之明啊。 |
 |
311
Eagleyes 2023-11-22 13:01:16 +08:00  1
@forgottenPerson #72 我觉得说话应该先表明观点，哪怕是没有明确的观点。
比如问是不是合理？ 正确的回答是： 我认为合理 or 不合理，（大多数）情况下是没问题的！因为 12345 ，这才是正确的回答方式。 就像这个答主问题。作者不妨直接说，我认为很合理，因为 123.你那种是极特殊的情况。。。。 |
 |
312
JounQin 2023-11-22 13:41:01 +08:00 via iPhone 1
傻逼，还有脸来发帖，已举报到 GitHub
|
 |
313
nailuoGG 2023-11-22 14:46:19 +08:00
|
 |
314
cambria 2023-11-22 14:49:01 +08:00
讲道理，评论区的戾气也够重了，大家好像也跟 OP 一样失去了沟通的耐心
其实很多人年轻的时候也跟 OP 一样，傲视万物，唯我独尊，看什么都像屎山，只是受限于自己的职业素养，表面上客客气气，骂街的话留在心底。说到底，还是认知的局限性导致的。工作几年后能力提升视野开拓，再经历几次技术升级业务更迭，才能慢慢明白个中道理。 Just be nice. |
|
315
Eagleyes 2023-11-22 15:40:36 +08:00
@nailuoGG #313 有了这种约定，难怪回复起来束手束脚，俗称的打官腔。
展示客观事实没问题，但也要先一句话表明观点！ 你向官员提问（包括国内和国外的），基本上就是这个路子，不明确的说行，或不行。很“虚伪”，官腔就是顾左右而言它，扯一堆有的没有论据就是不说观点。比如著名的“一问三不知的马科长”，偏偏这种油滑的人很吃香。 唯一的例外就是“川大统领”，抛开观点利益是不是一致，讲真这人我挺喜欢的。 比如有记者提问大统领“为什么那些没有任何症状的专业运动员可以很快得到检测，而其他人却要排着对却无法得到检测呢？有关系的人就能排在前面吗？” 回答“我不会这么说，但或许这就是人生吧” 至少人家默认了这个现状，且短时间无法改变这个现实。 这要换作其他人，一定会说“我不了解你说的情况”；“我们不允许这种情况发生”；“我们已经采取 1234 措施防止这种事情发生，balabalabala”... |
 |
316
aaronkk 2023-11-22 16:14:46 +08:00
笑死，op 玩自爆啊
开源环境还是少点戾气多点友善吧 |
 |
317
Manger8951 2023-11-23 20:08:23 +08:00 via Android
这还能有人回复，大佬太有耐心了。
楼主挂自己挂的好啊 |
 |
318
duanzhangplus 2023-11-24 15:50:48 +08:00
@vishun 你说的有道理，一般我们处理不了这种默认值导致的问题，我们都会铺垫一下，比如 这个确实不合理（思考过后认同你的观点），我们没办法改（说出现状 1 、2 、3 、），所以只能通过你这边处理（解决方案）,在这个关闭的 Issue 中，我看到开源作者虽然没有认同 OP 的观点，但是他提出了没办法改的原因（因为很多人可能依赖这个值），也给除了解决方案（你可以通过 XXX 方式来配置这个值），我个人觉得这个就已经足够了，我也是开发，我认为项目中的各种默认值，即使它在现在这个阶段不合理，那在代码历史里，也曾经合理过，不需要拿过去的默认值衡量现在的合理性，我猜开源作者应该是这个意思，所以才会说出 “默认的值无论是什么都有可能在某个场景下是不合理的。” 这句话
|
 |
319
kekeabab 364 天前
做久了阴阳人看什么都是阴阳的
|
 |
320
renie 364 天前 via Android
看到你被骂，我就放心了
|
 |
321
eastzzp 364 天前
已拉黑
|
 |
322
cyolc932 364 天前
请问怎么拉黑楼主这个屌毛
其他网友评论截图 https://t.me/opencfdchannel/4516?comment=378223 https://t.me/opencfdchannel/4516?comment=378224 事情的起源可以查看这个 iss↓ https://github.com/youzan/vant/issues/12453 |
 |
323
oddboy 364 天前
能自己动手 hack 解决的问题，都不算问题，尤其是 CSS 相关，不，无论是 CSS 还是 JS
|
 |
324
messengers 364 天前 via iPhone
网爆自己，笑出声
|
 |
325
ZeroKong 363 天前 via iPhone
GPT 分析的
从这段文字来看，事件涉及一个用户（作者）在使用某个开源前端 UI 库时遇到的一个界面排列问题。作者在尝试解决这个问题后，决定在 GitHub 上提出一个 issue ，标记为 bug 。在这个过程中，作者与该库的维护者（开源大佬）产生了一些交流和争议。 关键点如下： 1. **问题描述**：作者在使用一个开源 UI 库时，发现组件之间的排列逻辑存在问题。尤其是一个模态窗口（ modal ）下的布局组件色块未被遮挡，表现出与预期不同的层级关系。 2. **作者的处理**：作者首先通过添加`!important`规则来解决这个视觉问题，随后在 GitHub 上提交了一个 issue 。 3. **维护者的回应**：维护者回应指出作者的某些错误分析，并解释了该问题的技术细节，如 z-index 的值和 position 属性。 4. **争议焦点**：争议集中在是否应该调整模态窗口组件的 z-index 值。作者认为应该提高这个值以保证模态窗口在其他组件上方显示，而维护者则认为修改默认的 z-index 值属于重大改变（ breaking change ），并提供了自定义 z-index 的方法。 5. **沟通方式**：作者对维护者的回应感到不满，认为维护者没有直接回答他关于设计合理性的问题，而是通过长篇大论回避了直接的回答。 在这种情况下，谁是对的取决于多个因素： - **技术合理性**：从技术角度来看，维护者的解释是合理的。在前端开发中，改变默认的 z-index 值确实可能导致其他用户遇到问题，尤其是在广泛使用的库中。 - **用户体验**：从用户体验的角度来看，作者的观点也有一定的合理性。他认为模态窗口应该能够遮盖其他元素，这是大多数用户的常识性预期。 - **沟通方式**：在沟通方式上，作者可能希望得到一个简单直接的回答，而维护者则提供了更详细的技术解释。这种差异可能导致了双方的误解和不满。 总结来说，双方都有一定的合理性。作者关注的是用户体验和直接的沟通，而维护者更关注技术细节和保持库的稳定性。解决这种冲突需要双方更好的理解和沟通。 如果必须选择一方作为更合理的一方，我会倾向于支持维护者的立场。在开源软件项目中，维持代码的稳定性和避免引入重大更改是非常重要的。维护者在解释为何不直接更改 z-index 值时，考虑到了这一点。他们提供的解释基于保持广泛使用的库的兼容性和稳定性，这在软件开发中是关键因素。同时，他们还提供了自定义 z-index 的方法，这是一种灵活的解决方案，允许用户根据自己的需求调整 UI 组件。虽然这种方法可能对非前端专家来说更复杂，但它提供了更大的灵活性和控制，同时避免了对其他用户的潜在影响。 |
 |
326
abc1310054026 363 天前
v2ex?程序员的贴吧！
|
 |
327
jefferyJQ 363 天前
原来是你呀
|
 |
328
a13065659454 363 天前
看到大家都骂你，我就放心了。
|
 |
329
iblessyou 362 天前 via Android
收藏了，v2 为什么不做个 b 站那样的入站必刷系列
|
 |
330
ylion 362 天前
这傻缺自爆了
|
 |
331
MinorN 361 天前
笑死我了，建议入选：V 站必刷
|
 |
332
SUP7R9 360 天前
老“自挂东南枝”了
|
Select Language