Re: Safari For Windows
Dagmar Culloton
Font rendering can be different between Mac and Windows Safari as the systems typically have different fonts. As long as your page can gracefully handle missing fonts or different font sizes it should be fine.
Style sheet rendering is significantly different between Safari and Windows. To see this, try creating a page that has an element with a z-index of -1. The windows version will function without issue, the Mac version will not allow you to select the elements. Trust me, I wasted about three hours trying to figure out by trial and error why a page would work in one system but not the other. The worst bit is that when Safari doesn't render something properly, it does so without any indication. You have to debug line for line, a dreadful experience.
I am currently experiencing an issue where floating images in a blog with text wrapping around the image do not properly pad themselves in OS X; works fine in windows. Basically I've added padding to make the image align flush left or right such that the edge of the image is at the same offset as the edge of the text of the post; on OS X the image sticks out past the edge of the text.
Just wanted to add this experience I came across for Safari. Our devs are still going to look into this but not high priority for us since Windows Safari isn't much of our user base unlike Mac. But I think it relates to either (or both) - actual browser low level implementation of Safari by Apple, and/or javascript differences.
Our website recently implemented an HTML5 multiple file uploader. Single file uploads work fine on both versions of Safari. But when uploading multiple files, it fails on Windows. We had two different upload clients & endpoints for the uploader (think A/B testing flow), and one of them provided more details that may or may not point at the cause of the problem. On one of the client & endpoints, the client would send details of the filenames & filesizes of files to upload (as JSON array object) to the server endpoint (as seen via web inspector). On Mac where it worked, filesizes were valid, on Windows, they were 0 bytes.
I had an issue with the popup blocker in Safari in Windows XP. I guess the blocker didn't accept that the user clicked a link an Flash that then triggered a JavaScript that opened the Window. The did work in the other major browsers and Safari in OS X, though. Chrome also blocked my window in XP, but not in OS X or Ubuntu.
I am working on a website that has pretty standard layout. I have a box that contains other divs. It works on all major browsers, from IE6+, FF3+, etc. On Safari 5 on OSX, the box is totally to the left, outside the borders of my website. On the same safari version in windows, no problem.I am going crazy over this.
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Hi, i wanna make my website fit for safari, but i'm developing on Windows machine. Is it possible to download a real version of safari for windows? Or is there any other way i can develop for safari without having a mac?
What I get instead varies. Sometimes the Safari window will expand a bit and move all the way to the right. Or to the left. Or just expand a bit more. I cannot reproduce the problem with any other application. I've looked for possible conflicts that might have to do with Safari in particular and can't think of anything.
If I had a problem like this, what I would immediately do to debug it is add a second action before or after this action that displays those four function values, so that I can detect if the SCREENVISIBLE() function is returning the right data or not. That would give us a big clue depending on whether the data it returns is accurate or not.
I'm pondering it. When you say "it expands a bit" do you mean it fully expands vertically but not horizontally? Since we can't see your results, we have to ask questions like this. You said "a bit" but I don't know what "a bit" means to you.
Okay! I'm able to replicate your problem! Now I can really investigate. I've noticed a pattern. When I perform the resize action three times in a row, (with a pause inserted) it always works. So if you are just looking for a quick fix, do that. If you're more interested in a perfect solution, that may take time.
I've tried it with dozens of apps, in various settings. Safari isn't the only app. The KM Editor is another such app. It always has the same behaviour as Safari in dozens of my tests. So it's probably easier to address because now we don't need a separate app (i.e., Safari) to test with. I cannot blame Safari if the same problem occurs with the KM Editor. That leaves two culprits, the KM Engine or the macOS API which is receiving the requests from the KM Engine. In my experience, when it's a choice between KM or macOS, it's usually macOS that contains the bug. I'm not sure if it's directly related, but I found a thread on a similar subject here:
I rarely tag @peternlewis because I hate to bother him, (and I'm usually wrong when I ask him a question) but I think we can ask him the following: When using the KM Editor, and "Trying" the following action, why does it take three "Tries" before the KM Editor window becomes full screen? (My versions of Safari and macOS are the same as the original poster's.)
You're right, there's lots of specificity I haven't provided. The intent of my original post was not, "Please help me systematically debug this issue," but rather to see whether it would evoke any, "Oh, THAT? Yeah, it's been there for a year. The fix is . . ." replies. I hope I wasn't misleading in that regard.
For the record, I have been experiencing a similar problem in various apps since upgrading to KM11. While the problem is not as neatly reproducible as this one (which I can reproduce as well), it occurs most often in Microsoft Word. After Word has been running for a while (TBD), it starts acting up when it comes to moving and resizing windows with KM macros. As is the case here, it takes several successive triggers of the same macro to eventually get the window to the desired position and size. The same thing also happens in Safari after Safari has been running for a while. And I've seen this problem at least once in Nisus Writer Pro as well.
Interestingly, I do remember seeing this problem ONCE in a version of KM prior to KM11. But it was an one-off and I chalked it up to some kind of glitch. Now I realize it was a rare occurrence of a long-standing problem, which unfortunately has come to the fore with KM11. (I started having the problem with early betas of KM11 in Ventura. Reverting to KM10 would eliminate it.)
I have been in touch with Peter about this. It's good that he now has a reproducible scenario! Hopefully it's the same underlying cause (probably a bug in macOS's Accessibility API) and he can figure out something to do about it, either by undoing whatever has changed between KM10 and KM11 or by finding some other kind of workaround.
In the meantime, for MY problem, I have found that replacing the single Move and Resize action with two SEPARATE actions, Move first and then Resize, with a pause of 0.5 s between the two, helps quite a bit. It does not COMPLETELY fix the problem (once it start occurring, after the window's parent app has been running for a while), but it moves the window to the right horizontal position and it resizes it to the right height and width after a single trigger. But the vertical position is still wrong (it stays at the very top of the screen), although ONLY when I try to move the window from my main display (with the menu bar) to one of my side displays (with no menu bar). In those cases, I have to trigger the macro a second time to get the window to move to the right vertical position. So it's better than having to trigger the macro 3 times every time, but it's not perfect either.
Your message could be helpful to Peter. Of course, he can already duplicate the problem so I'm sure he's going to try to fix it, if it can be fixed. Sometimes the problem is with macOS API rather than the KM Engine, but sometimes he can implement a workaround to make a faulty API do the job correctly. I'm sure he's very busy with KM v11 issues, so give him a little time to work on this one.
Can I be confident that the same will happen after installing El Capitan? If not automatically, is there a cache file or folder I can save before the install/dig up afterwards to restore the windows? Should I just bookmark all the tabs?
I wouldn't count on it. Specifically, I had several machines not rejoin WiFi after the upgrade, so the tabs didn't load with no network. I would save all open tabs to an HTML document and save it just in case if you really can't afford to lose your workspace.
Safari did not automatically reopen the windows, but they were still available in the history and popped right open when I selected "Reopen all windows from last closed session" in the "History" menu.
How can I merge a single-page Safari window (with no tabs) with another specific Safari window (which probably contains a few tabs) while leaving other Safari windows intact in a single action? Sort of like how I can do it with individual tabs.
When doing research using Safari, I open lots of tabs with potentially useful resources, and when there are enough of them, sort them into different Safari windows according to various criteria for further processing.
Another way seems to be to drag and drop the address field at the top (tricky to drag from the right point without triggering another action) and then into the + button on the right of the tabs in the other window. Works best in Compact mode I think.
I think probably the best way is to reveal the sidebar, then look at the tab groups. You may just have the default "X Tabs" at the top of each window. You can expand that and drag and drop tabs between windows into that default tab group.
59fb9ae87f