How to resolve Bootstrap and Clarity styling conflicts when using forms - css

I'm using Clarity and Bootstrap together in an Angular project, but styling conflicts seem to be popping up, as the styling is not working as intended.
I've tried changing the CSS around in Chrome devtools. I noticed that reboot.scss might be causing some of the problems, but I don't know what to do about that if it is.
Here's the component code.
<h3>New Post</h3>
<form #productEditorForm="ngForm" clrForm>
<clr-select-container>
<label>Location</label>
<select clrSelect name="Location" [(ngModel)]="LocationID">
<option *ngFor="let location of Locations" [value]="location.ID">{{ location.Name }}</option>
</select>
</clr-select-container>
<clr-input-container>
<label>Images</label>
<input clrInput #files type="file"/>
</clr-input-container>
<button class="btn btn-primary" type="submit">Post</button>
</form>
The expected appearance of the selectbox is like the examples found here. The expected appearance for the button is like the primary button found here; the font size of the buttons is supposed to be .5rem, but the actual size is 1. The intended default font is Metropolis, but the actual font is Segoe UI. The page isn't supposed to have flickering scrollbars and jittery contents, but the actual page does. Where do I go from here?

There are many Angular carousel implementations (this one is built upon Bootstrap but is able to be used in an isolated way https://ng-bootstrap.github.io/#/getting-started) and they would be able to provide the necessary functionality.
If you do load Bootstrap, you would want to load it before Clarity so Clarity has the final say on the styling.

Related

Is there a proper way to wire up Trix editor with Livewire?

When wiring together Trix editor content with Livewire, I am stumbling into problems. I believe that the issue is that when Livewire receives content from Trix, the content is swapped out and Trix becomes disabled. Is there a better way?
What I have done, that works, is as follows. At the moment, the page is the redirected to itself in order to reboot Trix (defeating the whole point of Livewire, but it's being used for other things too).
<div>
<input
id="newCommentTextTrixContent"
type="hidden"
wire:model="newCommentText"
>
<trix-editor
id="newCommentTextTrixEditor"
input="newCommentTextTrixContent"
></trix-editor>
<button wire:click="addComment(document.getElementById('newCommentTextTrixEditor').innerHTML)">Add Comment</button>
</div>
I have tried
wire:model on the hidden input -- nothing happens
x-on:trix-change="$set('comment', $event.target.innerHTML) -- this works, but Trix goes grey and ceases to work after the first keypress (reboot problem?)
I'm sure something like the latter is better, but with Trix somehow being rebooted each time. It all seems a bit messy - so the question is, what's the right way to do this?
I got it working. With up to date Livewire and Alpine installations, the code is roughly as follows.
<div wire:ignore>
<trix-editor
class="formatted-content"
x-data
x-on:trix-change="$dispatch('input', event.target.value)"
x-ref="trix"
wire:model.debounce.60s="newCommentText"
wire:key="uniqueKey"
></trix-editor>
</div>
Why does this work?
You need wire:ignore on the parent node, because Trix inserts the toolbar above the text area. wire:ignore stops Livewire from worrying about it and therefore not removing it or messing with it on the next cycle.
You need a wire:key because the DOM moves around a bit, and this helps Livewire to keep track of it.
I propose the long debounce, which is a hack as the .lazy modifier doesn't work well with text. Also, waiting for Ajax on each key press is painful.
The alpine event ensures that Trix events (like bold, italics etc) are still fired
That's it. I use this above to repetitively submit comments onto the end of a comment stream, and everything seems to work fine. Good luck!
Note, I also have CKEditor working similarly, as described here.
As an extension on #Kurucu 's answer, and the comment under it from #Rehan;
This seems to work very well. But when I apply styles like li or bold
it doesnt retain in the wire:model. Ex:
<div>foo<br>bar<br>foobar</div> I applied the Bullets here the tags
are missing. Did you face this issue? – Rehan
To fix the issue of not having an updated value when pressing buttons bold, italic, or quote for example, add the following part to the trix editor (note the x-on:trix-change="$dispatch('input', event.target.value)"):
<div wire:ignore>
<trix-editor
class="formatted-content"
x-data
x-on:trix-change="$dispatch('input', event.target.value)"
wire:model.debounce.1000ms="newCommentText"
wire:key="uniqueKey"
></trix-editor>
</div>
The above option works but wasn't getting the data back from my field, Here's what worked for me with a little tweak using AlpineJS's #entangle.
Below is my working solution:
<div class="mb-2" x-data="{ description: #entangle('description').defer }"
x-init="$watch('description', function (value) {
$refs.trix.editor.loadHTML(value)
var length = $refs.trix.editor.getDocument().toString().length
$refs.trix.editor.setSelectedRange(length - 1)
}
)" wire:ignore>
<label class="form-label">Job Description <span class="text-danger">*</span></label>
#error('description')
<span class="error d-inline-block"><i class="mdi mdi-alert-circle"> </i> {{$message}}</span>
#enderror
<input name="description" id="description" type="hidden" x-model="description">
<div x-on:trix-change.debounce.1000ms="description = $refs.trix.value">
<trix-editor x-ref="trix" input="description" class="overflow-y-scroll"
style="height: 20rem;"></trix-editor>
</div>
</div>
I got it to work by using Trix's built-in events.
<input id="about" name="about" type="hidden" value="{{ $about }}">
<trix-editor input="about" class="wysiwyg-content"></trix-editor>
<script>
var about = document.getElementById("about")
addEventListener("trix-change", function(event) {
console.log(about.getAttribute('value'));
#this.set('about', about.getAttribute('value'))
})
</script>

