<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="">There’s other tooling that could benefit from not using the preprocessor in CSS as well. During the XBL work we explored adding code coverage support to CSS to help detect regressions as DOM structures changed, the idea being that we could do a try run and see if any specific rules used to match but no longer were. I still think that'd be a useful tool to help avoid regressions when making visual / frontend changes.<div class=""><br class=""></div><div class="">At the time I filed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1561001" class="">https://bugzilla.mozilla.org/show_bug.cgi?id=1561001</a> to track removing preprocessor usage from CSS. The proposal was to use @import instead of #include and to use CSS variables instead of substitution, which would handle many of the consumers. The concerns about runtime performance of CSS variables are good to bring up - I know I’ve seen some optimizations land over the years and at the time I didn’t see any red flags (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1561001#c4" class="">https://bugzilla.mozilla.org/show_bug.cgi?id=1561001#c4</a>), but it would be great to do some proper performance testing and raise any concerns to the style team since any fixes here would help us with web content that uses a lot of variables as well.</div><div class=""><br class=""></div><div class="">Brian</div><div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 5, 2020, at 5:44 AM, Dão Gottwald <<a href="mailto:dgottwald@mozilla.com" class="">dgottwald@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Note that toolkit and browser stylesheets use preprocessing for re-using things that don't change at runtime. So if you want to lint before building, that probably isn't going to work unless we either 1) make the linter understand preprocessing, 2) duplicate and inline these things instead of reusing them -- a loss for productivity, so not really desirable in the context of this effort and otherwise -- or 3) use CSS variables -- these might add runtime overhead. At times CSS variable overhead even showed up as talos regressions if I remember correctly. CSS variables aren't the most performant tool to use out there, although the situation may have improved in Gecko over the last few years.</div><div class=""><br class=""></div><div class="">I think we encounter syntactic CSS errors relatively rarely (and we already catch most of them with browser_parsable_css.js), so if in the end we want to check semantics anyway, maybe the right tradeoff is to just keep the preprocessing.</div><div class=""><br class=""></div><div class="">dao<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 3. Feb. 2020 um 08:44 Uhr schrieb Victor Porof <<a href="mailto:vporof@mozilla.com" class="">vporof@mozilla.com</a>>:<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"><div style="overflow-wrap: break-word;" 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="" 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 class=""><br class=""><blockquote type="cite" class=""><div class="">On 30. Jan 2020, at 10:37, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" target="_blank" class="">gijskruitbosch@gmail.com</a>> wrote:</div><br class=""><div 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="">On 29/01/2020 11:11, Victor Porof
wrote:<br class="">
</div>
<blockquote type="cite" 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" target="_blank" class="">bgrinstead@mozilla.com</a>>
wrote:</div>
<br class="">
<div 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" target="_blank" class="">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 class="">about:logins</a>
and <a class="">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" target="_blank" class="">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="">firefox-dev@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank" class="">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" target="_blank" class="">firefox-dev@mozilla.org</a></span><br class="">
<span class=""><a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank" class="">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" target="_blank" class="">firefox-dev@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank" class="">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></div>_______________________________________________<br class="">
firefox-dev mailing list<br class="">
<a href="mailto:firefox-dev@mozilla.org" target="_blank" class="">firefox-dev@mozilla.org</a><br class="">
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank" class="">https://mail.mozilla.org/listinfo/firefox-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>