Comments (10)
I'm wondering if we need to change the HTML gatherer to a DOM gatherer. In the Node code we can use JSDOM / cheerio, in the extension use DOMParser
. Then you have something you can query more effectively with querySelector('head meta[name="viewport"]')
.
I suspect many of the audits that will want to query DOM will want to do so that way rather than via RegExps.
from lighthouse.
sounds good. Will take a look at doing this instead.
from lighthouse.
Yeah def give it a go. I do some branching in the manifest gatherer for similar reasons (fetch in extension vs request in Node). This would likely be the same thing. The viewport is the only audit reliant on this atm, so it's impact should be minimal, and the viewport audit has tests so ... 👍
from lighthouse.
BTW if you use DOMParser
you need to know it doesn't throw if it can't parse. It will make you a doc with a <parseerror>
node .... yah I know.
from lighthouse.
I've started looking at one way to do this dom like selector in the audits and ended up doing the following - https://github.com/GoogleChrome/lighthouse/blob/html-theme-color-audit/gatherers/html.js
I essentially give the audits access to the window OR use JSDom for node environments. (In the chrome extension I have to ignore the jsdom module because babel / browserify doesn't like something in it).
@paulirish seems not too happy about JSDom being added, so simple solutions would be:
- Use basic regex to extract the head and body content of the HTML string and share that with audits (Nice and simple but still requires regex for extraction, which isn't that big of a deal).
- Use chrome driver to access to extract the head and body and share those strings with the audits (Slight variation on the above)
- Pass the driver to the audits to request anything they want (Feels O.T.T and may not be overly reliable if the audits are async)
- .....
from lighthouse.
First, on ChromeDriver... It's doing 90% of its browser interaction by via the Chrome Debugging Protocol that we're using directly. So it's pretty much the jQuery to our DOM. And in this case, we're too cool for jQuery. (That and we're unable to do everything we want via ChromeDriver and they dont work side by side)
Overall, we should always trust the browser as source of truth and take care when serializing/reparsing over in Node that we maintain 100% fidelity with what the browser sees.
I think we have a few options :
gather/theme-color-meta.js
- read DOM: We useDOM.querySelector
andDOM.getAttributes
etc, just like in gathers/manifest.jsgather/theme-color-meta.js
ask JS: We useRuntime.evaluate
and get the answers we need from clientside JS. (actually what's in the old viewport gather and audit)gather/DOM-snapshot.js
read entire DOM: We dump some representation of the full DOM tree and reuse that across tests.
Talking with @paullewis and both of us favor 1 or 2, assuming they are done as a specialist gather and definitely not in the audit. They are fairly one-off gathers and rely on a live runtime, but they should be straightforward and less brittle than... 3.. which would be very testable, but would also need ergonomics sugar to handle walking, querySelectoring, etc.
@gauntface do you have a preference of 1 or 2?
from lighthouse.
I'm probably more inclined for option 2 but curious why it was changed from
this?
On Fri, 25 Mar 2016, 00:25 Paul Irish, [email protected] wrote:
I read in the opensource handbook that you should upset everyone with a
big rejection of a new contributor's first PR.Or not. [image: 😕] Again, sorry for being terse and stuff.
I feed this thread more flowers for good luck: [image: 🌷] [image:
💐] [image: 🌹]
First, on ChromeDriver... It's doing 90% of its browser interaction by via
the Chrome Debugging Protocol
https://chromedevtools.github.io/debugger-protocol-viewer/ that we're
using directly. So it's pretty much the jQuery to our DOM. And in this
case, we're too cool for jQuery. (That and we're unable to do everything wewant via ChromeDriver and they dont work side by side)
Overall, we should always trust the browser as source of truth and take
care when serializing/reparsing over in Node that we maintain 100% fidelity
with what the browser sees.I think we have a few options :
- gather/theme-color-meta.js - read DOM: We use DOM.querySelector and
DOM.getAttributes etc, just like in gathers/manifest.js
lighthouse/gatherers/manifest.js
Lines 49 to 53 in af3ead2
- gather/theme-color-meta.js ask JS: We use Runtime.evaluate and get
the answers we need from clientside JS. (actually what's in the old
viewport gather
lighthouse/audits/viewport-meta-tag/gather.js
Lines 21 to 33 in 432323b
and audit
https://github.com/GoogleChrome/lighthouse/blob/432323b1035e0449bb1ebdc20f0ef53923365a3c/audits/viewport-meta-tag/audit.js
)- gather/DOM-snapshot.js read entire DOM: We dump some representation
of the full DOM tree and reuse that across tests.Talking with @paullewis https://github.com/paullewis and both of us
favor 1 or 2, assuming they are done as a specialist gather and definitely
not in the audit. They are fairly one-off gathers and rely on a live
runtime, but they should be straightforward and less brittle than... 3..
which would be very testable, but would also need ergonomics sugar to
handle walking, querySelectoring, etc.@gauntface https://github.com/gauntface do you have a preference of 1
or 2?—
You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub
#77 (comment)
from lighthouse.
I'm probably more inclined for option 2 but curious why it was changed from this?
Not sure. Lewis did it a while back.
Closing this as it seems to be mostly taken care of with the DOM based approach in the PR now. I'm adding some documentation so that there's justification for this sorta thing.
from lighthouse.
Oh, on Chrome Driver. It might make sense to use ChromeDriver for tests, but I have a feeling like it'd break since we require the protocol in either case (although devtools eng is working on fixing that bug).
from lighthouse.
note that we already have the latest (continuous build) Chrome downloading and starting up (listening on port 9222) on Travis, so anyone can start writing tests against a live browser today
from lighthouse.
Related Issues (20)
- LCP Element is not visible when the LH Audit gets started programatically HOT 3
- Google chrome headless is rendering html as mobile view HOT 1
- Get CLS of 0 in timespan even though navigate gives a nonzero CLS value HOT 2
- Update "Using Lighthouse as a trace processor" docs HOT 3
- Feature Req.: Accessibility: check for correct markup of language HOT 1
- Lighthouse tests on the crypto exchange website Binance.com give varying scores and persistent issues that I am not sure how to interpret.
- Executing lighthouse lic gets stuck in alpine nodejs environment HOT 5
- Lighthouse User Flow doens't work in Docker HOT 5
- Missing types for `category.supportedModes` and `node.explanation` HOT 6
- Unable to connect to Chrome HOT 1
- ..
- browser extensions HOT 2
- Lighthouse warns when an anchor tag is just a placeholder HOT 6
- a11y gatherer hangs on https://almanac.httparchive.org/en/2021/ecommerce HOT 7
- Improve `runtimeError` HOT 1
- Lighthouse fails to produce accessibility score altogether for incomplete axe-core result HOT 4
- People detect Lighthouse to cheat its performance score HOT 4
- Isolate lantern in preparation for moving to trace engine
- Gathering trace data from iframe targets HOT 5
- Protocol error (Storage.getUsageAndQuota): Quota information is not available HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lighthouse.