Why do bootstrap form select controls look a bit weird?

The code needed is very simple as shown by w3schools:
https://www.w3schools.com/bootstrap/tryit.asp?filename=trybs_form_select&stacked=h
Just add a label and a class of "form-control"
<div class="form-group">
<label for="sel1">Select list:</label>
<select class="form-control" id="sel1">
<option>1</option>
<option>2</option>
<option>3</option>
<option>4</option>
</select>
</div>
But the result is inconsistent; some borders are black, and some are transparent. It looks weird to me. Is my sense of style just off?
Checking out bootstrap docs it looks like the correct way to do it. Is it supposed to look like that?
I tried for example to add a class and style it:
<div class="form-group">
<label for="sel1">Select list:</label>
<select class="form-control dropdown" id="sel1">
<option>1</option>
<option>2</option>
<option>3</option>
<option>4</option>
</select>
</div>
CSS:
.dropdown {
border: transparent !important
}
No effect. What do you think?
Thanks in advance
You've hit a very interesting feature of the internet -- native form controls.
The border that you are encountering is the system styling of what appears to be internet explorer / edges rendering system. This can't necessarily be styled with CSS.
You could recreate the dropdown using CSS / JavaScript, but you would lose a lot of the functionality that inherently comes with that specific control.
For example, when you are on a mobile device the select / option control sometimes becomes a spin wheel / rolodex at the bottom of your view port. You also lose the keyboard / autocomplete functionality when users try to select an item via a keyboard ( I live in Minnesota, when presented with a state dropdown I type M -> selects Maine, I -> Selects (Mi)nnesota.
When developers rebuild this type of control with autocomplete functionality what tends to happen is I type M -> Maine, I -> Idaho.
Ultimately what you choose to do is up to you, but to eliminate some of the border weirdness could actually cause a user experience that is less robust than just letting it be.
As an aside most browsers implement select / option controls differently. See three different browsers below:

Angular UI-Grid Awesome Bootstrap Checkboxes not functioning properly

I am working on adding custom CSS styling for my checkboxes via Awesome Bootstrap Checkboxes and have them actually showing up in the grids with them initially being checked or unchecked properly via JSON data being read...
the issue is when I go to change the value. The values are updating properly from when shown to when hidden.
However, instead of just the checkmark disappearing in the checkbox, the entire checkbox disappears and the only way for me to get it back is to change the value of the back to ui-grid-cell-focus manually through F12 debugger in the browser.
It appears something is not set up right with them, but I haven't been able to pinpoint exactly what he issue is yet...any help would be appreciated.
Cell Template:
cellTemplate:
`<!-- .blueCheckbox --> <div class="checkbox checkbox-primary"> <input type="checkbox" class="ng-scope" value="true" name="select_item" ng-model="row.entity.Name" /> <label></label> </div> <!-- end .blueCheckbox -->,`
Got them working...Had to enable the checkboxes and move them underneath the overlay and they worked fine...weird because its totally different from how it normally works...

align submit and cancel button with bootstrap

I am using bootstrap 2.0 within my rails app (using the bootstrap-sass gem) and am having trouble getting a submit button aligned with a cancel button.
Here's the code snippet from the form in the html.erb file:
<div class="span3">
<%= f.submit class: "btn btn-primary" %>
<button type="button" class="btn">Cancel</button>
</div>
Here's the HTML it produces:
<input class="btn btn-primary" type="submit" value="Add Person" name="commit">
<button class="btn" type="button">Cancel</button>
And here's what it looks like in firefox 14.0.1. When I look at the
Note: Adding input-append to the div gets me close (see pic below) but is still off a bit--note that cancel is still a bit lower and that the rounded corners on the right side of the add person button are cut off.
How can I get these two buttons to align properly?
Update
I am using Firefox 14.0.1. When I look at the jsfiddle created by #Vestride to duplicate this problem here's what I see:
I am happy with the first result, but when I add the exact same code to my site, I don't get the same result. Instead I get the messed up alignment above. I wonder what this means? Maybe that my CSS for bootstrap is messed up?
Update 7/27
In response to Vestride's latest suggestion, here are the buttons as they show in my Firefox from the fiddle Vestride put together. Note, there's no improvement with changing from input to submit.
I made a jsfiddle http://jsfiddle.net/Vestride/YT3sq but was unable to duplicate your problem. They align perfectly for me (Chrome 21). What browser are you using? In the second example I added a btn-group class to the container element. That might also solve your problem.
Edit:
Try making your <input /> a <button type="submit">. Worked in Firefox for me. I updated the fiddle too.
I know it's an old issue, but using Bootstrap 4 I had the same problem. What solved it for me is adding margin-bottom: 0 or mb-0 class using bootstrap classes on the submit button.

Bootstrap buttons in Firefox on localhost?

I've got an ASP.NET 4 app being developed and tested against http:// localhost/mysite - I spent a while looking into a problem with Twitter Bootstrap buttons in Firefox (v12.0) where they looked weird.
However I noted that, when testing, if I swapped the URL and changed 'localhost' for my machine's FQDN (e.g. http://mymachine.mydomain.com/mysite) then it worked normally and as expected.
This is kinda good news because it means that there isn't a "bug" as such that I have to fix but I'm curious about why it's happened in the first place.
The weird behaviour is as follows:
The 'button' is marked up as follows (in this case, a <a> to look like a button):
<p><a class="btn btn-success" href="checkout.aspx"><i class="icon-shopping-cart icon-white"></i> Checkout</a></p>
I also have the same behaviour when using a 'real' button, marked up as follows:
<p><input type="submit" name="ctl00$cphMainContent$btnProceedToCustomerDetails" value="Next: Your details" onclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$cphMainContent$btnProceedToCustomerDetails", "", true, "", "", false, false))" id="cphMainContent_btnProceedToCustomerDetails" class="btn btn-primary" /></p>
In both cases, the buttons render in a grey, unreadable state and then sort of 'fill up' in green colour when you hover over, until it is about 75% filled up and then stops filling up.
Here's some images
The <a class="btn btn-success">
On load (before mouseover)
When you put your mouse over it, it fills up with colour from the bottom up in about 0.5 seconds, finishing up looking like this:
The <input type="submit" class="btn btn-primary">
On load (before mouseover)
After mouseover, again it fills up with colour from bottom up, in about 0.5 seconds, and looks like this:
Like I say, this only happens when using Firefox, and only when looking at localhost. Other browsers are fine. I am using a freshly downloaded copy of bootstrap.js (downloaded today) with no amendments, I only include one other css file, and even when I don't include it, it's the same behaviour.
I ran into this problem earlier today. This link: twitter bootstrap button changes rendering oddly in firefox and chrome helped me.
In my css, I applied the following:
.btn-primary, .btn-danger, .btn-success { background-image: none; filter: none;}
It worked. My pages now render correctly in firefox. Chrome worked fine for me.
After lots of efforts, I was finally able to pin down this issue to a specific CSS-Hack in Twitter Bootstrap.
Removing * (asterisk) from *background-image of btn-primary and other similar classes resolves this issue.
But the problem itself is not in the CSS. It has got to do with the implementation.
For example, I was using AjaxMin to minify and combine CSS and since *property is not a valid CSS, Ajaxmin was ignoring it rendering the final CSS without those properties. Buggy button effects being one such side-effect.

Resources