Thanks for the comprehensive reply, Nate.
In hindsight, I apologise for the tirade I unleashed; it was at the end of a very long day, during a very long-winded and overdue project. Rather than subject you to another stream-of-consciousness style battering, if I could ask for your patience while I formulate a response so I can come up with some reasonable suggestions, I would be very grateful
Cheers.
In hindsight, I apologise for the tirade I unleashed; it was at the end of a very long day, during a very long-winded and overdue project. Rather than subject you to another stream-of-consciousness style battering, if I could ask for your patience while I formulate a response so I can come up with some reasonable suggestions, I would be very grateful
Cheers.
Hi Chad,
Thanks a ton for your feedback. Stuff like that is incredibly helpful
A couple of quick responses:
1. Currently, we only place the .aui class on the HTML, so it shouldn't show up on the body, unless you add it there.
But also, the generic styling like .aui li {} is happening because we're wrapping all of Bootstrap, including it's use of normalize.css. The idea there was that all of the styling, including any resets, would be able to be completely removed by removing that CSS class.
So there are a couple of approaches you could take to handling this:
- From the theme, you have full control of the aui.css file, so you could copy it from _styled, and place it in your _diffs/css/ directory.
What you could do in this case is change the line that says @import "aui/bootstrap"; and instead copy all of the imports in aui/bootstrap.scss and put it in it's place. Then you could move: @import "reset"; to being outside of the .aui {} selector.
The resulting file would look something like: https://gist.github.com/natecavanaugh/669d65f00616a4267abc
- Another possible option is to remove the .aui class from the HTML element, and place it in selected areas. For instance, you could conditionally add it in the portlet.vm around certain portlets, or setting it in the Look and Feel settings, and around a few places in the theme (like around the dockbar).
There would be some cases where things might be off, but we might be able to work up a solution for them (or at the very least, maybe make it easier to work around them in the future).
2. Regarding the JavaScript, we actually shouldn't be relying on that class name being on the element, so if there are cases you know of where removing it breaks something or causes an error, please let me know, because it's definitely a bug. If we are doing that somewhere (I can't seem to find anywhere that is in the code), it was a mistake that slipped past me as it's supposed to be an optional class.
But again, thanks for this kind of feedback. If there's anything else we could do to help improve the theme building experience, please let me know (or if there ideas you have for solving some of the challenges I mentioned in my other reply, I'm interested as well).
Thanks Chad
Thanks a ton for your feedback. Stuff like that is incredibly helpful
A couple of quick responses:
1. Currently, we only place the .aui class on the HTML, so it shouldn't show up on the body, unless you add it there.
But also, the generic styling like .aui li {} is happening because we're wrapping all of Bootstrap, including it's use of normalize.css. The idea there was that all of the styling, including any resets, would be able to be completely removed by removing that CSS class.
So there are a couple of approaches you could take to handling this:
- From the theme, you have full control of the aui.css file, so you could copy it from _styled, and place it in your _diffs/css/ directory.
What you could do in this case is change the line that says @import "aui/bootstrap"; and instead copy all of the imports in aui/bootstrap.scss and put it in it's place. Then you could move: @import "reset"; to being outside of the .aui {} selector.
The resulting file would look something like: https://gist.github.com/natecavanaugh/669d65f00616a4267abc
- Another possible option is to remove the .aui class from the HTML element, and place it in selected areas. For instance, you could conditionally add it in the portlet.vm around certain portlets, or setting it in the Look and Feel settings, and around a few places in the theme (like around the dockbar).
There would be some cases where things might be off, but we might be able to work up a solution for them (or at the very least, maybe make it easier to work around them in the future).
2. Regarding the JavaScript, we actually shouldn't be relying on that class name being on the element, so if there are cases you know of where removing it breaks something or causes an error, please let me know, because it's definitely a bug. If we are doing that somewhere (I can't seem to find anywhere that is in the code), it was a mistake that slipped past me as it's supposed to be an optional class.
But again, thanks for this kind of feedback. If there's anything else we could do to help improve the theme building experience, please let me know (or if there ideas you have for solving some of the challenges I mentioned in my other reply, I'm interested as well).
Thanks Chad
Eike Salow:
another option might be to think about the so called " css specificity " when you doing css development for your portlets... the .aui class can remain where it is. all you need to do is to make sure that your css within the portlet / your portlet area has a higher "specificity"... doing this your rule would "win" against the aui rule above, as your css selector has a higher specificity.
The approach I am taking with my custom Liferay 6.2 themes follows along the same lines. Luckily, I recently began making it a habit to scope my CSS using a prefix. So it wasn't to difficult to refactor using the the .aui class name
.My SCSS now looks like this:
html.aui {
font-size: 100%;
overflow-y: scroll;
}
.aui body {
font-weight: 300;
font-family: 'Roboto', sans-serif;
color: #333;
font-size: 81.25%;
line-height: 1.618em;
}
I still had to author some especially for Liferay though
, such as:
.aui .lime {
select,
textarea,
input[type="text"],
input[type="password"],
input[type="datetime"],
input[type="datetime-local"],
input[type="date"],
input[type="month"],
input[type="time"],
input[type="week"],
input[type="number"],
input[type="email"],
input[type="url"],
input[type="search"],
input[type="tel"],
.uneditable-input {
height: auto;
&:focus {
box-shadow: none;
}
}
select {
width: auto;
}
}
But sadly
that has always been the case with Liferay, hope this helps.Cheers.