Thanks for this PR, @NiedziolkaMichal ! I don't have time to review now, but:

2. They don't work on firefox. It looks like latest version of firefox has an issue, with @counter-style and possibly other at-rules, be not operational, while being placed in shadow-root.

I remembered this after our conversation: #887 . Maybe the same thing?

Yes, it looks to be the same issue, although @font-face doesn't work on both firefox & chrome, while @counter-style works fine on chromium based browsers. Is there any way to make it work?

I don't know, @NiedziolkaMichal , sorry, @schalkneethling , do you have any ideas about this? I'm afraid that this is quite likely a blocker for this idea.

There is more information here:

• [css-counter-styles] Clarify how @counter-style name lookup works with shadow DOM w3c/csswg-drafts#5693
• https://bugzilla.mozilla.org/show_bug.cgi?id=1672302
• https://wiki.csswg.org/spec/css-scoping

@NiedziolkaMichal thank you for your continued contributions. I believe your recent pull request on mdn/bob will address the issues mentioned here? If so, let’s keep this one around until that one is merged. Thanks!

@schalkneethling No, this PR will still not work on Firefox, because output is presented in shadow tree. Recently I have been prototyping on replacing shadow DOM with iframe in HTML interactive examples. It would make it possible to use all at-rules and WebAPI examples, without much effort. Is there any important reason why you have chosen shadow dom instead?

Is there any important reason why you have chosen shadow dom instead?

I honestly cannot remember :) I believe it could have been because we were, and still are, considering moving interactive examples into content without it being hosted in an iframe at all. We needed to prevent styling and Javascript "leaking" into the rest of the page.

@schalkneethling Making HTML examples be operational without either iframe or shadow DOM would be tricky. There are plenty of examples, like p, using selectors that would affect rest of the layout.

@schalkneethling Making HTML examples be operational without either iframe or shadow DOM would be tricky. There are plenty of examples, like p, using selectors that would affect rest of the layout.

Yes, and so the hope/intent was that shadowDOM would shield us from this problem.

There are I think 2 levels here:

• the complete example, including the UI, code editors, and output
• the output pane

At the moment the complete example is in an iframe, of course, and the output pane is in shadow DOM to stop it leaking into the editor UI. So even if the complete example was "inline" in the page, we'd need to isolate the output.

Recently I have been prototyping on replacing shadow DOM with iframe in HTML interactive examples.

That's interesting! So we'd have an iframe inside an iframe? I might have mentioned this a few thousand times before, but I'd love to have Web API interactive examples on MDN.

@schalkneethling No, this PR will still not work on Firefox, because output is presented in shadow tree. Recently I have been prototyping on replacing shadow DOM with iframe in HTML interactive examples. It would make it possible to use all at-rules and WebAPI examples, without much effort. Is there any important reason why you have chosen shadow dom instead?

Hey, @NiedziolkaMichal , I have been trying to write this whole thing up and found this: #706 which is where we decided to use shadow DOM. It was also suggested there that an extra iframe could be a solution.

Just in case this bit of history could help :).

@wbamberg In the iframe PR, I believe that those issues don't exist. Applied CSS rules, don't select anything other than output. Clicking on links opens new browser tab. My solution also don't generate two separate documents, output exists only in memory and is applied via srcdoc attribute. On my device, I also didn't notice any performance issues.

@wbamberg In the iframe PR, I believe that those issues don't exist. Applied CSS rules, don't select anything other than output. Clicking on links opens new browser tab. My solution also don't generate two separate documents, output exists only in memory and is applied via srcdoc attribute. On my device, I also didn't notice any performance issues.

Thanks for checking! It's great that your solution doesn't suffer from the possible problems discussed there.

My suggestions include adding white space, using double quotes

The formatter doesn't seem to like this, so I've added in f4c78a4 to make things green, I hope that's okay.

Thanks everyone for the work! Merging shortly 🚢