In this case I am fine to go with 'hidden'. We can introduce wicket-core.css later if needed.
On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <s...@meiers.net> wrote: > Hi Martin, > > these stylings? > > width: 0px; > height: 0px; > position: absolute; > left: -100px; > top: -100px; > overflow: hidden; > > They are a 10-year old workaround > > > https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97 > > ... for a problem that no longer exists: > > > https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element > > A simple "display:none"/"hidden" is sufficient. > > Sven > > > On 20.03.20 10:29, Martin Grigorov wrote: > > 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 > >>>>>>>>>>> > >>> >
