我正在开发一个单页网络应用程序,它最常用于移动设备。它的功能之一是地图模式,可以暂时接管整个浏览器窗口;距离比例尺和一些控件附在地图的四个角上。这是地图的一个小截图,所以你可以知道我在说什么:
地图被实现为一个<div>,position: fixed并且所有四个坐标为零;我还在地图可见时临时将 设置为<body>,overflow: hidden以处理底层应用程序显示从原点滚动的情况。这足以使地图在桌面浏览器上完全按照我想要的方式工作。移动浏览器还要求我提供一个类似的元视口标签,"width=device-width,user-scalable=no"以使窗口的可见区域与视口完全对应。
这所有的工作精美几年前,当我最初写这个程序,但沿线的iOS Safari浏览器停止接受任何涉及缩放元视口选项的地方-显然太多的网站被误用的标签,导致文本是unreadably小,但不可缩放。目前,如果您在此浏览器上启用地图,您可能会看到一个稍微放大的视图,这会切断右侧和底部的那些按钮 - 而您对此无能为力,因为所有触摸都被解释为地图的缩放/平移手势,而不是浏览器滚动。如果没有通过这些按钮访问的功能,地图就不会非常有用 - 如果没有右上角的按钮,您甚至无法关闭地图。唯一的出路是重新加载页面,这可能会导致未保存的数据丢失。
我肯定会添加history.pushState/的使用,onpopstate以便地图叠加层表现得像一个单独的页面。您可以使用浏览器的后退按钮退出地图模式 - 但这并不能解决由于缺少按钮而导致的其余功能损失。
我已经考虑使用.requestFullscreen()来实现地图覆盖,但并非所有地方都支持该应用程序本来可以使用。特别是,它显然在 iPhone 上根本不起作用,而在 iPad 上,您会看到一个状态栏和一个覆盖您内容的巨大“X”按钮——我的距离刻度可能不再可读了。无论如何,这在语义上并不是我真正想要的 - 我需要 full window,而不是全屏。
如何在现代浏览器上获得全窗口显示?我能找到的关于这个主题的所有信息都在谈论使用元视口标签,但正如我提到的那样不再有效。
我工作的公司生产的设备通过WiFi提供基于Web的设置和操作界面.该设备通常会在不知名的地方使用,因此无法假设现有WiFi网络的存在:设备的WiFi模块因此作为接入点运行,并通过HTTP提供花哨的HTML5 Web应用程序(唯一的选择)可以使用我在2013年选择的WiFi模块,这是最初实现的.
这起初效果很好,但随着网络的发展,它逐渐崩溃.特别是两个问题:
Web应用程序的一部分涉及映射,当然,能够在地图上显示"你在这里"标记非常有用 - 但Chrome已经拒绝通过HTTP支持HTML5 Geolocation API(甚至没有明确信任的选项)页面),看起来所有其他浏览器都会效仿.
Web应用程序非常大(并且WiFi模块非常慢),所以我使用HTML5应用程序缓存功能在初次使用应用程序后有效地加载即时页面.不幸的是,主流浏览器已经拒绝通过HTTP允许此功能,无论如何该功能已被弃用,并且它的后继者(Service Workers)明确地仅支持HTTPS.
由于原来的WiFi模块不再可用,我不得不重做此功能的硬件和软件.目前可用的模块具有更多的CPU功率和存储(并且成本只有十分之一),因此现在可以做很多事情,例如通过HTTPS提供Web应用程序.我普遍看到这样的设备的建议是获得一个正确的SSL证书,但我不知道这可能在我的情况下如何工作:
当设备实际使用时,通常不会有Internet连接可用,因此无法验证证书.
可以通过IP地址192.168.1.1或LLMNR/mDNS名称访问设备ui.local.不为任何类型的地址提供SSL证书.
我需要它永远工作- 没有机制来更新设备中的证书.即使是10年(许多自签名证书生成器提供的最长有效期)也不够; 我拒绝在设备中构建计划的过时.
也许可以通过向设备添加DNS服务器来进行某种工作,基本上将其作为强制门户,以便可以通过我可以实际购买SSL证书的普通URL来访问它.但是,我发现很多潜在的问题:
如果用户的计算设备设置了静态DNS服务器地址(8.8.8.8或其他),则它会失败,而不是从DHCP接受一个.
如果用户实际上与设备的WiFi连接同时具有Internet连接,则会失败.
如果DNSSEC有效,它将永久失败.
仍然存在证书过期问题.
尽管提出了相反的建议,但似乎只留下了自签名证书作为唯一可行的选择.对他们的一个常见反对意见是"你教导用户忽略有效的安全警告"; 我明白了你的观点,但我应该做些什么呢?
是否有一些我忽略的方法,这会让我的设备继续使用现代浏览器,以及它在2013年的做法?