- From: Xidorn Quan <quanxunzhen@gmail.com>
- Date: Thu, 5 Feb 2015 15:01:31 +1100
- To: Kang-Hao(Kenny)Lu(平寿) <kanghao.lkh@alibaba-inc.com>
- Cc: W3C HTML5 中文興趣小組 <public-html-ig-zh@w3.org>
- Message-ID: <CAMdq698TO1KkfNr6xOKuNpaaT1sQO+c6pgZPE763yTuvXZT=Ng@mail.gmail.com>
还有一个需要考虑的问题是如果有嵌套的滚动条要怎么放。 或许我觉得更好的方案不是给目标元素设置属性,而是给有滚动条的元素设置,比如说一个目标建议位置的边界。滚动的时候,终止位置由原来的视界范围改到这个边界范围内,然后默认时这个边界等于视界。 - Xidorn 2015-01-24 13:14 GMT+11:00 Kang-Hao(Kenny)Lu(平寿) < kanghao.lkh@alibaba-inc.com>: > (1/23/15, 18:39), Xidorn Quan wrote: > > 2015-01-23 18:39 GMT+11:00 Kang-Hao(Kenny)Lu(平寿) > > <kanghao.lkh@alibaba-inc.com <mailto:kanghao.lkh@alibaba-inc.com>>: > > 'under-fixed' 这种东西主要是解决 Spark 文档那种固定 banner 的情形吧,这 > > 种情形还是比代码导航的 GitHub 情形多一点,要我说的话其实这才最该是 #id > > 滚动本身的默认行为,只不过现在有这些 hack 了,浏览器应该有兼容性考量不太 > > 愿意改这种地方? > > > > 所以对 Web 开发来说,可以考虑把 :target { scroll-position: under-fixed; > > } 放在 CSS Reset 里,剩下的再在有特例的页面微调。 > > > > 至于预期以外的结果我觉得是 Web 开发自己负责了,一个页面里面最多有一个 > > fixed 或是 sticky 才是常态吧。 > > (1/23/15, 18:39), Xidorn Quan wrote: > > 我一点都不觉得是常态。倒不如说我怀疑只有一个 fixed 的是极少数。大多数页 > > 面或者没有 fixed,要有就有不止一个。你可以打开几个网页试试看。 > > 好吧,应该说我这个逻辑不好,我要说的是应该是 “有的 cross-reference > 的页面里,一个页面里面最多有一个 fixed 或是 sticky 是常态”,那这样 > :target { scroll-position: under-fixed; } 作为 CSS Reset 或是 user style > sheet 还是适合的。我这个叙述还有很多反例么?作为文档的 Web 页面(wiki、 > 项目文档、GitHub)确实是所有 Web 页面的少数这个我不反对。 > > 反正不管怎么样,我们又不是在讨论默认行为,使用这个 CSS 的人后果自负就好 > 了吧。 > > > 我估计现在不少广告都用 fixed 了,更重要的是很多其他交互元件比如侧栏导 > > 航、弹框之类的,也会用 fixed。顶栏导航如果 fixed 的话,它的菜单估计很多 > > 时候也是独立的 fixed 元素。 > > 菜单会需要相对定位吧,所以会是 absolute,至少 Spark 那个例子是这样。不过 > 就算菜单是 fixed,'under-fixed' 合理的行为也会不算没显示的 'display: > fixed' 吧,菜单一般是不显示的。 > > > 所以我不觉得 under-fixed 这种值能够有很大的实际意义。 > > 这样分析吧。Spark 文档[1] 应该可以用 'under-fixed'。一丝的的那个例子里确 > 实不能[2],因为右边有一个 'position: fixed' 的导航条,而可能需要 > under(#nav) 什么的,或是更智能的什么东西。我不知道那种出现的多,直觉上以 > 文档来说 Spark 那种多一点,不过我没有统计过。 > > 以解决案例的角度来说 under(#element) 应该要有,'under-fixed' 可以再讨论。 > > [1] > > http://spark.apache.org/docs/latest/graphx-programming-guide.html#graph-operators > > [2] http://thx.github.io/cube/#h4 > > > 以上 > > Kenny >
Received on Thursday, 5 February 2015 04:02:49 UTC