There's this hack where we make Ctrl+Tab previews use the button-base binding instead of the standard button one in order to skip button.css. Now that button.css is loaded as a document stylesheet, this stopped working.

Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/06a2943bfa3f Fix Ctrl+Tab preview styling. r=bgrins

Thanks for removing this special binding! As noted in bug 1450823, when converting "button" to Custom Element, we'll probably need a subclass like <button is="button-plain"> that doesn't create any anonymous content. As I understand it, we have this behavior here because, in XBL, children that don't match any "children" element override the entire <content>.

(In reply to :Paolo Amadini from comment #5) > Thanks for removing this special binding! As noted in bug 1450823, when > converting "button" to Custom Element, we'll probably need a subclass like > <button is="button-plain"> that doesn't create any anonymous content. As I > understand it, we have this behavior here because, in XBL, children that > don't match any "children" element override the entire <content>. Can't the custom element check if there are child nodes and not create the anonymous content in that case?

If we end up using a delayed connected callback for "button" then that would be possible, otherwise if I remember correctly we don't have access to children when the element is connected during parsing, even if they are defined. Also, just checking whether there are children may slow down the creation, and if it's only one or two consumers who need this, it's probably more performant to have a separate subclass. Brian would probably know more, anyways we don't have to worry about this until we tackle the button binding.