On Wed, 11 Jul 2018 17:14:21 +0100, Terry Coles wrote: > It's worse than that; I've found that every browser that I've tried > on every device that I have access to exhibits different behaviours > with this code:
I think this is just something that happens with captive portals. It's not unique to the one you've set up. Given enough time to detect the captive portal, Windows 7 pops up a balloon from the taskbar suggesting that "Additional log on information may be required", which opens a browser when clicked. Captive portals are a bit of a hack, and largely rely on the assumption that, if someone wants to use an internet connection, they will open a web browser and try to access a website on the internet. On desktop browsers, if you have a home page that has to be retrieved from the internet, then the experience is that the sign-in page will appear automatically when your browser tries to load your home page. For some years, it was easy to get away with assuming that most people who wanted to use a WiFi hotspot would open a browser and try to load a web page. Then the iPhone happened and suddenly (seemingly) everyone wanted to run native phone apps and POP/IMAP mail clients, which would (correctly) exhibit error conditions rather than displaying a captive portal sign-in page, because they were not web browsers. And so, workarounds had to be devised by which devices could detect captive portals and display the sign in page to users who might not open a web page as soon as they connected to the network. Almost inevitably, the solutions are not standardised. (And phone and tablet OSes have more highly developed solutions than desktop ones.) > Actually I had problems with the logo, the button text size and the > background image. Your button font size was specified in ems. So, it was specified as a proportion of the size that it would otherwise have defaulted to if you hadn't specified one. Since you hadn't specified any absolute sizes that were inherited by the button, the size was relative to the default font size for buttons, as chosen by the browser. This is fairly sensible, provided the browser has a sensible default font size. It has the advantage of respecting any custom default font size that the end user might have set, which is good for accessibility. However, this approach falls down if a browser has a stupid default (that wasn't set by the end user). Which leads me to wonder; could the overflow you're seeing have to do with the global font size settings (for menus, etc) on the Android device you are using? If this is set larger than default, then perhaps the portal sign-in browser respects that and renders everything larger, while other browsers ignore this setting. If the browser is displaying things larger because you have personal settings that enlarge things, then you just have to bear in mind that that is the enlarged version, not the default, and design it to appear enlarged in that browser but "normal" size in the others. If you are more concerned about whether the buttons fit on the screen than whether they respect the user's font size preference, it might make more sense to specify the font size in viewport width units (vw). That is a design decision more than a technical one. Personally I'd try a smaller em size first. (It sounds like that's what you've done.) -- Next meeting: Bournemouth, Tuesday, 2018-07-17 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
