V2EX › autoxbc 的所有回复 › 第 146 页 / 共 147 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 138 139 140 141 142 143 144 145 146 147

❮

❯

2017-07-08 14:02:04 +08:00

回复了 JonyOang 创建的主题 › 全球工单系统 › 网易邮箱问题，还是我的问题？

建议开两步验证

2017-07-08 13:39:57 +08:00

回复了 tlday 创建的主题 › 程序员 › 现在 css 不是前端必备技能了吗？

CSS 编程被低估了。那些用机器生成的 CSS 代码，又臭又长，各种 bug，违反设计准则。

2017-07-06 15:35:54 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@DOLLOR

我的观点是"代码即 bug"。针对 github 上的众多开源项目的研究显示，无论大小项目，每千行代码 bug 率是接近的。如果说有什么差别的话，前端代码会更糟一些，有更少的测试流程，更低(或者没有)的崩溃日志收集。

当我们抱怨是用户的锅，或者第三方代码的锅，是否想过，这正是平稳退化所说的非预期错误。

前端的高速发展，是检视旧设计的好机会，那些超出狭义设计方法的通用工程思想，可以留存下来。

2017-07-06 05:58:16 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@DOLLOR #99
我真的没有禁用 js，我是说不相信 8 万行这个量级的代码，在多样化的解释器，多样化的用户环境中(注意主流浏览器都支持扩展，一些扩展可用的 api 足够强大，扩展代码质量良莠不齐)，可以实现零错误。这种非预期状况不是特例，时刻都在发生。

「知乎为什么与很多 chrome 插件不兼容？」
https://www.zhihu.com/question/21243152

顺带，我仔细看了 WebAssembly 的介绍，这个技术不会颠覆 Web 的基石 html css js，最多把 js 扩展为 jvm。

@AntiGameZ #100
这确实不算 bug，我也只当是个例子，当作课后的练习题。

2017-07-05 15:27:43 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@DOLLOR #97
「虽然我觉得知乎的体验也是超烂的，但是他们有底气认为禁用 JS 或者使用原始社会的浏览器的人不是目标客户、不能创造价值，他们当然可以拒绝过度“退化”。」

那请问什么是"过度退化"?

Web 的基石是 html css js，强调内容、样式、行为分离，现在前端已经发展到只要行为了吗？还把要看内容的需求叫做"过度退化"，我真看不懂了。

2017-07-05 03:07:21 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@chengluyu #93
「 @autoxbc 您单纯讨论设计当然没错，可更多的时候设计要按照运营的思路来，毕竟知乎是商业公司，还要忙着用 Live 等产品赚钱。现有的纯前端渲染，恰好可以满足运营思路多变。」

可能您研究技术思想升华，开始从更高层面考虑，这也是一个角度。

我个人相信看不见的手，尽量避免充盈同理心，避免从大局考虑，专以自己的私心为出发点，这一刻我只是用户，一个看了白板的用户。

2017-07-04 20:43:20 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@libook #69
您的方法论是对的。不过就这个例子来说，成本并不高，相信大家是看得出来的。

@tairan2006 #75 , @leewayhsu #76
这里说的是平稳退化。兼容是产品说了算，退化的话前端还有发言权吧，至少我所见的前端都还在研究 UX，并不是纯码农。

@AntiGameZ #78 , @silentsora #82
我怕知乎的开发说我是用 IE6 的乡民，当然 v2 也有人这么说，还是有点意外。退化和兼容 IE6 是没关系的，反应的是开发者是否务实，是否承认设计可能会以非预期的形式展现，并给出合理安排。

@coolzjy #80
服务器端异常，少见而可控；客户端异常，则难以预计。顺便说一下，我说的是格式化展开的行数。

@meepo3927 #89
您脑补过头了，我的话怎么都看不出有批评合并压缩的意思。

@chengluyu #90
您对"平稳退化，渐进增强"这几个字的理解完全不对，这是讲狭义设计思想的，不是广义运营思想。知乎的需求我也不关心，我说的是他们没有满足用户的需求。

2017-07-04 02:28:35 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@libook
@tlday

我觉得成本驱动是对的，那么知乎这个级别的站，写一个退化规则，要求专栏可以看见文章，问答可以看见问题和答案，需要多少人月？

2017-07-03 18:24:37 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@just1 #39 这里讨论的不是兼容，是退化，退化是允许功能缺失的
@zythum #35 我去看了 google search，gmail，退化做的相当好

2017-07-03 18:00:11 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@XueSeason
@zander1024
@jsq2627
@wxsm
@libook

