<scribe> scribenick: clmartin

alrra: should we start?

clmartin: yes

alrra: hey everyone we're gonna get started
... we're gonna talk about sonar today. sonar started at Microsoft at first but we're gonna get into why it was started
... we realized today that doing web development is hard. it's complicated to keep base with everything. there are a lot of frameworks.
... it's impossible to keep track of everything that's changing. It's even worse as developers tend to search for quick answers which may not be the best.
... There are a lot of tools, some tools are good some are bad, some go deep while others scratch the surface.
... Developers don't know about all the tools.
... We thought about this internally and created sonar. The goal was to tackle all of these problems
... The intent is to help developers regardless of skill, educate them and lastly get rid of obsolete patterns and by doing so move the web forward
... from the start we wanted to be community driven with up to date best practices and flexible enough to be integrated with various developer workflows
... going to show some demos on how it works but there is a package you can install and also a live site scanner
... starts with a simple json config file, can be generated via sonar --init
... it asks a few questions when you kick it off but before that let's review the main components
... 3 main components, connector that handles connecting to browser-like things (chrome, edge, jsdom, etc.)
... rules which are the tests that run
... from the start we made the decision to not re-invent the wheel so to that end we integrate tools that do the job (axe a11y, ssllabs, etc.)
... with the rules we have 3 main things we look at, they should go deep and not just blindly check for things
... when it makes sense they should be configurable and lastly be context aware
... going to show some examples
... like i said you can run it from command line after you install it
... i'll just run it and sonar will detect that i don't have any configurations and it will ask me to choose a connector (which asks which browser to connect), formatters are how results are explained
... it opens the browser and starts analyzing the site. an example that touches on all the previous things - shows simple doc
... scans site using "sonar localhost"
... by default it will say something like "x-ua-compatible header is not specified" or "the meta tag is discouraged"
... the default is to have the most strict defaults
... rules go really deep and they know what to test by default but they are configurable
... documentation will explain edge cases and what the rules mean/do
... rules are context aware (aka provide the browsers you care about to sonar e.g. chrome 50)
... when you re-run with the new browser targets it will say the meta tag isn't needed
... rules are smart enough to adapt to the browsers/browser-like things your testing
... going to scan meetup.com/sfhtml5
... in this case you can see it found an image and even though the media type is .jpg the image itself is actually .png
... downloads the file and shows it's actually a .png
... rules are flexible/configurable, you can make them warnings or errors and pick the rules that are right for you/your team
... doing a scan on sonarwhal.com
... scanning example.com, in this case there are two meta tags that don't need to be there
... everything is documented, every test has full documentation including edge cases with links to the spec and community best practices
... there is core and then plugins, what makes sense for the entire community will go into core, otherwise plugins
... want users to be in control of what they're doing
... Why all of this? We want to help developers evolve their site as the web platform evolves
... the idea is to get rid of obsolete patterns from the web/cleanup the web
... for the future we're adding more tests, more configurations, start collecting data to generate stats
... plan to integrate them with editors (vscode to start)
... the project is open source, donated it to the js foundation
... if you want to engage you should go to sonarwhal.com (scanner/documentation and the rest are there)
... github.com/sonarwhal for issues
... and twitter is where we talk about stuff
... we built this and want input from standards bodies on what problems they have/what issues they see developers having and can we integrate that so we can test that
... questions/feedback?

rbyers: what's the goal/objective?

alrra: we've seen users don't test in all browsers and the goal is to help automate that
... we say about 17000 scans in the first few days
... make it easy as possible to test new websites
... the initial idea is that we know best what's happening behind the scenes so we can recommend what to do/not to do. the other reason is to help the community so the website works on all browsers including edge

rbyers: to help developers ensure that they're building great websites that work in all browsers
... does it do any perf metrics

alrra: it integrates with cloudinary

jrossi: the original motivation was the old modern.ie compat scanner
... wanted something more modern
... something you could run locally, that's more of a tool vs a prescription

alrra: the modern.ie scanner was static but this runs in a real browser, can do more things like wait for a site to load/do other things
... for a11y we inject script and wait for it to run

rbyers: can you give some example of issues you've seen

alrra: if you have a link with target _blank everyone else uses no referrer except edge

rbyers: can you call out javascript api's that are called that don't work everywhere

alrra: that's interesting, the idea in the future is to grab webidl's from all browsers and build a database
... as even caniuse is out of date

rbyers: it's still a hard problem to tell what api's the page is actually calling
... can you tell if they're doing a feature detect? we tried designs but haven't found anything that's useful/practical to build

sterns: could the content performance policy rules be rolled up into sonar

yoav: I don't necessarily think cpp set of rules would apply here. the target was to reign in 3rd parties and this is mostly targeted at first party content

alrra: not necessarily

yoav: but third parties vary

stern: they have amp rules

yoav: you could have cpp apply a similar set of rules saying your 3rd parties are awful

alrra: or you can ignore it, we've seen issues where you can't control 3rd parties so it's easier to ignore as well for some developers
... we can integrate other parses over time (typescript)
... and add best practices for things like typescript into sonar

stern: one thing that might be interesting is if the site is using an @supports rule for a new css feature to scan the css outside of the @supports rule to see if you have fallback styling for browsers who don't have the feature

alrra: how do you create a 404 page that's correct

yoav: going back to the cpp idea, theoretically you could try to figure out what features people shouldn't be using and notify them
... also notify them when new alternatives have shipped so they can adopt new policies

rbyers: that's the plan for lighthouse, warn people when a new feature has shipped
... interesting tradeoff between static/dynamic
... for dynamic you can guess but increasingly we have to rely on telemetry

alrra: one idea is to have steps like using webdriver for more complicated scenarios
... we started scanning a lot of websites and we've seen devs fail on a lot of things
... for instance compression, we haven't seen anyone using brotli

rbyers: one of the differences between this and lighthouse is that lighthouse has a score, that can be bad but it also motivates developers

alrra: we talked with lighthouse before releasing this but we didn't think scoring is right
... a service worker makes sense but maybe a manifest doesn't
... when you look at the scanner it will tell you where you fail and your competition passes
... we're tracking data over time, we're considering what to do but we can do a scan as well instead of just developers doing scans
... but we were sure we didn't want a scoring system

rbyers: it's great to see tools with multiple strategies to see how they're adopted

alrra: with lighthouse we know we'll overlap but we should agree when we do

rbyers: the other tradeoff is that lighthouse is intentionally designed to rely on internal hooks in chromium

alrra: rules can have connectors that only work with one browser

rbyers: in particular some of the things we added for lighthouse can be used here?

alrra: yeah
... some rules will only work in certain browsers as they're only exposed in certain browsers
... some tools have limitations, for instance with compression to really make sure we need to get raw bytes
... some things will be connector specific
... other questions or remarks?

: we have an internal tool for Edge where we can see code coverage of our DOM APIs (part of DRT suite); curious to see if other browser vendors are interested in a feature to turn on that feature in their browsers to get a scan of the web

rbyers: Chrome is interested in that; did a crawl run of 10k sites to prioritize which APIs to implement first--was a one-off hacky kind of thing. would love to instrument APIs but worried about the overhead

alrra: lighthouse sometimes recommends things that are Chrome, but some browsers do it differently, so idea was to come up with an abstraction that works in all browsers

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)


WARNING: No "Present: ... " found!
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
        <amy> Present+

Found ScribeNick: clmartin
Inferring Scribes: clmartin

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 08 Nov 2017
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)