How can I remove the three labelled gaps in the image below?
This code is available at http://jsfiddle.net/69zj6smo/ - resize the render area to see that some lines are typically present.
What confuses me is that I think I've always created fluid/percentage layouts like this, and I don't remember this visual artifact (layout error, or possibly browser defect) in any browser previously.
Regardless of whether fractional pixels exist (such as in a Zoom or High-DPI mode) or not (see: Is there such a thing as fractional pixel?), it doesn't explain this issue. In my mind, there is no reason for this otherwise excellent browser (Google Chrome 37.0.2062.124 m, also 38.0.2125.104 m) to answer this existential question differently for different elements on a single page.
Most suspiciously, the difficult-to-see gap "A" occurs between TD elements, when the background color is actually applied to the TR element. Regardless of pixel widths I wouldn't expect the TR to appear broken.
However, the gap "B" between a width: 100% table and its parent, and "C" between float: left siblings also strike me as odd. However a parent chooses to calculate width, I'd expect a width: 100% child to use the same method, and however a sibling chooses to calculate position, I'd expect the following float to be precisely adjacent.
In each of these cases, looking at the computed dimensions in the "F12 Developer Tools Inspector", I can see that the visual gaps represent actual values, e.g. a parent DIV width of 282.375, and a child TABLE width of 282.0 pixels.
Have these problems always been present and I just never noticed them? Any recommendations on how to address this and yet retain some fluidity on my page? I do not see this artifact in IE, is this arguably a defect?
Update: I've discovered this may be related to my 3200px-wide laptop display, which enables Chrome's High DPI mode, and reveals certain defects. However, disabling Chrome's High DPI mode (either by launching with “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” /high-dpi-support=1 /force-device-scale-factor=1, or by setting HKEY_CURRENT_USER\Software\Google\Chrome\Profile\high-dpi-support to 0, makes everything appropriately tiny but does not resolve this apparent pixel-rounding issue.
Update 2: Filed a Chrome defect report. https://code.google.com/p/chromium/issues/detail?id=424288
This appears to be the result of two or more Chrome defects.
The most noticable of the gaps ("B" in the image), seems to be caused by a defect reported over a year ago here: https://code.google.com/p/chromium/issues/detail?id=241198 (duplicate defect reported here: https://code.google.com/p/chromium/issues/detail?id=306878). Please vote these defects up if this answers your question.
The more subtle issues ("A" and "C" in the image) only appear in Chrome's High DPI mode. It is probably related to this defect: https://code.google.com/p/chromium/issues/detail?id=403955. However, I didn't dig deep enough to ensure I understood that one. Regardless, I'm uncertain why in issue "A" specifically, there would be a visible artifact in the (theoretically continuous) TR at a child (TD) boundary, but that implementation detail would be irrelevant to me if not for the resulting visual flaw.
Related
I've attached two images showing the effect I'm trying to achieve, and what's wrong with the way I'm currently doing it. The first is displayed on page load, the second when you click on the down arrow.
The second partially obscures the first, currently using a negative margin. My current version has an invisible element underneath the leftmost box containing the icon, which has the same class as it that handles indentation. But At certain screen widths you get the effect below, where you can see the expanded section's border running halfway up the original element.
I've tried a few things to get rid of the glitch, but it's feeling a lot like pressing down bubbles - either they create worse problems, or the same problem at different widths.
I have the strong suspicion that I'm doing this all wrong, but I haven't thought of a better way to generate the same effects - border around the whole thing, text from the expanded element getting pulled up to approx where the original summary text was.
I can afford to use fairly modern CSS for this - our audience tends to be pretty high tech. In case relevant, I'm using a transition animation for the height increase, so it needs to be something consistent with that.
Before:
After:
The simplest fix for your problem is to make the left icon area overlap the rest (using z-index and position:relative) and extending it by 1px (so it covers the border in all cases).
Update your question with a code example and I'll update my answer with the fix, if the principle outlined above is not enough.
The alternative is to empirically determine the widths at which the border is misplaced and adjust the width of your dropdown, using #media queries.
Another rather important aspect which you don't seem to have determined is if the bug is specific to any particular browsers/devices.
As a side-note, I find quite a few questions similar to yours have one (rather silly) common cause: the developer has unknowingly changed the zoom level of their browser, pressing either Ctrl++ or Ctrl+-, viewing the page at 90% or 110%. Make sure you're developing at a zoom level of 100%, by pressing Ctrl+0.
I'd also like to suggest you take a look at How to ask to get tips on improving your question(s), to increase your chances of getting better answers.
I have a web app with a form in it. The form in turn has a select element with options containing a bunch of users' info, their names being set as the label/content of the option elements.
Now apparently one of the users' parents think it's fun to give their child a name with 3000 characters of gibberish in it.
I wouldn't want to make his life any harder than it is, but unfortunately I'll have to remove his account because the long name seems to introduce some interesting limitations on browsers that I didn't know about.
I started highly scientific testing using this fiddle with a few browsers in two computers and found out that
Chrome v50 (64bit) displayed a black box instead of the dropdown when the label length hit 1510
FF v46 refused to open the dropdown at all when the content length was 2716
IE v11 doesn't even break a sweat with tens of thousands of characters
Chrome v49 was the least fun of all. It rendered the whole window and all the other open tabs fully black so I had to close them all and start again. Didn't bother to find the exact limit for that
It seems though that the actual limits are much more related to the content width and not the length, as changing the character from "a" to "i" using proportional font affected the results.
The question: is there a reason Chrome and FF flip out with content of this size? Is there a specific limit on how long/wide the option's label can be (other than the subjective opinions about aesthetic/usable form inputs)?
I encountered something at work and I'd like to understand it.
I had copied the HTML of a website's header and put it in my own website (I can't provide a link to my site because it's on a private server). I also included all the CSS files of the site I was copying. Everything looked identical except for a couple little spots that were taller on my site.
I investigated and found that those spots were every place in which img elements were children of a elements. I ran Inspect Element on both my site and the one I was copying and found out that these a and img tags had all identical Rules and Computed, but that that a's were all 3px taller on my site.
I decided to compare all the Browser styles, although I expected nothing would be different, because, of course, I had been comparing in the same browser. Well, it turns out that on my site the a's had different properties for transform-origin and perspective-origin. I had never even heard of those properties until now, and Firefox did not show them as coming from any CSS files.
Can anyone explain this?
To sum it up very briefly:
Perspective origin is your point in space from which you are looking at the object, whereas Transform origin is responsible for setting the point over which you are making a rotation or translation with an object.
You should note that perspective is responsible for setting the view angle for a given element's children, and thus could explain the slight difference in those properties.
Okay, so I am in the process of designing a website which has a login form at the top-right corner of a webpage. I set the size attribute of its input fields and I am getting some interesting results. Below is a group of screenshots that I threw together. I even stacked them for you all. I am even throwing in a jsFiddle for you all. So four things:
I aligned them based on the bottom right hand corner of the password input field in the stacked image. Don't ask why.
I design with borders on everything until the layout is correct, then I remove them and add the colors and images and whatnot.
The IE 9 screenshot is based on Adobe's BrowserLab since I am working on a Mac.
Note that the WebKit-based browsers (Safari and Chrome) render the same size.
I could not find anything to reveal what is happening after a series of searches. Maybe it's because it's hard to word a question like this into simple search terms (or at least for me)…
With all of this said, my question is why is are the input fields rendered so differently, and most importantly, how can I remedy this (without JavaScript or the dependence on User Agents preferably)?
The size attribute sets the number of characters that the field will display (in the case of text and password fields). Different browsers use different default fonts, font sizes, and ppi measures, meaning that you get massively different sized (in pixels) fields.
Also, as the spec says, this is merely the "initial" width of the control, and the browser is free to resize the control if it decides it needs to in the course of reflowing the entire page.
To even have a hope of making this field close to the same (pixel) size on different browsers, you'll have to style it with CSS. That being said, there is probably a good reason that each of these are different sizes - mostly having to do with default fonts - and if you pixel-restrict the size of the field that means some browsers will display more actual text than others.
In our current project, we have one particular page where, when viewed in IE7 or IE8, fonts seem .1 or .2 em larger than they should be. Having inspected the code and css, I cannot see where this is coming from. This issue affects ONLY ONE PAGE which is to all intents and purposes exactly the same as many others in the site, which display as expected.
Some things I have ruled out:
Text-size settings (it's not that, set to medium, and anyway if so why one page only)
DPI settings (same reason as above)
Browser zooming (it's set to 100% - the problem scales with the zoom setting, btw)
Browser-specific CSS (no browser specific rules are applied to the elements in question)
Stray font-size setting code in the markup (I've been through and eliminated this)
Voodoo (okay I haven't ruled this out - as my frustration increases I'm starting to think it might be this though)
The page displays as expected in Firefox. This is not a live site yet so unfortunately I can't point you at the URL.
Has anyone come across something similar and, if so, what was it?
Many thanks,
G
Without showing us or replicating it at least, asking is pretty much near useless but I suspect it's probably just a tag that wasn't closed on an element with an above average font size.
I'd recommend validating the HTML. If it's good, then it's hard to say without looking at the code/page.