* [edbrowse-dev] home runs (fwd)
@ 2018-05-21 1:37 Kevin Carhart
2018-05-21 2:24 ` Karl Dahlke
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Carhart @ 2018-05-21 1:37 UTC (permalink / raw)
To: edbrowse-dev
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [edbrowse-dev] home runs (fwd)
2018-05-21 1:37 [edbrowse-dev] home runs (fwd) Kevin Carhart
@ 2018-05-21 2:24 ` Karl Dahlke
2018-05-21 9:50 ` Kevin Carhart
0 siblings, 1 reply; 3+ messages in thread
From: Karl Dahlke @ 2018-05-21 2:24 UTC (permalink / raw)
To: edbrowse-dev
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [edbrowse-dev] home runs (fwd)
2018-05-21 2:24 ` Karl Dahlke
@ 2018-05-21 9:50 ` Kevin Carhart
0 siblings, 0 replies; 3+ messages in thread
From: Kevin Carhart @ 2018-05-21 9:50 UTC (permalink / raw)
To: edbrowse-dev
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-05-21 9:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-21 1:37 [edbrowse-dev] home runs (fwd) Kevin Carhart
2018-05-21 2:24 ` Karl Dahlke
2018-05-21 9:50 ` Kevin Carhart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).