The names behind PrimeFaces' class attribute values in the html generated for data grids -- like ui-paginator-rpp-options for the rows per page display/input, and ui-paginator for the page "navigator" GUI component -- are those names PrimeFaces-specific? Or could I easily find other UIs that use the same names in the class attribute?
My understanding is those names have been created by PrimeFaces, and there was no other pseudo-standard using those names earlier, right?
I am simply wondering if the code I am writing to address GUI details like these is PrimeFaces-specific or not, which would have consequences for the architecture I am designing for a test framework. It should clearly reflect what refers to (and conceptually depends on) what ;)
I am amazed that after years of wrangling with this stuff, I still am note sure about this. If the answer is so obvious that it embarrasses me too much, I will delete this question (I think :) )
Many classes in PrimeFaces come from the jquery-ui guidelines. But indeed some are PF specific. If styling in PrimeFaces needed to be done for components or component parts that have no counterpart in the jquery-ui set of components, they 'invented' new classes. It would indeed have been better if those would not have gotten the ui- prefix, but a pf- prefix.
There is, afaik, not en exaustive list or even a non-exhaustive one that contains an overview of all of these
Related
This "question" has been asked before I've seen, but none of those existing answers really address the question, nor provide resources that are exhaustive in themselves. I am looking for a single resource that I can import into code easily, not have to write a web scraper to expand every possible link and then scrape secondary and tertiary pages for property values.
Examples of links that are useless: (or borderline so)
http://meiert.com/en/indices/css-properties/
for other useless links, check the prior questions, my reputation won't let me post more than 2 links as examples.
Almost ok(ish)
https://www.w3.org/TR/CSS21/propidx.html (except that it is a small fragment of what is possible with css3 and links elsewhere for other properties, and one has to expand the <...> refs to find the actual values for many properties as well).
Ideally something like in the mozilla headers/code might work, requiring a minimal processing, or just a flat table if someone knows where it is would be great.
Hopefully this doesn't get closed as off topic, because the list of property keys and values is of paramount importance for programmers. Otherwise how would one know what all the valid values are? Anyway, I don't think its the kind of question to attract spam, esp as I've done some in depth googling.
This is for inclusion in separate library, not to just write css myself.
...because the list of property keys and values is of paramount importance for programmers. Otherwise how would one know what all the valid values are?
One very easy way to find out the available properties and values is to play with the browser dev tools.
Open the dev tools in your favourite browser. Inspect any element you like from the page you're on, and you should get the HTML shown on the left, with the CSS and other properties of the current element on the right. From here you can explore the available styles, and see their effect in real-time.
The "Computed" styles will show you all the styles that are available and their current settings. The main styles tab will allow you to add new styles or change existing ones. In most browsers, you can use the cursor keys here to explore the values that are available for any given CSS property, and also the properties that are available for the current element. Making changes here will update the page immediately. This is a great way to learn the kinds of things you're looking for.
I think I found something workable, hopefully this helps others too. Basically the place to look is in the opensource webkit code at the CSSPropertyNames.in and CSSValueKeywords.in files. I'm looking at version 7601.3.8 on Apple right now. A user can extract what they need without too much work, though I may just write an easy to use/shareable lib for others.
http://opensource.apple.com/source/WebCore/WebCore-7601.3.8/css/CSSPropertyNames.in
http://opensource.apple.com/source/WebCore/WebCore-7601.3.8/css/CSSValueKeywords.in
7601.3.8 is up to date as of 2015, according to the changelog. It may not have absolutely everything, but I think it should work.
Actually the list I included here is not exhaustive either. The webkit .in files cop out and just list a bunch of values under CSS_PROP_OTHER.
This question already has answers here:
Best way to structure a CSS stylesheet [closed]
(2 answers)
Closed 8 years ago.
I am creating a design for a mid-sized Web application. It's my first time, and there is no established design process at my workplace. Previous projects are small internal applications, and the back-end developer used a minimal design just enough to make stuff align where it should.
I started doing the design for each type of page separately, and created a new CSS file for each type of page, e.g. a separate one for input forms, another one for the search interface, and so on. I also made one large file with elements used everywhere (header, footer, buttons, warning messages and so on). It was the only reasonable structure I could think of.
I've been at it for a while, and I'm now noticing that I've created some sort of chaos. When I have an element and need to change the definition of its style, I always have to go through Inspect Element and then Visual Studio's search function, which is still reasonably efficient. But I also frequently find myself looking at definitions in the stylesheet, having no idea what they are for, or if they're still in use at all - maybe we have already thrown out the elements which use them, or they were an attempt to solve a problem which got a better solution.
I am already trying to give good, semantic names to my classes, but it's not sufficient, and sometimes even impossible - every workaround I use seems to leave me with names like .centeringWrapper.
What is a good, workable structure of CSS code which prevents these problems? What principles can I apply to arranging the code?
How can I divide the code into files so I can find the correct file?
How to structure code inside the files so I can keep my orientation within a file?
How to keep the overview of different definitions for the same element which are used within different #media blocks?
Any advice for making my work less messy is welcome.
The best practice for structuring your CSS is to structure your CSS. By that I mean have a system. It doesn't really matter what your system is, as long as it makes sense to you and your team and people can consistently maintain it (at least for a reasonable length of time).
I can tell you one way not to do it, though and that's by not designing each page separately with its own CSS.
I think you've figured this out already, but it's worth repeating.
Now, there are times when I've broken this rule. But it's rare and it's typically on small marketing-centric sites where I simply have 4 very different pages. In general, though, you want to re-use as much of your CSS as you can across all your pages.
One way to achieve that is to start with a pre-existing structure by working off of a CSS framework. A common one is Bootstrap, but there are literally dozens and dozens of options out there.
Why do I see .closed-dialogue and .open-dialogue so often in commonly-used libraries, instead of .closed.dialogue and .open.dialogue?
the problem with a single class per element
To format all dialogues with the first approach, you would already need two classes in the selector.
Each time you add another difference, f.e. some colour, you would multiply the number of classes in the selector: .warning-dialogue-closed, .error-dialogue-closed, .warning-dialogue-open, .error-dialogue-open.
Now how can that be good practice? This is hardly maintainable!
You couldn't even separate your code in modules, since the basic selector for dialogues needs to know all dialogues that exist!
several classes per element solve this
By concatenating several classes, the code would be way shorter, more maintainable and easier to read:
.dialogue formats all dialogues, no matter how many different you have.
.error.dialogue and .warning.dialogue would add changes for either flavour. .open.dialogue and .closed.dialogue would take care of the other difference.
You even could have another isolated module that defines big and small dialogues, and the basic module doesn't even have to know about it.
So why have I never seen this?
The problem with your approach is that it's more likely to conflict with other classes.
If the page itself has some other unrelated open class, class="open dialog" will pick up rules for that class and get messed up.
This is why libraries like jQuery UI tend to prefix all of their classes with a unique value.
I was reading this:
"Guideline Number 7: Try to avoid using unecessary classes and IDs.
So, now that we’re keeping our hooks to a minimum, it’s time for our next step in quality over quantity: naming. We want to avoid names that imply presentational aspects. Otherwise, if we name something right-col, it’s entirely possible that the CSS would change and our “right-col” would end up actually being displayed on the left side of our page. That could lead to some confusion in the future, so it’s best that we avoid these types of presentational naming schemes."
So what do I call them if not right-col and not presentational?!?!
I discuss this very topic in "How to Develop with CSS". What you call it depends on the content. Maybe "sidebar" or "links" or "extra".
any naming technique has advantages and disadvantages...try to find a way that help you more in your work, and make well commented css files.
Rather than naming things after their presentation name them for their function, or purpose. Also, try to use a coherent page structure so far as possible, and use the CSS cascade to access/target elements.
As long as it conveys meaning for the html structure and other developers can understand well it should be fine.
check out 960.gs using that gridsystem will save a lot of time, trying to figure out the best naming scheme.
NCSS Sheets is a naming convention and guideline for semantic CSS: CSS class naming convention
Where multiple people can work on same css. is it possible to follow semantic name rules even in large websites.
If I would write all main css first time with semantic names . then what and how i should guideline/instruction to other developer to maintain css readability, validation . and to know quickly where other are adding their own css if required.
Right now every one just go to down and write required css classes ot IDs at bottom. and most of the time they don't write semantic names.
How to make good documentation/guide with text or with images for other developers on how to use css in whole site and how i wrote and what i used.
Update:
We use only one CSS file. I don't want to divide one css in multiple. Want to keep css managable even using one CSS file for whole site.
A similar question was asked a while ago: How to manage CSS Explosion there is a number of good answers there, and a number of great links (check out those provided by Paul D. Waite for example.)
Your main problem is going to be structuring the CSS file well. You will need clean rules for that: Keep everything grouped within the CSS file. Maybe using a CSS editor that can help you "navigate" through the style sheet is a good idea (similar to a programming IDE's "code explorer" feature). I don't know, however, if such a thing exists.
Other than that:
Using version control is a MUST. I personally am totally happy with centralized versioning using Subversion and TortoiseSVN; others believe in distributed version control like git or hg. For a team of designers, I think the centralized approach of Subversion is good, but that is a discussion in itself.
Maybe it's a good idea to split the style sheet into thematically relevant separate files to avoid chaos, and compile it using a tool like LESS or xCSS.
Define a clear, concise coding style. Use a CSS beautifier like Polystyle ($14 per license but money well spent) or Code Beautifier (based on CSS Tidy, haven't used it but looks interesting) and run it frequently on the file.
Have a number of links handy of pages that use the style sheet. Have people test those pages after they have made a change to the style sheet.
I would break down your css logically into groups and put each of these groups into its own css file. For example: header, footer, sidebar, content groups. Maybe some pages even deserve their own css file if big enough.
Similarly, give ids and classes on pages names that make sense. If it is a css rule for sub headings on a navigation bar, make sure it comes off as that in naming. Similarly to any other coding, don't use any magic numbers, etc. for naming.
See Modularizing web applications, includes specially CSS