Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"inputbox.html" uses CSS zoom incorrectly #1

Open
DanRathbun opened this issue Jul 31, 2018 · 5 comments
Open

"inputbox.html" uses CSS zoom incorrectly #1

DanRathbun opened this issue Jul 31, 2018 · 5 comments
Labels
bug

Comments

@DanRathbun
Copy link
Contributor

DanRathbun commented Jul 31, 2018 •
edited
Loading

"inputbox.html" uses CSS zoom incorrectly

In the style element of the file ...

    /* Applying a global zoom to scale down the default size of Bootstrap. */
    html { zoom: 0.8; }

zoom does not work outside an @viewport at-rule. It is ignored according to the docs.

Ref: https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport

EDIT: (2018-08-31)

After further tests, neither zoom nor -ms-zoom works, outside of a @viewport rule, in UI::WebDialog on MS Windows which runs in a MSIE WebBrowser Control.

It DOES work in Chromium dialogs, outside of a @viewport rule, which is used by the UI::HtmlDialog class on SU2017 or higher. (This example is only written to use the new UI::HtmlDialog class, so the lack of zoom working in a UI::WebDialog may not be considered a bug for this example.)

Also tested the following in a MSIE UI::WebDialog and it also does NOT work.

@viewport {
  -ms-min-width: auto;
  -ms-max-width: none;
  -ms-zoom: 0.75;
  -ms-user-zoom: fixed;
}
@thomthom
Copy link
Member

hm.. didn't realize it wasn't standard. (https://developer.mozilla.org/en-US/docs/Web/CSS/zoom)

I haven't seen a single browser ignore it. Been around for ages. Setting zoom: 1.0 was one of the old tricks to control old IE's hasLayout behaviour.

But being non-standard, it's better to avoid it. Real fix would be to regenerate bootstrap CSS with custom sizes.

@thomthom thomthom added the bug label Jul 31, 2018
@DanRathbun
Copy link
Contributor Author

It is in SU2016 and IE WebBrowser control that I noticed it has no effect at all.

What I ended up doing was just base everything upon the font setting at the top of of tree (html) and then use rem which plays off of that (when I want it to.)

Since 1em == 16px, and that is too large I set the size to 0.75 for the content.

Oh and I ended up ditching the bootstrap CSS entirely. It was just way too large to even consider understanding for simple dialogs.

And I also prefer the XP style buttons rather than flat blue buttons. I just copied what I wanted from the bootstrap rules (borders and hovers styles mostly) and made our own separate CSS files. I just don't have time to learn bootstrap. Take the best, forget the rest. ; ) I also got rid of some of the weird wrapping label & control pairs. Just made issues.

@DanRathbun
Copy link
Contributor Author

Thomas said: I haven't seen a single browser ignore it. Been around for ages.

DAN said: It is in SU2016 and IE WebBrowser control that I noticed it has no effect at all.

Okay, I have finally gotten a new machine that can run SU2017+ with a higher DPI display of ~141ppi, and have done some more tests, and compared my dialogs running in UI::WebDialog (SU2016) and UI::HtmlDialog (SU2017+).

The zoom attribute WILL work outside an @viewport rule in Chromium.

Dan said: Since 1em == 16px, and that is too large I set the size to 0.75 for the content.

Turns out I do not need the zoom: 0.75 on a 141ppi screen at 100% display scaling. (Ie, a 15" FHD notebook screen.) The buttons and text in the web dialog are the perfect size (compared to the MS Calculator buttons, etc.,) and holds true for both the new UI::HtmlDialog class and the old UI::WebDialog (on SU2016.)

I was designing my dialog layouts on a 25" FHD monitor which I didn't realize was only FHD and so is only a 88ppi pitch. This is why the dialogs looked so big. They and their content are 15% larger on the large display, then they are on the internal 100ppi display of my old notebook.

Anyway, using font-size: 1em; (=16px) for the html element, and then using rem for other subordinate elements seems to be fine for FHD on a 15" display at 100% scaling. If users want larger they'll set a higher display scaling.

Thomas said: Setting zoom: 1.0 was one of the old tricks to control old IE's hasLayout behaviour.

From the Mozilla docs, it says that MSIE 10+ must use -ms-zoom.
But it also has no effect in a SketchUp UI::WebDialog outside an @viewport rule.

My tests are with the following start to the HTML files:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=11"/>
    <meta http-equiv="MSThemeCompatible" content="yes"/>

The next problem I have is window size. As the users increase display scaling the default sizes of the web dialog window(s) are too small. UI.scale_factor will help me for SU2017+ but I'll need to find a Fiddle solution for SU2016.

@thomthom
Copy link
Member

thomthom commented Aug 31, 2018 •
edited
Loading

What I did in SUbD to deal with the webdialog sizes I allowed the users to set a scaling factor manually if they where using an older SU version.

Here's my DPI utility module that I used:

Sketchup::require "TT_SUbD/settings"

module TT::Plugins::SUbD
  module Dpi

    SKETCHUP_VERSION = Sketchup.version.to_i

    def self.scaling_factor
      if UI.respond_to?(:scale_factor)
        UI.scale_factor
      else
        Settings.read('MonitorScale', 1.0)
      end
    end

    def self.scale(value)
      value * self.scaling_factor
    end

    def self.scale_line_width(width)
      if SKETCHUP_VERSION > 16
        # SketchUp 17 scales line weights automatically.
        width
      else
        width * self.scaling_factor
      end
    end

    def self.scale_webdialog(logical_pixels)
      if Sketchup.version.to_i > 16
        # SketchUp 2017 scales up the position and size automatically for both
        # UI::WebDialog and UI::HtmlDialog.
        logical_pixels
      else
        logical_pixels * self.scaling_factor
      end
    end

    def self.get_transform(screen_point)
      scale = self.scaling_factor
      tr_scale = Geom::Transformation.scaling(scale, scale, scale)
      tr_translate = Geom::Transformation.new(screen_point)
      tr_translate * tr_scale
    end

  end # class
end # module

@DanRathbun
Copy link
Contributor Author

DanRathbun commented Sep 1, 2018 •
edited
Loading

FYI (and note to self): DPI-related APIs and registry settings
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn528846(v=win.10)#system

@DanRathbun DanRathbun mentioned this issue Sep 27, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thomthom @DanRathbun