Noissue - In the devtools panel, preserve space for missing document domain

devtools-panel.html

Index: devtools-panel.html
===================================================================
--- a/devtools-panel.html
+++ b/devtools-panel.html
@@ -88,7 +88,7 @@
         <td>
           <div class="request-wrapper">
             <a class="resource-link" href="" target="_blank">&nbsp;</a>
-            <div class="domain"></div>
+            <div class="domain">&nbsp;</div>

[Thomas Greiner, 2018/04/03 12:39:43]

This issue is purely cosmetical so, instead of not allowing this element to be
empty, why not make sure that neither of the rows here collapses if it's empty?
That way we won't have to worry about what's inside those rows.

For instance, using CSS this could be achieved with `min-height: 1em`.

[Sebastian Noack, 2018/04/03 23:21:56]

Well, this is how we already avoid other elements with optional content (see
"resource-link", "filter" and "origin") from collapsing. I didn't intend to do a
major refactoring here, but merely made the behavior consistent.
While I agree that inserting dummy data (i.e. &nbsp) to influence the visual
representation is a hack (and against semantic markup practices), I couldn't
come up with a better way back then when I implemented the devtools panel.
(Redundantly) hard-coding the (min-)height is hardly any less of a hack.

[Thomas Greiner, 2018/04/04 12:34:01]

Sure, we should avoid any major refactoring. So if you think the suggested
change is out of scope for fixing this issue and if you want to make it
consistent, feel free to make two separate commits.
It's great that we're revisiting code to iterate on it. In this case I don't see
how defining how elements should look like in CSS is a hack. For instance, I'd
also consider it reasonable to set the anchor tag above to `display: block` to
ensure that it occupies the entire width of its parent. So the former defines
the link's height and the latter defines its width.

[Sebastian Noack, 2018/04/05 00:36:10]

It's a hack to superfluously define a height on the element. This seems much
more error-prone than the approach with the  . Currently, the element's
height is defined by the font-size/line-height of its content. If we now
explicitly define a height for the element itself and later change the size of
the content, we have to remember updating the height of the container as well,
otherwise the layout is off.

           </div>
         </td>
         <td>