Use scale instead of pixels, fixes #38

[rubenstolk]

:eyes:

• [x] Zoom: 100% after and before this PR:
• [x] Zoom: 90% after and before this PR:

[rubenstolk]

Is this something scheduled?

[rubenstolk]

It looks like this was already fixed in https://github.com/PolymerElements/paper-radio-button/pull/91. That mostly fixes it although the result is not perfect, still a bit off in certain zoom levels.

I wouldn't mind taking a look at it again, but before I do I need to know if there is a chance of getting a merged, so someone please let me know!

@hotforfeature @bicknellr @notwaldorf

FYI these are screenshots from 90% and 110% in Chrome with the current master branch, definitely better than before but I would still vote for what I suggested with this PR:

[hotforfeature]

I don't see why not, it may even be easier now. I haven't tried it myself, but if you set #onRadio width and height to 100%, then the checked state to scale(0.5) using the current master branch, I think that'd accomplish what you were going for.

[rubenstolk]

@hotforfeature @bicknellr I've updated this PR:

• BEFORE 90%
• AFTER 90%
• BEFORE 110%
• AFTER 110%

[bicknellr]

It's better but I'm still seeing a lot of rendering inconsistency; here's what it looks like 90%: To really squash this bug, I think we need to switch to SVG from divs. All of this seems to result from each browser's individual behavior for aligning boxes with device pixels to prevent border anti-aliasing.

[rubenstolk]

@bicknellr that's true but at least now we have the best situation that can be achieved with HTML/CSS. I agree that svg is better but with this PR in I wouldn't consider it as a bug anymore as it just behaves like anything else on zoom levels. We would be as good as something like https://material.angularjs.org/latest/demo/radioButton now.

[bicknellr]

I think that's a reasonable argument. I filed #96 about converting to SVG, but, like you said, this is probably as good as it gets without leaving HTML/CSS.

[bicknellr]

LGTM, thanks!