Hello Sven, I always thought:having override like this will require re-testing all 3rd-party components manually (I don't have that much time) So I'm using library as-is and override as minimum as possible :)
On Tue, 17 Mar 2020 at 18:56, Sven Meier <s...@meiers.net> wrote: > > Hi Maxim, > > what is difficult about that? > > Actually it is recommended to have it in your normalize.css (formerly > reset.css). > > Here one without !important: > > https://github.com/necolas/normalize.css/blob/master/normalize.css > > Sven > > > On 13.03.20 15:21, Maxim Solodovnik wrote: > > Additional note: > > > > Bootstrap has following CSS > > > > [hidden] { > > display: none !important; > > } > > > > which makes life much more diffiicult ... > > > > On Fri, 13 Mar 2020 at 21:17, Martin Grigorov <mgrigo...@apache.org> wrote: > >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mgrigo...@apache.org> > >> wrote: > >> > >>> Hi Sven, > >>> > >>> <html> > >>> > >>> <head> > >>> <style> > >>> /* rule from the application that should be used when the > >>> element is visible */ > >>> div { > >>> display: flex; > >>> margin-bottom: 200px; > >>> } > >>> > >>> /* Rule coming from wicket-core.css */ > >>> .wicket--hidden { > >>> display: none; > >>> } > >>> > >>> </style> > >>> </head> > >>> > >>> <body> > >>> <p> > >>> Element when visible: <br/> > >>> A1 <div id="blah1.1" >B1</div> C1 <span>D1</span> > >>> <br/> > >>> </p> > >>> <p> > >>> Element when hidden (there is no B1 because Wicket renders > >>> just the tag, without any children): <br/> > >>> A2 <div id="blah1.2" hidden></div> C2 <span>D2</span> > >>> <br/> > >>> <small><strong>C2 & D2</strong> are still 200px down > >>> because 'hidden' is not like 'display: none'! > >>> The application developer will have to do something more for > >>> the placeholder case to hide it.</small> > >>> </p> > >>> > >>> <p> > >>> Element with wicket--hidden class<br/> > >>> A3 <div id="blah3" class="wicket--hidden">B3</div> C3 > >>> <span>D3</span> > >>> <br/> > >>> <small><strong>C3 & D3</strong> are not 200px down > >>> because > >>> of 'display: none'! > >>> The application developer has nothing to do!</small> > >>> </p> > >>> </body> > >>> > >>> </html> > >>> > >>> It shows two things: > >>> > >>> 1) since Wicket placeholder tags do not have children elements [1] there > >>> is not really a need to use 'hidden' or 'display: none' > >>> > >> As I explained below we do need to use display: none. > >> I've forgot to update this line. > >> > >> > >>> 2) if we really want to hide the element without leaving extra work for > >>> web designers then we have to use display: none > >>> > >>> > >>> 1. > >>> https://github.com/apache/wicket/blob/10d10a92dda2e5834508f52d7807fe361f20fbea/wicket-core/src/main/java/org/apache/wicket/Component.java#L2370 > >>> > >>> > >>> > >>> On Thu, Mar 12, 2020 at 4:35 PM Sven Meier <s...@meiers.net> wrote: > >>> > >>>> Hi all, > >>>> > >>>> I've looked at all responses and most arguments in favor of a "core.css" > >>>> boil down to: > >>>> > >>>> > `hidden` attribute doesn't work (even `display: flex` breaks it) > >>>> > >>>> > Using the hidden attribute puts the responsibility with the developer > >>>> > where this should be on the framework. The hidden attribute just > >>>> doesn't work. > >>>> > >>>> > When something as simple as using flex or display:block on a div > >>>> breaks > >>>> > the hidden attribute [1] we should not depend on it working. > >>>> > >>>> Sorry, but I don't share that assessment: 'hidden' works just fine! > >>>> Every browser supports it and it has a strong semantic meaning we can > >>>> utilize. > >>>> > >>>> If you (or your web designer) decides to style hidden elements as > >>>> floating, static, flex, pink or with marquee ... feel free to do so. > >>>> > >>> No. The web designer styles the element when it is supposed to be visible. > >>> But then when some condition is met Wicket may render it as a placeholder > >>> for Ajax requests and then this element will be rendered. > >>> It does not have text content but the CSS rules will be still applied and > >>> the web designer will have to add more rules for the cases when 'hidden' > >>> is > >>> there. > >>> Most probably something like: > >>> div[hidden] { > >>> display:none; > >>> } > >>> > >>> > >>>> Wicket doesn't need to ship a CSS file to fix anything here. > >>>> Note that the way we are hiding components in Wicket never exposes any > >>>> sensible information anyways. This topic is just about layout and > >>>> styling and that is completely in the responsibility of your developer > >>>> ... and works out-of-the-box if you don't break it! > >>>> > >>> What about the cases when the children need to be invisible ? > >>> .wicket--hidden-fields > >>> > >>> > >>>> >Wicket ... has been dependent on its own styles, spread out through > >>>> our code in odd ways > >>>> > I consider not having a wicket stylesheet file a bug, not a feature > >>>> > >>>> I couldn't disagree more. These "odd ways" is one of many cool features > >>>> of Wicket named "components". BTW we Wicket devs have never been very > >>>> successful in crafting CSS anyways, we shouldn't start with this now :P. > >>>> > >>> We don't really start. > >>> We do not mandate styling. We just hide whatever is supposed to be hidden. > >>> Nothing more. > >>> > >>> As agreed (?!) earlier .wicket--color-red should be just a marker CSS > >>> class. The content should be provided by the application. Just like > >>> FeedbackPanel's CSS classes. I will remove it now! > >>> > >>> > >>>> I'll start a vote soon. > >>>> > >>>> Sidenote : This doesn't mean I'm against the CSP feature in general! > >>>> After some iterations we arrived at a very cool solution (with some > >>>> minor detail questions remaining). > >>>> > >>>> Have fun > >>>> Sven > >>>> > >>>> On 27.02.20 22:18, Emond Papegaaij wrote: > >>>>> Hi Andrew, > >>>>> > >>>>> I thought of this solution as well and it will work. The major > >>>>> advantage is that the styling is only added when it is actually used. > >>>>> But it requires significantly more work to build and is a lot more > >>>>> complex than the current solution. For this, we need some place to > >>>>> accumulate element styling, like we do for JS event handlers. This > >>>>> then needs to be rendered in the response. > >>>>> > >>>>> The most complex part is ajax updates. These might change some of the > >>>>> styling. Simply replacing the style element will not work, because in > >>>>> an ajax request only the added components are rendered. Rendering a > >>>>> style element per component will work, but is far from ideal. This is > >>>>> why I went for the easy solution. > >>>>> > >>>>> Emond > >>>>> > >>>>> On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev <and...@kondratev.pro> > >>>> wrote: > >>>>>> Just as a brainstorm. Not sure if it's a good idea. > >>>>>> > >>>>>> Wicket potentially can add nounced style to the document with hidden > >>>>>> elements hidden by id. > >>>>>> > >>>>>> Imagine generated HTML has components like these > >>>>>> <div class="wupb-container"> > >>>>>> <div class="wupb-progressBar" id="ida"><div > >>>>>> class="wupb-border"><div class="wupb-background"><div > >>>>>> class="wupb-foreground"></div></div></div></div> > >>>>>> <div class="wupb-uploadStatus" id="id9"></div> > >>>>>> </div> > >>>>>> > >>>>>> #ida and #id9 must be hidden, so in the page header we add something > >>>> like > >>>>>> this > >>>>>> > >>>>>> <style nonce="abracadabra"> > >>>>>> #ida, #id9 {display: none;} > >>>>>> </style> > >>>>>> > >>>>>> Even if the wupb-progressBar has display: flex, the #ida will win. > >>>> Will > >>>>>> win even over #id8 .wupb-progressBar {display: fles} > >>>>>> > >>>>>> !important can potentially be added. > >>>>>> > >>>>>> > >>>>>> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro < > >>>> reier...@gmail.com > >>>>>>> : > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene < > >>>> an.delb...@gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro < > >>>>>>>> reier...@gmail.com> wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Right now I have no enough knowledge to vote in this feature. One > >>>>>>> thing I > >>>>>>>>> didn't like, and I already mentioned it before, is some of us were > >>>>>>>> waiting > >>>>>>>>> for 9.x to be released some time ago (at least a few months ago I > >>>> was > >>>>>>>>> preparing some branch of our application and ported it to 9.x, after > >>>>>>>> asking > >>>>>>>>> about release plans) and all of the sudden this feature is > >>>> introduced > >>>>>>> and > >>>>>>>>> all sub-frameworks depending on Wicket will have to be adapted. > >>>>>>>> In which way sub-frameworks should be affected? I mean, as far as I > >>>>>>>> understand it, if we disable CSP blocking configuration everything > >>>> should > >>>>>>>> work "the old way", and that's why I would prefer to keep CSP > >>>> disabled by > >>>>>>>> default. > >>>>>>>> > >>>>>>> Well if something is supported at core level then if associated > >>>> projects > >>>>>>> want to comply with this new feature, which might be ideal, then > >>>> they will > >>>>>>> have to be adapted (or not?). I'm not talking about not releasing the > >>>> new > >>>>>>> feature. I'm talking about not releasing as part of 9.x, as it was > >>>> said to > >>>>>>> be almost ready for release a few months ago, and deffer it to 10.x > >>>> (and > >>>>>>> try to release it soon). > >>>>>>> > >>>>>>> -- > >>>>>>> Regards - Ernesto Reinaldo Barreiro > >>>>>>> > > > > -- WBR Maxim aka solomax
