I have a website http://www.domain.com and I am creating a separate section just for the iPad. I will be putting that in its own directory, http://www.domain.com/ipad/ is there a way for it to pull the contents of the /ipad/ folder but only show www.domain.com?
Hope that makes sense.
Thanks!
Do you have any example of a website doing this? Isn't a better option to serve this content from a specific mobile version, something like "m.domain.com"?
Added:
You can also do this. Use browser sniffing to serve a different stylesheet for the content if it is an HTTP request from an iPad. However, browser sniffing hardly works and it create good web-dev #fail joke memes. So, IMHO, using m.domain.com is the safest bet.
aHave your website serve iPad-specific contents if incoming request has user agent string set to iPad's (see this question).
PArticular implementation of serving content based on browser user-agents depends on which webserver / application container etc. you use.
I would not recommend doing this unless the content is significantly different for the iPad. This has SEO ramifications as well.
If the content is the same, a better approach is to use CSS media queries and serve a iPad styled version of the same website.
Related
I'm developing a SPA web app and it will support various languages. It is build with AngularJS and I am using angular-translate to provide i18n.
But I am struggling a little bit with how the URL structure should be. I do no plan on using either gTLDs nor ccTLDs, so that leaves me with three options.
Use query params: ?locale=en-us
Use url paths: /en-us/page
Store the chosen locale in localStorage or a cookie
The first option is a no-go according to Google's guidelines for web apps SEO. So that leaves me with the last two options.
I have a hard time deciding which is more beneficial, though I am inclined to believe that using url paths would probably be more crawler friendly.
P.S: Not sure if this is the best place to ask such a question either.
The second option is your safest bet as according to https://webmasters.stackexchange.com/questions/59652/what-happens-if-i-try-to-set-a-cookie-on-a-bot cookies are ignored. You can test this yourself by going to the Google Console and fetching your website.
As of now most crawlers ignore cookies and DO NOT execute JavaScript. This means that they usually just download the html and make their judgements from there.
Some developers get around the no javascript problem by pre-rendering parts of their content. I haven't done it personally but you might want to check out https://prerender.io/
Edit
As rolandjitsu mentioned google crawls and executes javascript content.
You should go with second option: provide the language tag (and, optionally, region subtags) in the URL path as first segment.
For the simple reason that it allows you, visitors, and bots to link to specific translations.
I am developing a site using PHP, and I was a bit mislead by how Appcache works; it turns out that it also caches the current page. Which, in the case of a PHP app, is a problem. :)
I'd still like to cache my javascript, css and images on the client, but not my actual generated page. What is a good alternative for that? Just the plain old cache headers? The problem I see with them is, that they still produce requests. I am trying to mimize the amount of requests a client needs to make - this includes 304s.
As you might have found out by now, appCache is in the process of being deprecated and will sometimes disappear. It was a good solution for offline applications (static pages with variable data), but not as a cache for static files in dynamic pages.
You could try to include a blank page with a manifest in a hidden iframe in your dynamic pages, but still only pages present in the appCache would use the static resources downloaded from the manifest; the other pages would check the live static resources from the server anyway (the only part of the manifest which is valid everywhere is the "fallback" part).
So your best option is to check your cache headers as suggested by Marged, as it IS possible to avoid server access indefinitely for a static resource.
You could dig what the ServiceWorkers cache does, but I'm not an expert in the field (for now).
I have a black box container. I love black boxes, they obfuscate things so well.
This black box is an encrypted zip (sort of) and has inside some html files (this is the short, not so painful to explain, version).
Those files need to be displayed in an UIWebView. Now, the easy way to do it, decrypt, unzip to filesystem, load file from filesystem. That's good, except, the black box contains secret stuff, and can't just lay around on the filesystem, not even a sec, so, I made a C library that actually streams the contents of the box (directly out of the box).
Now, I have this streaming capability and have to somehow make it work with UIWebView. First thing that comes in my mind would be to use a mini local HTTP server where the UIWebView can sent its requests. I would then manage the requests myself and return the contents the UIWebView requires using the streaming lib I've done. That would work I suppose well, but I think a mini HTTP server would somehow, maybe, be a little bit of a overkill.
So, I was wondering, is there another way to interfere between UIWebView and the filesystem? Maybe using a custom schema? Like myschema://? And every time the UIWebView makes a request to myschema://myfile.html I would somehow interfere and return the data it needs?
Is such a idea viable? Where should I look to start from? Maybe NSURLRequest?
EDIT: I found this: iPhone SDK: Loading resources from custom URL scheme. It sounds good, however, how will the browser know the size of the request, the type (xml/binary/xhtml) and all the info HTTP puts in its header?
Create a custom NSURLProtocol subclass and register it so it will handle the HTTP requests. This will allow you to handle the requests that come from the UIWebView however you see fit, including supplying the data from your library. You can examine an implementation of one that performs disk caching of requests to allow offline browsing by looking at RNCachingURLProtocol. I personally use a custom NSURLProtocol subclass that I wrote to handle injecting some javascript code into pages that are loaded in the UIWebView, and it works very well.
I am looking for options on how to deal with an issue as I don't think there is an easy fix.
We're dealing with a really stubborn client that doesn't want to accept the fact that browsers don't print css backgrounds by default.
He's convinced that XP running IE 6 & 7 are the most common browsers and we are a bad company for not supporting them. (I've shown him analytics from our typical client's visitors but it hasn't changed his mind). I'm rewriting his site to work on them but am stuck with the print stuff now.
He would like (demand is a more accurate term) to have the page print exactly as it looks on the site as well as them look exactly the same in all operating systems & browsers. I don't think it's feasible to go through and put all the images in the html instead of in the css and I've tried the list-style tip without luck. Lots of the color of the site comes in from background css colors as well.
Is there any other options? Or even suggestions on how to deal with this client?
Try something like:
<style type='text/css'>
#import 'whatever.css' screen, print;
</style>
Make sure #import is above all other CSS tags, and that you target the external stylesheet that you have your CSS for your page on.
Here's a slightly different approach:
I would consider converting the web page to a pdf which you can print instead.
An nice way to do the conversion is through a product called PhantomJS. It's essentially a headless browser that will render the page and convert it to a pdf on the fly. You can integrate by running the PhantomJS server and add a link on the original page to download the pdf.
The pdf will then print the page consistently across all browsers. There is however a decent amount of additional work, so you have to consider if it's a good fit for your needs and timeline...
Additional complexity with this solution is that you have to host the PhantomJS javascript server somewhere, write a PhantomJS script using the API to convert your page to pdf.
Pdf and image conversions are relatively easy to do, but you have to also consider authentication if your pages require login. PhantomJS will write the converted file to disk on the server, so you would also have to manage downloads to the user's browser.
All in all it's a good chunk of work, but you might find it interesting to at least learn about it :-).
More info here:
http://phantomjs.org/
I've read that its bad (not advised) to use User Agent Sniffing to send down the correct content for a mobile browser, so I'm wondering what IS the best way to do this?
I'm using ASP.NET MVC, and I've built my site and it works well on desktop browsers, so I'm looking to begin building a mobile version. When a mobile browser comes to my site, I'd like to use a different set of Views, which ideally posses the following attributes:
Link to pre-scaled images
Use minimal javascript
Remove all but essential content
My first thought was to sniff the user agent, and then send down a different .CSS file, but as stated above I've read that this is a bad way to do this, so I'm asking you for your thoughts.
The user agent is really all you have in a HTTP GET request, but you should let someone else maintain the list. We use the Microsoft Mobile Device Browser File with a custom view engine in a manner roughly similar to this Scott Hanselman post.
The best way to detect a mobile browser is to use this wonderful codeplex project:
http://mdbf.codeplex.com/
For background on how you could create targeted views read here:
http://www.hanselman.com/blog/MixMobileWebSitesWithASPNETMVCAndTheMobileBrowserDefinitionFile.aspx
The simplest approach could be use a separate domain "m.yourdomain.com" or "yourdomain.mobi" (Source) that way you can assume that the user is on a mobile device.
While I believe it's frowned upon to sniff for browser to determine capability and you should use capability sniffing, such as JQuery.support. When it comes to actually presenting significantly different layouts then I think you have to sniff for the browser ID and act accordingly.