<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">To bring everyone up to date, we had a discussion during the all-hands about what’s next.<div class=""><br class=""><div class="">There’s a spectrum of how informative "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">correctness </span>checking" for CSS and HTML can be: from just verifying syntax (“your nested `calc` needs more parens”), to fully fledged semantic validation (“you’re floating a flex item, wat”). Static checks aren't able to provide much value in that regard and tend to be useful only for the former end of that spectrum. Runtime checks make the latter possible, and they’ve also been proven with our devtools Inspector.</div><div class=""><br class=""></div><div class="">Just as with JS, distinguishing between coding style and code correctness is going to be useful with CSS. We should leverage the existing formatting machinery we have in place to deal with the former, and devise a more capable solution for the latter. This means using Prettier for CSS _formatting_, alongside a yet to be decided cocktail of tooling and runtime analysis for CSS _linting_ (which we might enable on debug builds and/or on CI). Simple checks to at least make sure we don’t ship broken CSS is a good way to start, Gijs already has a few ideas here.</div><div class=""><br class=""></div><div class="">All of this is orthogonal to enabling Prettier for JS inside markup, which is underway.</div><div class=""><br class=""></div><div class="">Victor</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 30. Jan 2020, at 10:37, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" class="">gijskruitbosch@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">I'm curious about the linting side of the HTML and CSS work. Can
we land an initial version that at least checks for validity, even
if we don't do formatting or much else yet, and improve things
incrementally in that department? Basically, I'm interested in
getting something up relatively quickly that helps enforce we
don't land broken things into nightly because something got missed
in review (or in a post-review update to a patch). I wouldn't
expect just the linting to have blame implications of a magnitude
where it'd be worth doing something about the archaeology (ie
hopefully almost all the CSS we ship is already valid CSS...) - in
other words, can we use an approach as we have with progressively
enabling eslint rules for that work?<br class="">
</p><p class="">~ Gijs</p>
<div class="moz-cite-prefix">On 29/01/2020 11:11, Victor Porof
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:455FE60B-BA28-4DCB-8F89-6A88C73FD716@mozilla.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
Happy to see continued work around tooling, thanks everyone! Here
is some of the work I’m currently involved with:
<div class=""><br class="">
</div>
<div class="">Coding style</div>
<div class="">===</div>
<div class=""><br class="">
<div class="">I’ll be extending coding style enforcement to HTML
and other markup files. For example, we currently disabled
Prettier for JS in HTML and the likes, and I want to turn that
back on. Many of our tests are written this way, and there’s
no reason why we shouldn’t extend our coding guidelines to
cover them. </div>
<div class=""><br class="">
</div>
<div class="">I’ve also taken a look at various CSS linting and
formatting approaches last year, and we can fit those neatly
into the current tooling infrastructure we’ve built for C++
and JS. Defining what linting means exactly is slightly
trickier for CSS, but I’m confident we can figure out a set of
reasonable guidelines to enforce. I’ll keep you posted on the
progress as it develops.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">In terms of what the whole process looks like,
as with JS formatting last year, I’ll be coordinating with
relman, doing preliminary formatting passes and enabling
these checks at commit time/ review time sometime before a
merge to limit the impact on the beta uplift process.
Leveraging the existing tooling for doing archeology is also
a must every time we start formatting bits of our code.</div>
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Runtime coverage</div>
<div class="">===</div>
<div class=""><br class="">
</div>
<div class="">With the RKV work (unifying key-value data stores
across Mozilla), it became clear that we need to start
tracking when data corruption happens. We currently have no
way of knowing when Firefox users lose their data. Migrating
to RKV is going to help with the robustness part, and to prove
that it works I’m adding telemetry for tracking these kinds of
incidents, for example: 1. data corrupted, we throw it away
and 2. data malformed but salvageable.</div>
<div class=""><br class="">
</div>
<div class="">A broader scope of this kind of investigation is
trying to make sense of our profile directory. The RKV work
currently limits itself to key-value storage, but the guiding
principles of having more robustness can be extended to more
than just key-value data. The more we inch towards better
telemetry surrounding data robustness, the more we need to
have a system in place that tracks what kind of storage we
have in our profile directory, what gets added and what gets
removed, and equally importantly: what gets corrupted.</div>
<div class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Victor</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 29. Jan 2020, at 09:32, Brian Grinstead
<<a href="mailto:bgrinstead@mozilla.com" class="" moz-do-not-send="true">bgrinstead@mozilla.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div dir="auto" class="">
<div dir="ltr" class="">Thanks for bringing this up -
I think it’s a great idea.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">We have a few environments to
deal with here between parent vs content process
combined with chrome vs content privileged. So in
general if we can make shared Custom Elements
content privileged that will support all
environments, and have the benefit of being able to
develop/test in a normal web page. We could also
consider pulling in third party development tooling
like Storybook to make it easier to build and share
the components.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">It also would help further XUL
element removal as we begin to share the elements
with chrome. There will be some details to figure
out for scenarios where we currently rely on chrome
privilege in the elements for important reasons
(like, could we mixin the “content” version of the
element when it’s used in chrome as a way to expose
these features?). But those are solvable problems
and I trust mstriemer would do a good job getting to
a consensus and pushing this forward.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">Brian</div>
<div dir="ltr" class=""><br class="">
<blockquote type="cite" class="">On Jan 29, 2020, at
8:23 AM, Mike Conley <<a href="mailto:mconley@mozilla.com" class="" moz-do-not-send="true">mconley@mozilla.com</a>>
wrote:<br class="">
<br class="">
</blockquote>
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">Oh, one more thing comes to mind
here, presuming it's in the scope you had in
mind when you started the thread:<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I've been chatting off and on with
mstriemer about looking at ways we can share
more UI components between both the browser
chrome and the in-content pages. The idea
would be to populate toolkit/ with custom
elements that are generalized (but
customizable) for reuse.</div>
<div class=""><br class="">
</div>
<div class="">As an example, I think the search
inputs in both <a href="about:logins" class="" moz-do-not-send="true">about:logins</a>
and <a href="about:addons" class="" moz-do-not-send="true">about:addons</a>
could be pretty decent candidates for a shared
custom element.</div>
<div class=""><br class="">
</div>
<div class="">-Mike<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 28 Jan
2020 at 10:43, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" class="" moz-do-not-send="true">gijskruitbosch@gmail.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hello
firefox-dev,<br class="">
<br class="">
It is already almost February, so in the
spirit of better late than <br class="">
never: let's talk 2020 planning for improving
code quality, <br class="">
maintainability and developer productivity in
Firefox!<br class="">
<br class="">
Some of us talked about this at all-hands last
night - there is definite <br class="">
room for improvement in our processes and
automation aimed at improving <br class="">
the quality of code changes and how productive
we all are when working <br class="">
with the code.<br class="">
<br class="">
Some ideas that came up include:<br class="">
<br class="">
- more linting for CSS, HTML, SVG, Fluent and
other files (basically, <br class="">
eslint-style linting for non-JS)<br class="">
- type inference in JS<br class="">
- automated infrastructure jobs to get runtime
coverage for issues that <br class="">
are harder to check statically (e.g.
accessibility, performance)<br class="">
- guidelines/policy/documentation on code,
architecture, issues to look <br class="">
out for in reviews, etc.<br class="">
<br class="">
What kind of improvements do you think are
most important on the code <br class="">
side of the Firefox/Toolkit codebase, and why?
What big things are we <br class="">
missing that you've seen elsewhere?<br class="">
<br class="">
~ Gijs<br class="">
<br class="">
_______________________________________________<br class="">
firefox-dev mailing list<br class="">
<a href="mailto:firefox-dev@mozilla.org" target="_blank" class="" moz-do-not-send="true">firefox-dev@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank" class="" moz-do-not-send="true">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
</blockquote>
</div>
<span class="">_______________________________________________</span><br class="">
<span class="">firefox-dev mailing list</span><br class="">
<span class=""><a href="mailto:firefox-dev@mozilla.org" class="" moz-do-not-send="true">firefox-dev@mozilla.org</a></span><br class="">
<span class=""><a href="https://mail.mozilla.org/listinfo/firefox-dev" class="" moz-do-not-send="true">https://mail.mozilla.org/listinfo/firefox-dev</a></span><br class="">
</div>
</blockquote>
</div>
_______________________________________________<br class="">
firefox-dev mailing list<br class="">
<a href="mailto:firefox-dev@mozilla.org" class="" moz-do-not-send="true">firefox-dev@mozilla.org</a><br class="">
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></div></div></body></html>