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.
Related
I am using Puppeteer to automate some processes.
I need to find the largest text on a web page.
I do not know if this is possible through Puppeteer. I suppose I could write a script that would check the CSS and all inline CSS on the page and try to find which class has the largest text size, but if the page is dynamically loaded it may make things more complicated.
Another issue would be if the text is bound within an element and the size of the text is just set to 100% of the width or height.
As far as I can tell it may not be possible to get the largest text on the screen, but I thought I would pose the problem here to see if other people had ideas for a solution.
Thank you.
I have a shopping website and I want to print a shipping labels for orders.
The format of the shipping lable need to be like in the picture.
which means, I have this structure, and I need to fill in 4 data fields.
The data is not the problem.
My problem is that I tried to do it, and when I pressed ctrl+p, I didn't have the option of printing the page horizontally.
So my question is how is it possible that I can't choose "horizontally" in the page-layout option??
If I succeed to fix this problem, it will be easier for me to do the rest, but still, I want to ask also if there is a way of writing HTML pages (pages to be print)? Because this is actually my first time that I write a page like this.
At the beginning I tried to write the text when it is rotated 90 degrees, so that when I print the page (vertically - because I can't choose another option...) it will be printed as I want it to be. I found it very difficult to write the data in its right position because I couldn't fit the data to the format (because it is 90 degrees rotated...)
Another important thing is the fact that this is not an online website, it is a website on the computer localhost (which means the URL is: "localhost/.../.../something.php"). I mention this because I have noticed that all the "localhost" pages don't have the option of printing horizontal. I don't know if it is related, it sounds very strange to me.
Does anyone have an idea why I couldn't choose "horizontal" in the printing options?
Or does anyone know what are the "rules" of HTML printing pages?
I have a user generated report page that is sometimes printed off, but it has a bizarre bug one internet explorer. The page is set as tables within a series of divs that appear on the website at all the same sizes and formats, however when printing with IE each page "shrinks" a little more. It may be that the margins are growing, but the relative font size and proportions of the table seem accurate in that they shrink with the pages. I have tried disabling the shrink to fit option, but that did not help. Has anyone run into a similar bug? I have been searching for a while but most of the related problems' fixes have not helped.
looked in to your page, what i think that is causing the shrinking of the page is the extra space at the end of the page.
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)?
We have an HTML page which displays a bunch of pretty bars using divs and repeating backgrounds. We are in the process of making a report out of this that can be printed nicely, but this may take some time because we don't have a reporting framework in place. As an interm solution we'd like to make the HTML version printable. The background of the divs are the only problem, and they don't print because of the default setting (which can't be enabled because the workstations are locked down).
I have found a work around for printing background images, but this doesn't work when the background needs to be repeated.
Are there any other work arounds which might be able to help? I have also been trying to insert an image inside the dive and stretch it, but this is throwing off all the other relative positions and is proving to be very difficult to fix. I am still looking into this however.
I have used this ActiveX Component in situations where controlling the printer output was absolutely neccessary (think printing stickers etc).
The function you'd want is : printBackground
However this doesn't come with their free license but perhaps the cost of that license outweigh the other work arounds implementation time.
Drawback: IE only.
If you can educate your users, there is an option in the print dialog box of IE and Firefox that is labeled something like 'Include Background Images' or 'Print Background Images'
This will include repeating background images.
I couldn't load the link, and I may not be understanding the problem correctly, but...
This is more of a work-around than a solution, but would you be able to make a single image that just appears to be repeated? Or at least, is repeated (for variable browser and screen sizes), but is large enough to be 'proper' for printing (which is a much more standard size)?
The easiest way I can think of achieving this is to have different stylesheet for printing that uses standardised images that fit the containers printed on paper.
The display stylesheet would continue to use the repeated images which wouldn't hinder performance as the full images loaded in the print stylesheet would only be loaded when the page is sent to the printer.
...at least, that's what the HTML spec says should happen. Whether this is actually the case, I can't be 100% sure.