You can see what becomes of q-layout in chrome inspector.
Screen Shot 2020-11-09 at 16.19.17.png
If you use q-layout (you are using Quasar) you will have to put elements inside it which are compatible with q-layout. It only make sense that way.
As you found out a single un-styled div isn’t compatible. While it isn’t impossible to make it compatible … you will likely going to rebuild q-headerin the process. And this extra work you are doing for what ?
So the options are
a, Style your custom component so it is compatible with q-layout.
b, Create your own layout and not use q-layout. I think you will miss out on a lot. q-drawer to start with. Unless of course you make your layout compatible with q-drawer.
c, the best IMO is to use q-layout with the already provided compatible elements after all why reinvent the wheel.
Hi dgk. Thanks for the input and feedback. If I may ask, would you be interested in creating an RFC for your thoughts to improve Quasar in terms of Design/ Styling/ Theming for v2.0? Don’t keep yourself reduced to this situation, but go “hog wild” in imagining a new way of designing with Quasar.
This is just me, but my wish would be that components aren’t styled in any one way to begin with. But rather, they are first “styleless”. Then, there would be a “core Design” that can be added to your app (i.e. Material, Bootstrap, Tailwind, etc.). Then there would be a “Theme” choice or even set of choices that can be added. But, that is just me and my ideas. I’m not a designer. 😁
We can continue this discussion here, if you’d like. I guess bottom line is, this suggestion more than likely won’t be done. But, for v2.0, we can make designing in Quasar even better.
Ok, so … if we could make WebPack build the two themes as two separate css bundles, we could load these after platform detection ?
I tried to do this (separating the css file from the main bundle), as we like our customers design requests separate from the main logic, but at the moment we let the http server do the mapping of these files.