我提纯前端渲染，大家就揪着纯前端渲染
我提禁用 js，大家就揪着禁用 js
这是我没想到的

我提平稳退化，大家打个哈哈，提开发成本云云就算过去了
这个我预想到了

从理念上讲，完全没有退化就是错的，这和用户是否禁用 js 没关系。进一步说，我们不仅要考虑退化问题，还有可访问性，无障碍浏览，这才是前端应该做的，不然和切图仔有什么分别。

从技术上讲，只要把几百个字的正文复制一份放在标签里，不要说 IE6 IE5，就是 lynx 都没问题，这很难么？需要多少开发成本？浪费流量？那 2MB 的脚本是怎么回事？

提技术栈的，桌上没筷子就上手抓么？ React 不做退化，所以选择 React 就没办法做退化？退化的核心是内容权重分析，是 UX 体验调整，前端技术栈不能思考，前端程序员可以。

2017-07-03 15:34:11 +08:00

回复了 autoxbc 创建的主题 › 前端开发 › 知乎这种纯前端渲染真的没问题么？

@hronro 不要把平稳退化狭义化

@GordianZ 我试了，请您也试一次

@NCR 脚本有 2MB，展开 8 万行，一个纯展示弱交互网站，搞成这样

@chengluyu 脚本开头就崩的话，后面组件化也没用

@tabris17 SEO 不是关键，google 已经收录了，但是对用户不友好

@ibm360 纯前端没问题，没有退化就有问题

2017-06-29 16:37:05 +08:00

回复了 didikee 创建的主题 › 程序员 › 长时间对着屏幕眼睛干涩犯疲劳怎么整?

@carlist #27 感谢提供这些评测。我看到了基于原理的分析和基于仪器的观测，不过没有基于双盲的人眼实验。我也没有具体的数据，只是主观觉得低频 PWM 闪烁敏感人群的比例并没有那么高，大多数人可能根本分辨不出区别。

看了下 29# 的说明，Volumouse 或者 Windows 本身的亮度调节应该是二次 gamma 映射，和一次的 2.2 不是一个概念。二次映射是把 gamma 曲线重新整体压缩，和一次 gamma 调节导致的还原失真不一样。流程是这样的：

1. 拍摄自然物体，gamma encoding，参数 1/2.2，曲线上凸，损失亮部灰阶(不敏感)，补偿暗部灰阶(敏感)
2. 显示系统还原，gamma decoding，参数 2.2，曲线下凹，抵消第一步操作，得到真实色彩
3. 二次 gamma 映射，gamma 曲线整体线性压缩，等价于调节显示器亮度。

2017-06-29 02:26:29 +08:00

回复了 didikee 创建的主题 › 程序员 › 长时间对着屏幕眼睛干涩犯疲劳怎么整?

@carlist 我主力显示器是 11 年之前的型号，非 CCFL，应该是低频 PWM，用了 5 年不觉得有问题，和今年新换的体验一样。我希望有人做 AB 测试，看看是不是玄学。

至于调节 gamma 导致的色准问题，我这么理解：显示器只在一个特定的参数组合下是颜色准确的，其他一律不准。在那个特定参数下，亮度一定是过高的，权衡下体验放在首位，不用纠结色准。

调节 gamma 导致的色偏是整体变暗，和调节 RGB 分量导致的色偏完全不同。同时，调节系统 gamma 和调节驱动改变亮度和调节显示器硬件亮度值，原则上是等价的。

2017-06-29 01:33:35 +08:00

回复了 didikee 创建的主题 › 程序员 › 长时间对着屏幕眼睛干涩犯疲劳怎么整?

放个地图炮，抗蓝光和 LED 调光什么的都是玄学，常年每天十几个小时的经验来看，关键不是这个

眼睛不舒服两个原因：1. 字太小； 2. 太亮

在 27 寸 1920*1080 ( dpi 计算值 81.59 )的情况下，我的网页正文默认字体是 20px，一些前端写的默认 12px 字体不知道是给谁看的；代码默认字体小四，换算为 18px。看的清就不需要用力看，自然不累眼睛。

液晶显示器普遍亮度超高，为了拉高对比度参数和色域参数，默认亮度能把人闪瞎。我近期买的 2 台显示器，最低亮度仍然太亮，几个小时下来就特别难受。这时已经无法进一步下调亮度，需要调节系统 gamma 曲线。技术细节就不说了，推荐个软件 Volumouse，设定成窗口边缘滑动滚轮下调亮度(实际调的是 gamma 值)，效果立竿见影。

