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)?
Related
Some of the pages on the site I'm building cause chrome to prompt simplified view when viewed on mobile. These pages specifically seem to be the ones with more content (just more text and images than the others). Simplified view spoils the website look so ideally none of the pages would prompt this but I can't find a list of what could be causing the prompt in order to deal with it.
As a guess it may be possible that there is a word count above which the prompt loads or perhaps the greater amount of content is a red herring and there's another cause.
I found this Stack Overflow solution but unfortunately my text size was already larger than the answer recommended and so wasn't of help in this case:
Prevent show simplified view prompt or work with simplified view on Chrome
Thanks in advance for any assistance on this
I have experimented with the total word count, number of images, number of 'p' elements and length of page. The prompt is incurred if there are more than a certain number of text elements but that those elements each have to have a minimum amount of text.
Pages with few elements containing large volumes of text do not cause the prompt but neither do pages with many elements with little text, only pages with a certain number of elements with no less than a certain number of words cause the prompt to appear.
This seems to be the problem with the pages at fault on my site. Since I didn't want to change the volume of text on the pages I instead replaced the elements with elements which solved the problem, definitely not the most proper way to do it though.
I am trying to use the built in inspector tool in Google Chrome to manipulate the site http://www.di.se (as it probably has one of the most # layouts I have ever seen on a popular website) with around 300 000 visitors daily.
It seems to be mainly built with three HTML frame tags with the names: historyFrame, headerFrame and contentFrame. I can remove the headerFrame that covers a huge part of the view. However, I don't know how to change the contentFrame size so that it will cover the entire screen.
I have tried to add a CSS height property but it does not seem to change anything. If this is solvable I would be very thankful and so would 300000 other users :) Thanks!
The frameset, which is the parent of the frame you removed, specifies the heights for each of the frames, currently rows="0,210,*". So if you remove the header frame, the content frame becomes the second frame and gets a height of 210. By changing this attribute to 0,* the problem should be fixed.
However I'm not able to modify this property in Chrome's toolkit. Maybe this is a limitation of the developer tools of Chrome. After all, frames are old (removed even from HTML5), so maybe they didn't pay much attention to supporting it.
Note though that the top frame contains the advertising that probably pays for the site. If you got this working and all 300.000 users would use your solution, then the site would probably seize to exist, and you got 300.000 unhappy users. So think twice before you do this.
You can do it by:
First deleting the first Frame(header)
and modify this:
from:
rows=".260,*"
To:
rows="1,*"
So you have only the frame you want, no useless data and the frame you want take 100% of the screen.
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.
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.