1. Is Bootstrap 4 officially supported for Kendo UI for JQuery? If not, is there an official page where I can track if/when it will be supported?
2. If it is supported, is there a guide on what files (CSS/JS) need to be included in order to upgrade to Bootstrap 4?
8 Answers, 1 is accepted
Is Bootstrap 4 officially supported for KendoUI for jQuery?
Technically speaking, those are two separate and independent frameworks and there isn't any cross-framework support. That being said, we've ensure compatibility with Bootstrap 4 in terms of appearance. More specifically, we have a sass-based theme called Bootstrap-v4 that reuses the variables used in Bootstrap 4 (which is also based on sass). In other words if you have a custom variable file that can customize Bootstrap, it will also customize Bootstrap-v4 theme, to an extent that is.
How to include Bootstrap v4 theme / How to upgrade to Bootstrap 4?
* To include Bootstrap-v4 theme, you need only a single file (that's an advantage over less-based themes, which needed two files) -- kendo.bootstrap-v4.css or kendo.bootstrap-4v.min.css
* To use Bootstrap 4 you need to include it like you would.
I've created a very simple dojo -- https://dojo.telerik.com/@joneff/AjeBeXAH -- that shows Bootstrap buttons and textboxes, as well as KendoUI Bootstrap v4 theme counterparts. The only difference is in the shade of default (secondary) buttons. We've opted for a lighter shade of gray.
I feel like I'm missing something here. I upgraded from bootstrap 3-4 and have noticed some strange behavior with the dialog widgets. See the attachment but basically the boostrapp style classes are not allowing the dialog to expand to it's contents.
I took modified your original dojo
and created one of my own to replicate this issue in the dojo.
I also tried experimented in the dojo with and without the styles in the documentation it says to include at this link:
Are there additional styles that need to be incorporated for bootstrap 4?
CSS is very contextual to markup. Without your previous markup that worked, I cannot really say what was happening and why. I modified your example slightly, because you were missing the "container-fluid" or "container" class. which helped a bit with the layout, but still not as before. Do you think you can provide a dojo with the previous setup?
Modified example: https://dojo.telerik.com/@joneff/ikImELuh.
I tried importing bootstrap 3 into the dojo but was not able to replicate. I saw something about how behaviors may differ in an iframe which the dojo uses.. This really needs to be supported though. I can't rely on setting a minimum content width to force the form group's label and input onto the same line. It says in the telerik documentation:
Please see this latest dojo: https://dojo.telerik.com/UtuxemEb
Test 3 in this one has the label contents expand the width of the dialog. There are no col-md-2/col-md-10 on this dialog.
Test 2 has the dialog but with a much larger label text and the dialog also is expanded.
Test 1 (the original) has the smaller dialog. I would expect that the dialog would behave like the 2nd one and expand to allow the text of the label to fit on one line rather than compacting the dialog size so that a wrapped label text is forced. I cannot figure out why this is happening though but it seems to have to do with the col-md-(x) classes.
I ran the tests with and without the additional styles to reset the box sizing.
It says in the documetation:
If the Dialog contains horizontally expandable block-level elements—including Kendo UI widgets such as the Grid, Editor, and others—the widget can expand horizontally to the point of touching the right edge of the browser viewport.
I've updated the dojo again -- https://dojo.telerik.com/@joneff/enONUFuc. In this example, I've added another dialog with some text in it. As you can see, it stretches almost to the edge of the preview (max width is set to 98% of viewport width, but if you remove the commented css rule it will be 100% of viewport).
Then I've modified the rest of the examples to include container-fluid instead of container. There is a subtle difference, but the main takeaway is that container-fluid has now explicit max-width, where as container has, depending on the resolutions..
Even without the max-width, it's the browser that decides how wide the content should be. You can also uncomment the rule and see how the examples behave. At the end it's the browser that decides how to render the content and how wide it should be when there is no explicit width set.