Hi Sven, What about wicket--hidden-fields ? We still need wicket-core.css for it.
Martin On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <s...@meiers.net> wrote: > Hi all, > > I've built an example to better demonstrate my argument: > > a) "hidden" tags work fine out-of-the-box :) > > https://jsfiddle.net/p8s7Lrk2/1/ > > b) changing display of tags changes "hidden" tags too :( > > https://jsfiddle.net/p8s7Lrk2/2/ > > c) and a simple fix for "hidden" tags - no !important required ... 8) > > https://jsfiddle.net/p8s7Lrk2/3/ > > In my opinion there's no need to invent "wicket--hidden" when "hidden" > works already as expected/needed (a). > And furthermore Wicket does not need to provide a fix (c) for something > the web designer screwed up (b) in the first place. > > Have fun > Sven > > > On 17.03.20 13:01, Maxim Solodovnik wrote: > > 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 > >>>>>>>>> > >>> > > > > >
