<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=""><div class="entry"><p class="">This is the fifteenth edition of the XUL/XBL Replacement 
Newsletter. Since the last edition we’ve been working to incorporate 
more web standard code into the browser frontend, and converted some 
particularly complex XBL bindings to Custom Elements.</p>

<h2 id="css-shadow-parts" class=""><span style="font-size: 12px;" class="">CSS Shadow Parts</span></h2><p class="">With XBL, direct descendant CSS selectors are able to traverse the 
anonymous content boundary. For instance, if dropmarker has some 
anonymous content like: <code class="highlighter-rouge"><content><image class="dropmarker-icon" /></content></code>, then the icon could be selected from a document stylesheet with: <code class="highlighter-rouge">dropmarker > .dropmarker-icon</code>.
 This is handy and we’ve relied on it all over the place, but can be 
confusing: it’s not always clear when reading the CSS if you are working
 with anonymous or explicit content. Also, it’s unsound in the presence 
of dynamic changes to the DOM, and fixing that in the style engine would
 be very complicated.</p><p class="">Previously, we didn’t have a way to do this with Shadow DOM. Because 
of that, we would often convert bindings to use explicit DOM children 
instead of Shadow DOM (using <code class="highlighter-rouge">appendChild</code> etc in the <code class="highlighter-rouge">connectedCallback</code>) so that we could continue to style contents from our stylesheets. The <a href="https://drafts.csswg.org/css-shadow-parts/" class="">CSS Shadow Parts specification</a> aims to close this gap. With Shadow Parts you can expose an element in the Shadow DOM like: <code class="highlighter-rouge"><image part="icon"></code> and then target it from CSS with syntax like: <code class="highlighter-rouge">host-element::part(icon)</code>.</p><p class="">Emilio Cobos Álvarez has added partial support for this feature in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1505489" class="">bug 1505489</a>, and we recently started using it in our first chrome Custom Element. Here’s the <a href="https://hg.mozilla.org/mozilla-central/rev/87e14a059e60" class="">changeset</a>
 that shows what that consumer looks like. We are planning to keep 
working with it in order to provide usage feedback to the standards 
process, and also to convert XBL bindings that need to use Shadow DOM 
and are also extensively styled from document sheets (like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1397876" class="">arrow panels</a>).</p>

<h2 id="box-object-removal" class=""><span style="font-size: 12px;" class="">Box object removal</span></h2><p class="">XUL box objects were helper objects used to implement some layout 
features that could be tailored to the specific layout used by an 
element. Replacements for box object properties are generally available 
as web standard properties like <code class="highlighter-rouge">getBoundingClientRect</code>, <code class="highlighter-rouge">screenX</code>, and <code class="highlighter-rouge">screenY</code>.</p><p class="">Neil Deakin has now <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1519948" class="">completely removed this feature</a>.
 Frontend code was migrated to use the standard properties when 
possible. For cases where there is no standard property, the 
functionality has been moved to specific XUL element subclasses.</p>

<h2 id="binding-removals" class=""><span style="font-size: 12px;" class="">Binding Removals</span></h2><p class="">There are <a href="https://bgrins.github.io/xbl-analysis/#timeline" class="">25 bindings left</a>, compared to 33 from the last update and 300 from the start of the project. We also have a <a href="https://bgrins.github.io/xbl-analysis/tree/" class="">bug on file</a>
 for every remaining XBL binding and are looking forward to a big drop 
after the upcoming merge to 70, once the old <a href="about:addons" class="">about:addons</a> and old 
awesomebar code gets removed.</p><p class="">Here’s a list of changes since the last update:</p>

<ul class="">
  <li class="">Alex Surkov <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1534404" class="">converted the <code class="highlighter-rouge">searchbar-text</code> binding to a Custom Element</a>.</li>
  <li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1519514" class="">converted the <code class="highlighter-rouge">tab</code> and <code class="highlighter-rouge">tabbrowser-tab</code> bindings to Custom Elements</a>.</li>
  <li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1544916" class="">converted the <code class="highlighter-rouge">dialog</code> binding to a Custom Element</a> using Shadow DOM.</li>
  <li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1495621" class="">converted the <code class="highlighter-rouge">wizard</code> binding to a Custom Element</a>
 using Shadow DOM. In the process of these conversions he’s been finding
 some web-exposed Shadow DOM focus bugs that have been getting fixed.</li>
  <li class="">Andrew Swan <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1555060" class="">converted <code class="highlighter-rouge">tabs</code> and <code class="highlighter-rouge">tabbrowser-tabs</code> to Custom Elements</a>. <code class="highlighter-rouge">tabbrowser-tabs</code>
 was one of the biggest and most complex bindings remaining. I expect 
that moving it into JS will open up opportunities for simplifications, 
similar to what we saw with the <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1392352" class=""><code class="highlighter-rouge">tabbrowser</code> binding</a>.</li>
  <li class="">Robert Strong <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1515484" class="">removed the <code class="highlighter-rouge">updateheader</code> binding</a> by <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1521628" class="">removing the last consumers of the old update UI</a> and replacing them with the newer and more well-tested UI.</li>
</ul><div class=""><br class=""></div></div></body></html>