[edbrowse-dev] home runs (fwd)

[edbrowse-dev] home runs (fwd)

[Kevin Carhart]

This could be a moot point after the acid tests, but I found out something 
interesting about the baseball reference website.  The visibility of the 
page is determined not by the CSS attribute "visibility" (or not only), 
but also by the CSS attribute "display".  The distinction between them 
according to W3Schools is that display:none will collapse and pull up the 
empty space when something becomes invisible, while visibility:hidden 
maintains the hole.  Not that we do that, but that's apparently the 
purpose that those two pieces of CSS would serve for designers.


So in baseball-reference.com, the CSS rule that hides everything is:
.f-i,#footer,#content,#inner_nav,#srcom display:none

So I assume that some time later, the subject-matter-related javascript 
file sr-min.js is supposed to set display back, but that code doesn't run 
I guess.  But here are a few interesting lines of jdb where I confirmed 
that setting display makes the page render.  Immediately at the time of 
the variable set, thanks to our cool side effects!


huh = document.querySelectorAll("#footer,#content,#inner_nav,#srcom")
[object Object],[object Object],[object Object],[object Object]

h0 = huh[0]
[object Object]
h1 = huh[1]
[object Object]
h2 = huh[2]
[object Object]
h3 = huh[3]
undefined

#never mind srcom, the first three are illustrative

h0.style.display
none
h0.style.display="block"
block
.
bye
lines 6 through 143 have been updated
jdb
h1.style.display="block"
block
.
bye
lines 144 through 1248 have been added
jdb
h2.style.display="block"
block
.
bye
lines 1249 through 1398 have been added


---

---------- Forwarded message ----------
Date: Sat, 12 May 2018 19:07:19
From: Karl Dahlke <eklhad@comcast.net>
To: kevin@carhart.net
Subject: home runs

> Hmmm. Which JS file is the visibility set in?

Some sites pull in 20 js files, we're lucky this one only pulls in one.
There is a lot of js on the home page though.
But that js dynamiclly creates and runs the other script.
Run with db3 and you'll see it pull in and run the cloud script.
I've made a local version that I've been playing with, so I don't have to go to the internet all the time.
That cloud script has a couple of places where it sets   blah.style.visibility = "visible".
Look for    visibility *= *.visible
but you likely have to deminimize the script first or it's a mess.

[edbrowse-dev] home runs (fwd)

[Karl Dahlke]

All corect. Just not sure what piece of javascript is not running, that would do what you did manually.
I can't find any reference to those particular nodes anywhere.
So it's looping through in some other way, maybe the whole document I don't know, and finding them and turning them on,
but it's not working for us which is weird as there are no errors.
I tried changing the user agent to look like a commercial browser, no dice.
Well it's not our highest priority, since I can type hover and bring everything back in,
or better still, run without js, which isn't needed here,
but it just nags at me a bit.

Re: [edbrowse-dev] home runs (fwd)

[Kevin Carhart]

> Well it's not our highest priority, since I can type hover and bring everything back in,
> or better still, run without js, which isn't needed here,
> but it just nags at me a bit.


Me too, I was hoping to get it.  Ok, I do have one more idea that I was 
pursuing for a little while today!

When edbrowse loads the baseball reference, it says in the source, near 
the top:
<!-- no:cookie fast load the css.           -->

So then the css is inline and when your CSS code runs in startwindow and 
gathers the "link" and "style" sources, I believe it picks up the CSS from 
inline CSS and not also from the file: 
https://d2p3bygnnzw9w3.cloudfront.net/req/201805182/css/br/sr-min.css

Now contrast this with firefox.  When I go to the baseball reference in 
firefox, it says this:
<!-- yes:cookie regular load the cached css -->

There is no inline CSS block.  It loads sr-min.css.

Now it appears that these two chunks of CSS are different.  The inline 
block has around 24000 characters and it actually ends on :
.f-i,#footer,#content,#inner_nav,#srcom{display:none}

While the file sr-min.css has 138000 characters and actually contains 
this:
.f-i,#footer,#content,#inner_nav,#srcom{display:none}#footer,#content,#inner_nav,#srcom{display:block}

Is it possible that the CSS to set display:block is not reached because of 
the difference between the inline CSS and the link?

Sorry if you've covered this and are aware of this already.  I wonder what 
cookie it's referring to.  When I run with db3, it shows that there are 
plenty of cookies being processed.

Kevin