On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij <emond.papega...@gmail.com> wrote:
> > On Tue, Feb 25, 2020 at 10:54 PM Sven Meier <s...@meiers.net> wrote: > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > > > I agree that for this one Wicket can just add the CSS class (e.g. > > wicket-feedback-indicator) on the HTML element and let the application > > provide the CSS rules for it > > I'm ok with that. I only added that styling to be compatible with the > old behavior, which was broken in my opinion anyway. > As long as the default behavior is specified in the Wicket core css file, I'm for it. .wicket--color-red is godawful so +1 for making it meaningful. IMO this means that we should move the styling of e.g. the feedback panel [1] into the wicket-- fold. However, that is not something that is related to CSP, so CSP should not be the driver (nor wait) for that. > > An idea: > > if CSP is disabled then Wicket can deliver the content of wicket-core.css > > as inline CSS, i.e. <style>....</style>. > > This will keep the number of http requests the same as before. > > This already is an option now and doesn't depend on CSP being enabled > or not. As long as the style element is rendered with a nonce, it will > work. We can make the header contribution a bit more flexible with the > following options: > * inline wicket-core.css (or another stylesheet) > * resource reference to wicket-core.css (or another stylesheet) > * no core stylesheet at all > AFAIR the extra request is normally not a problem as browsers multiplex that on the HTTP/2 connection to the server, and the CSS is easily cached. It might actually be a worse experience to inline the style than having it as a separate resource. Martijn [1] https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html
