Let's try to remove this CSS and check :) I'm currently using latest wicket SNAPSHOT at master so most probably will provide some feedback :)
On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mgrigo...@apache.org> wrote: > > 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 > > >>>>>>>>>>> > > >>> > > -- WBR Maxim aka solomax