不推荐用 flux 之类的改变色温，会导致整体严重偏色，偏色导致的不真实感也是视疲劳的原因之一。刺激人眼的是亮度，不是蓝光。蓝光影响的是延迟睡眠，和眼睛难受没关系，延迟睡眠是另一个问题，我觉得也被夸大了。

2017-06-27 21:32:07 +08:00

回复了 tbag781623489 创建的主题 › JavaScript › 请教一个 video 的多个 onerror 的问题

@tbag781623489 不用日本 ip 不能获取，dmm 网页限制 ip，只有最终文件下载不限制。如果是需要用番号直接生成下载链接，那这种方法不行。

看了下一楼的代码，onerror 只能定义一次，多次定义离 error 事件最近的有效。javascript 的异步流程决定了，一楼的实际流程是

src = 123
self.onerror = {...} 此时 http 状态码还没有返回，error 事件不会触发
video.onerror = {...} 回调被覆盖了
... 过了一段时间
src = 123 的 error 触发，执行 src = 789

所以 src = 456 和 log 不会执行

2017-06-27 06:20:13 +08:00

回复了 tbag781623489 创建的主题 › JavaScript › 请教一个 video 的多个 onerror 的问题

@tbag781623489 我在 dmm 的页面里看到了这样的代码，不知道题主为什么要用字符串拼接 url，为什么要用 onerror 去试文件是否存在。简单的在 iframe 里读取 json，推送到父窗口生成 video 标签就可以了。
https://gist.github.com/anonymous/ce1c3bfe8e8b86a0fd849844953c361c

2017-06-26 22:45:18 +08:00

回复了 gtalk 创建的主题 › 全球工单系统 › ofo 和 mobike 的安卓客户端会相互唤醒

统一推送搞出来也没用，该唤醒还是唤醒，灰色产业利益链决定的

2017-06-23 22:35:46 +08:00

回复了 zjsxwc 创建的主题 › 程序员 › 谁能用代码解释下以太坊的去中心化的原理吗？

中心这个概念是有歧义的，去中心的说法也比较模糊。不如说决议的产生比较直接，中心化的结构，决议由法定或者掌握暴力的组织下发，其他人只能无条件接受；去中心化的结构，决议的达成由投票决定，选票就是计算力。

比如有人振臂一呼，说把币值最大的钱包分了，人人有份，只要投票通过，就可以分了。据说几个核心开发者的币被黑客偷了，他们另起一个分支，偷的都不算数重新开始，等于把所谓黑客的币分了。

至于投票的过程，就是你把自己的算力接在哪个链上就算投票了，产生的决议甚至无所谓发布，新链旧链同时存在，大家各玩各的。玩的好叫自然演化，生生不息。玩不好就是暴民统治，再慢慢振荡回归。

2017-06-19 19:54:45 +08:00

回复了 lancn 创建的主题 › 程序员 › JS 根据来路域名跳转不同网址问题

@Chaidu 您的方法不是最佳实践，我分析一下
1. 在 ['123.com','www.123.com'] , '111.com' 这个跳转规则中，三个域名是数据，跳转是操作。在多条规则中，数据和操作应该分离，就是一楼那种写法。#39 楼的代码也做了分离，就是这个意思。
2. 数据分离后，操作会被抽象，您的三种方案都没做抽象，存在冗余代码。
3. referring.indexOf('123.com') < 13 这里 13 是 Magic Number，会增加额外的维护成本。抽象度足够的话，并不需要魔数。同时，网站域名变更，魔数就是潜在的 bug，甚至是漏洞。
4. 对 url 字符串用 indexOf 或者 match(/new RegExp/) 匹配域名，并不总可以正确匹配，如果这是安全校验的一环，会造成跨域漏洞。给你个例子看看
http://zhchbin.github.io/2016/09/10/A-Valuable-XSS/
5. 前端处理 url 字符串的安全做法是一楼那样，给出一篇说明，其中客户端 URL 解析部分
http://web.jobbole.com/82459/
6. 如果略微放松浏览器兼容性的话，我们还会构造 URL 对象，这也是安全的。
new URL('http://www.test.com:8080/find?arg=str').hostname
// "www.test.com"
看这个教程，接口十分丰富，比手写好 5 倍。
https://developer.mozilla.org/zh-CN/docs/Web/API/URL
7. v2 是高水准程序员社区，我可能是这里最菜的一部分，但我愿意虚心向 v 友学习，希望您也可以。

1 ... 138 139 140 141 142 143 144 145 146 147

❮

❯