我,老鼠,给我寄台 Kindle

我以前写了一个网页版的时钟,在一个陈年的 iPad 上运行,就是想废物利用吧,但其实也没有多大用。

今天老妈说自己的小闹钟坏了,我原本是想给她买个新的,但我这里淘宝快递不方便,京东上的价格总让我觉得偏贵了。于是我就把 iPad 给放了过去,文字够大,她挺喜欢的。忽然觉得我这些无聊的小玩意儿偶尔也能有点用,我也挺开心。

恰巧最近有对这个时钟进行改进的想法,不过想着更好的兼容一下电子墨水屏设备,看了一下,现在市面上有的一些针对电子墨水屏的网页时钟……Emm,就是觉得还不够完美吧。

但这里就遇到一个小问题,我的 Kindle 坏了,真·用来垫桌脚了。而这种网页测试起来必须要有设备进行实际的测试,毕竟设备自带的网页浏览器应该算是精简版,所以要根据他实际能够支持的技术进行调整,以及网页性能等,也要借助设备进行实际的测试。

毕竟家境贫寒,不可能为了写一个网页就买一个设备。所以你们谁有吃灰的,能不能送我一台?最好不是咪咕版/青春版,因为这个版本就没有浏览器(好像是),当然他们也可以通过一些方法去变通的浏览网页,但就真的不方便进行测试,以及观察无法隐藏工具和地址栏的情况下,具体的展示情况。

大概就是这么个意思,我就是问问,有一搭没一搭的,万一呢……

我有一台很老的,要不要寄给你,好像 kindle 4

太老的版本,我不确定是否具有参考价值。我心目中比较奢望 pw2 或者 3

过些天我盲写一个页面,你帮我测试下吧先

我,芸枫,帮你找到了
http://jenevoldsen.com/literature-clock

3 个赞

我有台吃灰的pw1(不过我们这里快递由于疫情停运了

矮油这个不错啊,可惜每天有1440分钟,中间难免会有任何文学作品都没写过的冷门分钟

不着急,我先问着,寄东西的事情得等等看,毕竟我这里的快递也半瘫痪

挺有想法的!

我侧重的是另外的方向,所以不冲突

那时候就自己瞎写一段把冷门的分钟补上 :upside_down_face:

我有一个14年买的 paper white
之前有段时间用来看aida 64的监控页面

毕竟设备自带的网页浏览器应该算是精简版

Kindle 的浏览器没有想象中那么不堪。我的 Kindle 10 在 HTML 5 测试 里也能拿到 152 分。而这个成绩甚至比 IE 9 还要高,后者只有 113 分

所以要根据他实际能够支持的技术进行调整,以及网页性能等,也要借助设备进行实际的测试

如果你实在不放心,你也可以在Amazon 官网下载到 Kindle 的技术指南。其中的附录 C:HTML and CSS Tags Supported in Kindle Format 8部分详细列出了 Kindle 在阅读器中所支持的 HTML 和 CSS 标签——这一标准应该也适用于内置浏览器。

最好不是咪咕版/青春版,因为这个版本就没有浏览器(好像是)

所有版本 Kindle 均内置浏览器。(非常非常久远的古董版本除外)

真的不方便进行测试,以及观察无法隐藏工具和地址栏的情况下,具体的展示情况。

普通 Kindle 的分辨率大多为 600 x 800,网页可见大小约为 600 x 699。根据此比例制作网页即可。


最后附上一个 Kindle 青春版(或称 Kindle 10)的 UA :Mozilla/5.0 (X11; U; Linux armv7l; zh-cn) AppleWebKit/534.26+ (KHTML, like Gecko) Version/5.0 Safari/534.26+ Kindle/3.0+
你可以用此 UA 访问微信读书,看看微信是怎么适配墨水屏设备的。

2 个赞

这就让人觉得十分给力!

那么 JS 哩?

那么 JS 哩?

兼容性与前几年的主流浏览器基本一致。
有极少数 Javascript 新特性不被支持,如Media Function bind JSON API Geolocation API等,不过这些在 Kindle 上本来就不太常用。
相比之下, CSS 和 HTML 才是需要注意的部分。但是只要注意少用某些「奇巧淫技」,Kindle 是可以正确解释大部分网页的。

...我的想法们

有认真的在思考 @w568w 所讲的这些问题。

以及最近在写代码时,由于自己的强迫症导致了一些问题。

总结下来,自己太强迫症了,恨不能让自己的代码能够兼容 IE6,这一点值得反思。但这样的强迫症也是有一定原因的。如上面所说,现在的时钟用的是一个 iPad,我也搞不清楚是一代还是二代,反正系统已经没有办法再升级了,可以装的应用也变得越来越少。在书写它上面使用的时钟时,就遇到了许多的问题。比如我想让时钟全屏显示,但是它并不支持全屏的 API(好消息是它支持将网页钉在桌面上,然后以全屏形式打开),以及一些类似的技术细节。

想在这些吃灰的设备上去搞一些有趣的玩意儿,会遇到的细节问题常常要比自己想象的多,在真机上进行调试还是有必要的。

不过我也确实应该认真的考虑一下,日常的代码是不是不要考虑太高的兼容性问题,最新的主流浏览器可以正常运行就够了。

另一个可能的视角是,写的时候就直接用最新标准写,再用各种 Javascript Compiler 适配旧环境,然后根据 UA 分发对应的文件。大部分情况下旧设备的用户基数并不大,就算加了各种 polyfill,实际上对绝大部分用户都不会有太大的影响。

1 个赞

因为目标就是旧设备,问题变得不太一样了就。有些新标准的语法并不能很好的转换到旧标准,还有性能等问题需要考虑。

1 个赞