search

Samantha-Mcguigan / newsAnalysis

repository for our newsAnalysis web page
3 stars 0 forks source link

Safari browser trouble with SVG on analysis pages #19

Closed ebeshero closed 6 years ago

ebeshero commented 7 years ago

The analysis pages (the ones with SVG graphs) are rendering in a way that blocks out the top and bottom of their HTML pages in Safari. (We should check Internet Explorer too).

My hypothesis: I think the problem might be with CSS flex boxes on these pages. To test, try an alternate CSS for these pages without any flex, and see if that renders better. I could be wrong and I'm going to ask around to see if they're seeing a similar problem over on Obdurodon...

ebeshero commented 7 years ago

Okay--here's what we know about browser support of CSS flex: http://caniuse.com/#search=flex It's supported by all browsers, and as long as you have a version of Safari above 10, that should be okay. That said we do have some well-formedness issues on the pages once the server-side includes fire--that is because they're currently set to open up inside the <head> element, instead of at the top of the <body>. It's interesting that the browsers are generally rendering things anyway, but the visible part of the page in the browser window is really supposed to be in the <body> for valid HTML.

@jonhoranic @ajnewton1

dotfig commented 7 years ago

Take a look at the site @ebeshero @jonhoranic @Samantha-Mcguigan and let me know if this is what you guys were thinking o

ebeshero commented 7 years ago

@ajnewton1 I think it looks like a better use of the top space, and I like how all the items are easily visible in that space! I think it's collapsing funny on squish: the items can overlap the newsAnalysis logo. I think you can fix that by floating the menu items as divs next to each other and trying a CSS flex arrangement to manage how they take up space in the browser.

Here's a problem: You want to move your server side include line down into the <body> element: it's making the HTML invalid (and might make it behave weirdly depending on browsers).

ebeshero commented 7 years ago

@ajnewton1 On second thought...I had a look at it on my iPad, and I kind of like how the menu items appear above the words News Analysis Project in the smaller browser window! And having the menu options opening to the right looks great!

For a few minutes, I think I saw the search window, and it was working-- I was thinking we could actually set it to run again even from the result search.php page...since it runs by firing JavaScript. It's okay to have two JavaScript <script> elements pointing to two different files. They shouldn't conflict. Just make sure you move the SSI line down into the <body> element where it belongs!

dotfig commented 7 years ago

I think I got it to work. Once you're on the php page you can now search for another word @ebeshero

ebeshero commented 7 years ago

On the search.html page, take a look at the Search icon (is it the emoji?): On my browsers it comes out like this: Search🔍 I think to make sure it comes out right, you want to just add this line to the <head> element in the HTML (and it should probably be on every page): <meta charset="utf-8">

dotfig commented 7 years ago

Huh, thats very interesting. On every other page the emoji is perfectly fine

ebeshero commented 7 years ago

I didn't realize it was the same character! I bet there's something different in the encoding on that page...let me check.

dotfig commented 7 years ago

I figured it out! There was no <?xml version="1.0" encoding="UTF-8"?> written on the top of search.html

ebeshero commented 7 years ago

@ajnewton1 OK--that's one way to fix it, but... ....go look at your page in the w3c validator. HTML 5 doesn't like to see an XML line at the top. So if you remove the xml line, try adding <meta charset="utf-8">. Trick is, it should be on every page...

ebeshero commented 7 years ago

The w3c validator can be annoying, but among other things it likes the <script> line to look like so: <script src="javascript/menu.js" type="text/javascript">/**/</script> (The way we've got it, it's like this: <script src="javascript/menu.js" type="text/javascript">//</script>, which makes the validator fire an error. )

dotfig commented 7 years ago

Another thing I'm getting caught up about is the npr.html page and the fox.html. Its acting weird

ebeshero commented 7 years ago

@ajnewton1 They look the same as the others to me--what am I missing?

dotfig commented 7 years ago

When I click on those links. They both look go back to how the page originally looked and I am not sure why it is doing that on my browser.

ebeshero commented 7 years ago

@ajnewton1 here's how the NPR page looks on my end:

screenshot 2017-04-24 21 46 01
dotfig commented 7 years ago

Ugh, this always seems to happen to me. Maybe it is just Safari...

screen shot 2017-04-24 at 9 48 11 pm
ebeshero commented 7 years ago

Hmmm... I think you need to refresh it from the server. Might be from the browser cache? Try command + R to refresh from server.

http://osxdaily.com/2012/04/03/safari-keyboard-shortcuts/

dotfig commented 7 years ago

Wow that was simple!

ebeshero commented 7 years ago

I may not have told you all about favicons, and setting one up on your site...the other projects from last term have them... It's the little tiny image that shows in the browser tab. You can set that by choosing an image (any image) that you think would look sharp when shrunk to like 16 x 16 pixels, and save it as favicon.ico in the root of you project directory.

screenshot 2017-04-24 21 59 12

I should open a new issue on this...