So, I've been using this little bit of Javascript (as a bookmark) to increase the font size of various websites I visit on my iPhone's Safari browser (zooming in leads to too much scrolling from side to side).
http://www.everythingicafe.com/forum/iphone-software/increase-font-size-in-safari-without-zooming-9511.html
javascript:for(i=0;i<document.getElementsByTagName ('*')
.length;i++)void(document.getElementsByTagName('*' )
[i].style.fontSize='18pt');
However, this doesn't work on any of the StackOverflow sites. Any suggestions on how to fix it?
Poking thru the CSS in FireBug doesn't give me many clues except for a font-size: 100% that is in the p tag.
I tried changing fontSize='115%'); and it changed some of the text but not the question/answer body (the most important stuff!)
Stack Overflow uses relative font sizes for everything.
Here is a simple fix to adjust the font size for the entire document:
javascript:void(document.body.style.fontSize = '16pt');
Related
This is perhaps a more general question as I'm looking for ideas on how to approach a problem working with PDFView/PDFKit. I have a small sample application that allows you to display a page, select a range of text and then associate a comment with that text. Once the comment is saved the comment is displayed on the PDFView page in the margin via an overridden draw() function for PDFView.
Problem is that with very small margins the comments can be very squished. I've been looking for a straight-forward solution and would very much appreciate ideas on how to address it.
The obvious (ie, easy) solution is to change the actual "page size" in the PDFView and have wider margins, but of course PDFKit has no support for that (I don't think). Another thought was to go to a custom PDFView library but the only ones I found when I last looked were iOS (not Cocoa) based.
Last idea was to instead of drawing directly on the page have some sort of pop-up window (like a sticky-note) contain the note but then it would need to be moved dynamically with the scrolling of the page. And of course one other was to recreate the PDF dynamically for viewing and make all the pages larger... but I've not dug into how much of a performance hit / effort that would entail.
Maybe there's a simple/obvious solution that I've missed?
I created a simple sample app in gitHub which shows the basic functionality for people to play with if that's of help. https://github.com/jcnolan/PDFMarginTextView
I'm having an issue with getting Googlebot to correctly render my webpage(s).
It's rendering the header and one "row" of my page (just the page's top background picture), and then failing to render anything beyond that, not even the footer, missing about 3/4 of the page.
My site is www.runparis.fr and screenshots of the rendered fetch are attached.
Other potentially relevant information includes:
The code that was fetched is missing nothing
The fetch status is complete (no missing resources)
The problem is site-wide; it happens on all my pages
When I check the cache the whole page is rendered perfectly
Fetch as Google (mobile) renders the site perfectly
The site looks fine in any of my browsers
There's nothing funky going on in my page; It's just background images and text. Easy stuff.
My questions are:
Will google's inability to render the page have an impact on how Google ranks it?
Is there any advice for solving the problem and having google render the page correctly?
Thanks for any help or advice anyone can offer!
Googlebot render 2
Edit:
I've done another Fetch as Google and render for a test page and found that Googlebot will stop rendering after it has rendered any background images that I've set to "full height" in my page builder in my Wordpress installation; that is, any image that is set to take up the full height of the browser window kills the render.
So, it will render everything until it hits this image, renders that, and then stops.
As stated before, my page isn't fancy; It's just simple background images and text. It surprises me that Googlebot has trouble rendering what any browser can render perfectly, especially given the simplicity of the pages!!
So, my questions are:
Will Google not being able to render my page impact the way Google ranks my site? (given that what's in the cache renders fine on my browser)
And, Is this a common problem? Are there any fixes that will let Google render my pages correctly?
Some new information supplied by an external source:
"validator.w3.org/nu/?doc=http%3A%2F%2Frunparis.fr%2F"
"jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Frunparis.fr%2F&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en"
The various errors and warnings might explain why rendering is hampered in some tools such as Google Fetch and render.
Browsers are much more forgiving than all these validation and rendering tools.
I'm guessing that in Google's rendering tool the css rules that set the background image(s) and foreground image(s) and text content are being applied in the wrong order so background stuff ends up on top of foreground.
Does this new information help anyone understand why Googlebot would be having trouble to render the page?
I have experienced the same problem, the only viewable thing on the renderer was the hero section, and it was caused with defining height:100vh; for the hero section.This problem occur when using vh css units, or in some cases height:100%;
Here is the thread and discussion that really helped me out to understand the issue:
I believe that the google bot is doing this:
1. Looking at your website with a 1024x768 viewport.
2. Checks how tall the window.scrollHeight is
3. Resizes it's virtual browser to be the same height as the window.scrollHeight
4. Takes a screenshot and
5. Checks to see what elements are visible, and tallies SE score as appropriate. (Dinging content that is not visible.)
I partially solved this issue with inserting extra rules into mediaqueries: So for resolutions around 1024px width, I put max-height:800px; (rule height:100vh; stayed active) on my hero section, and on mediaquery for rules around 1280px width and up, I set max-height:none; (rule height:100vh; is active).
I'm still loosing around 30px of height in the renderer, but that's being cut off at the end of the page, with no text and any meaningfull content.
I have the similar issue with (Google Mobile-Friendly) tool and (Fetch as Google) mobile version is broken because Googlebot is not loading my style.css and affect my rankings
so I output my stlye.css code for mobile manually
add_action('wp_head','load_mobile_styles');
function load_mobile_styles () {
if( wp_is_mobile() )
{
ob_start(); ?>
<style>
enter code here
</style>
<style>
enter code here
</style>
<?php
echo ob_ob_get_clean();
}
}
I also have this issue. I am using Ubuntu and just completed the Hello world tutorial. I wrote some more text and I am unable to scroll. I can see where the words keep going but nothing I have tried lets it scroll. I have not made any HTML/CSS edits. I have only added more text to the <p> tag.
There is some default CSS applied for chrome packaged apps. Putting the following in your CSS should re-enable scrolling:
html {
overflow-y:scroll;
}
Someone is putting together a cool guide which might have some more tips. See https://gist.github.com/maicki/7622137#scrolling
Chrome apps have a default stylesheet applied to them, to help the web "page" be more of an "app" by default.
For Chrome Apps on Mobile, we also include this (well, a nearly identical) default stylesheet.
So that is the reason for that behavior. Scrolling is absolutely useful in very many contexts, and is absolutely supported in any DOM element by adding overflow-y: auto;.
It was simply deemed to be the wrong default for packaged apps which live inside a dedicated window of set bounds and where we encourage not having full page content overflow (very much the opposite of the web). Most apps usually surround a main scrolling element with fixed navigational elements (but not always).
FYI, there is also another open issue for Chrome Apps on Mobile to replicate yet more of the Chrome for Desktop default styles.
Got an issue I've been trying to solve without much luck for a while across various projects.
I've got some divs with text inside that is centered with CSS using display: block and line-height. I also tried with padding and a fixed height. Typically, these are setup as either just headers, or sometimes buttons.
Either way, I always seem to have an offset on the top from vertical center in the mobile safari browser that I don't get in ANY web browser (it's perfectly vertically aligned in a desktop browser). I can alter the setting to center in the mobile browser, but this throws out all the other browsers and this is a responsive design.
Has anyone experienced this issue?
I've got -webkit-text-size-adjust: 100%; but that doesn't seem to be related to this issue.
So far my hack work around is to have devices only css which sets a different line-height, but as you can imagine, that's a horrible solution.
This article has some great information on many different options for centering content when you don't know anything about the widths and heights:
http://css-tricks.com/centering-in-the-unknown/
It builds on from user1002464's answer quite well.
you can use display:table-cell and vertical-align:middle for the div containing the text
I'm having an issue with Outlook and when Windows Display (Control Panel > All Control Panel Items > Display) is set to Medium - 125% (or larger)
The text in the newsletter appears bigger and is creating issues with spacing. Although most of the issues with this can be resolved, I would like to know if there is a way to force Outlook to respect the pixel sizing as defined in the html email.
An example code block is something on these lines
...
<td width="460" valign="baseline">
<p style="font-size:16px;margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;" >Hello </p>
</td>
...
The text inside the <p> tag is 16px on a machine that has Windows Display 100% but is larger when Windows Display 125% (interestingly, the browser still respects the 16px and does not increase the font size like Outlook)
I don't think you're taking the right approach to this problem. Please look at it another way.
The user said "I want my text to be bigger". They probably said that because they have a very high res display or they have visual difficulties. It's their preference, if not their need, to have bigger text.
You're saying "how do I override the user's preference for my cosmetic convenience?".
Don't do that. Fix your layout's design so it adapts better to varying text sizes.
Reduce your image use and/or place your images so that they can handle being pushed around by the text. Consdier using scalable units like em or percentage font sizes to be more friendly toward people with visual difficulties or very-high-res displays.
Background:
The reason Windows scales fonts (and pixels) like this is because software developers for the platform have been consistently ignoring the font sizes the user sets in Explorer and the theme. Apps often force the use of their own fonts with specific pixel sizing instead of using the system fonts and sizes.
This has led to lots of apps that're unusable for people with visual difficulties, on media PCs, etc.
Microsoft wanted to give users a way to override these badly behaved programs, so they gave users a way to scale the pixel sizes provided by applications by a fixed percentage. Essentially they redefined a font "px" as an abstract unit that can be scaled.
Your HTML email is trying to be one of those badly behaved programs.