I would like to offer my users the ability to customize the look and feel of the website.
I am giving them a color picker to choose a color scheme. I would like to dynamically generate few matching colors and apply them.
My questions are:
1.) How can i generate a color scheme based on the choosen color ? (some matching colors and contrasting colors for the background)
2.) What are the best practices for achieving a themable interface ?
I am writing an AngularJS SPA app with pure HTML with REST API as backend.
Right now for my 2nd question, I am retrieving the color setting and applying them for body.
<body style="background:color:{{bgcolor}}; color:{{fgcolor}}">
I am looking for something more elegant.
You can do this with ngStyle as you have above... but as you noted, it's not very elegant.
The simple truth is that nothing in AngularJS itself is really designed to address this problem other than the ngStyle directive itself. However, while I haven't exactly seen a "best practice" for this, you might take some ideas from Drupal's "Color" module, which is one of its base/core modules. You can do the same thing in Angular very easily.
What this does is go back to stylesheets, which I'm assuming you skipped over because it didn't seem like an obvious solution for something dynamic. But they have a clever answer. In a piece of code, after the user picks a color, they write out a stylesheet with a unique ID for its filename. They put these in a directory where other user-uploaded assets are kept, so they don't mix with core site code (minimize the potential attack vector). Then they only need a simple rule in the page to include the stylesheet itself.
You can easily emulate all of this with Angular, although you'll need your server's help, of course. But the nice thing about it is it's much easier for you to maintain. Instead of having to "sprinkle" ngStyle directives all over the place (one on everything you want styled) and potentially having conflicts with other things you want to do on some of those elements, the stylesheet can work exactly the way it's supposed to: using classes to target specific elements. You can make a template stylesheet that's easy to maintain, so that's a natural fit... and the best part is, it's easy to hook everything up.
Related
Challenge
When using puppeteer page.click('something') one of the first challenges is to make sure that the right 'something' is provided.
I guess this is a very common challenge, yet I did not find any simple way to achieve this.
What I tried so far
In Google Chrome I inspect the element that I want to click. I then get an extensive element description with a class and such. Based on an example I found, my approach is now:
Take the class
Replace all spaces with dots
Try
If it fails, check what is around this and add it as a prefix, for example one or two instances of button.
This does not exactly feel like it is the best way (and sometimes also fails, perhaps due to inaccuracies from my side).
One thing that I notice is that Chrome actually often seems to give a hint hovering over the thing I want to click, I am not sure if that is right but I also did not see a way to copy that (and it can be quite long).
If there is a totally different recommended way (e.g. Looking in the browser for what the name roughly is, and then using puppeteer to list all possible things), that is also fine. I just want to get the right input for page.click()
If you need an example of what I am trying: If you open this question in an incognito tab, you get options like share or follow. Or if you go to a web shop like staples and want to add something to cart.
When using puppeteer page.click('something') one of the first challenges is to make sure that the right 'something' is provided.
Just to be clear, "something" is a CSS selector, so your question seems to reduce to how to write CSS selectors that are accurate. Or, since Puppeteer offers XPath and traditional DOM traversals, we could extend it to include those selection tools as well.
Broader still, if there's a data goal we're interested in, often times there are other routes to get the data that don't involve touching the document at all.
I guess this is a very common challenge, yet I did not find any simple way to achieve this.
That's because there is no simple way to achieve this. It's like asking for the one baseball swing that hits all pitches. Web pages have messy, complex, arbitrary structures that follow thousands of different conventions (or no conventions at all). They can serve up a slightly or completely different page structure on any request. There's no silver-bullet strategy for writing good CSS selectors, and no step-by-step algorithm you can apply to universally "solve" the problem of accurately and robustly selecting elements.
Your goal should be to learn the toolkit and then practice on many different pages to develop an intuition for which tools and tricks work in which contexts and be able to correctly discern the tradeoffs in different approaches. Writing a full guide to this is out of scope, and articles exist elsewhere that cover this in depth, but here are a few high-level rules of thumb:
Look at context: consider the goals of your project, the general structure of the page and patterns on the page. Too many questions on Stack Overflow regarding CSS selectors (but also in general) omit context, which severely constrains the recommendation space, often leading to an XY problem. A few factors that are often relevant:
Whether the scrape is intended to be one-off or a long-running script that should try to anticipate and be resillient to page changes over time
Development time/cost/goal tradeoffs
Whether the data can be obtained by other means than the DOM, like accessing an API, pulling a JSON blob from a <script> tag, accessing a global variable on the window or intercepting a network response.
Considering nesting: is the element in a frame or shadow DOM?
Considering whole-page context: which patterns does the site tend to follow? Are there parent elements that are useful to selecting a child? (often, this is a distant relationship, not visible in a screenshot as provided by OP)
Consider all capabilities provided by your toolkit. For example, OP asked for a selector to close a modal on Stack Overflow; it turns out that none of the elements have particularly great CSS selectors, so using Puppeteer to trigger an Esc key press might be more robust.
Keep it simple: since pages can change at any time, the more constraints you add to the selector, the more likely one of those assumptions will no longer be true, introducing unnecessary points of failure.
Look for unique identifiers first: ids are usually unique on a page (some Google pages seem to scoff at this rule), so those are usually the best bets. For elements without an id, my next steps are typically:
Look for an id in a close parent element and use that, then select the child based on its next-most-unique identifier, usually a class name or combination tag name and attribute (like an input field with a name attribute, for example).
If there are few ids or none nearby, check whether the class name or attribute that is unique. If so, consider using that, likely coupled with a parent container class.
When selecting between class names, pay attention to those that seem temporary or stateful and might be added and removed dynamically. For example, a class of .highlighted-tab might disappear when the element isn't highlighted.
Prefer "bespoke" class names that seem tied to role or logic over generic library class names associated with styling (bootstrap, semantic UI, material UI, tailwind, etc).
Avoid the > operator which can be too rigid, unless you need precision to disambiguate a tree where no other identifiers are available.
Avoid sibling selectors unless unavoidable. Siblings often have more tenuous relationships than parents and children.
Avoid nth-child and nth-of type to the extent possibe. Lists are often reordered or may have fewer or more elements than you expect.
When using anything related to text, generally trim whitespace, ignore case and special characters where appropriate and prefer substrings over exact equality. On the other hand, don't be too loose. Usually, text content and values are weak targets but sometimes necessary.
Avoid pointless steps in a selector, like body > div#container > p > .target which should just be #container .target or #container p .target. body says almost nothing, > is too rigid, div isn't necessary since we have an id (if it changes to a span our new selector will still work), and the p is generic--there are probably no .targets outside of ps anyway.
Avoid browser-generated selectors. These are usually the worst of both worlds: highly vague and rigid at the same time. The goal is to be the opposite: accurate and specific, yet as flexible as possible.
Feel free to break rules as appropriate.
In my angular 5 application I develop for multiple countries say, India(Hindi), default(english) and Malaysia.
Now when the user change the language, I require to add the appropriate font-family as default to page.
In the page, there is some font-family added by element level. say ( p tag with font thinner and small size ).
As a information how this kind of scenario handled by UI development?
Is there any regular practice which i need to follow?
Thanks in advance.
Depending on your framework, many allow for inbuilt localization functionality that makes it super easy to change content as well as things like font. For Angular look into:
https://thebhwgroup.com/blog/2015/01/translation-localization-angularjs
Usually we search elements by selectors in libraries like jquery but what happens if we want to make the other way around: given an element we want to find all rules applied to it like firebug does it!
This kind of job is necessary if we want to bring a css file and update it so we can see live results in our webpage.
In firebug by selecting an element we can see in reverse order all the rules that were applied to it.
First, we have to find the document's style rules and retrieve their contents as a text so user can update them but the real problem is to find the relation between an element and all the rules....
Is this possible even with the help of a library like jquery?
I was looking for opinions about what tools can one use to tackle such a problem in the restrictions applied by a browser environment...
My opinion is that we have to make a brute search attack at the css files/selectors and construct the dependencies: suppose we have 100 rules for a page with 100 elements the possible combinations are 10^4 as the relations are many-to-many.
Then, we can build 'tables' in memory (hash arrays) that might excced 10^4 records if we want to keep the cascading order of rules for an element.
Anyway, my point is that I wouldn't dare to put jquery in such a pain! If we can 'transplant' the heart of jquery, it's search engine I mean.
It seems that it's heart listens to the name of 'sizzle' but it's a waste of time here (regular expressions? no thanks). I think the real 'heart' is a simple word: 'querySelectorAll' and now we are running with native speeds here...
just an opinion since I don't care about wide/old browser support.
I am working on creating a jQuery plugin and I have some questions regarding how to structure things:
1.How much HTML should the plugin have written and how much should it create through jQuery ?
Is it good to have written all of the HTML so that the entirety of the markup structure is visible when looking over the code ?
Or is it better to have written only the minimum amount of HTML so that it is very easy for the user to add/modify content and create all of the rest, bulky HTML through jQuery ?
Is there a recommended practice ? How are things done in professional plugins ?
Why should things be done in a certain way and what are the reasons behind it ?
2.How to balance the plugin options with the CSS ?
Should the plugin offer options that would affect the presentation of the plugin (options that would modify the stylesheet) or is it a better practice to have the user directly modify the stylesheet for presentational modifications and in the plugin only have options relating to the functionality ?
What are some guides regarding what options to offer in the plugin as to not step over CSS ?
Regarding my experiences, I have seen all of these in different places and plugins and that is why I am asking for opinions from experienced users and what are good practices and why.
1. How much HTML should the plugin have written and how much should it create through jQuery ?
According to the paradigms of progressive enhancement, there should be no markup which would be useless in case of no JS enabled. In other words - if your plugins needs some special markup and additional tags it should create them by itself.
The reasons for that is semantics. Additional plugin markup is useless for users (and bots) when there's no JS enabled and thus it should not be present at all.
Also keep in mind that developing a good JS plugin means that content will still be available when the plugin fails or JS is disabled. Moreover, you have to take additional care about making sure that your plugin is accessible. More on the topic of progressive enhancement covering also more advanced issues can be found for example in a book by The Filament Group.
2. How to balance the plugin options with the CSS ?
Do it as follows:
Content: HTML
Logic: JS
Presentation: CSS
Despite the fact it's changing now a bit (think CSS3 animations), options of the plugin may influence the way it works rather than the way it looks. That means your users should be able to config timings, delays, speed, number of element or whatever your plugin is doing through JS. But leave the presentational aspects in the CSS stylesheet. Use JS to change classes of elements rather than inline styles and let your users write whatever CSS they want. Obviously, don't forget to provide some default styling :)
I always recommend reading more on the topic in A List Apart. It's quite a theoretical article but absolutely a must-read for any front-end dev.
Tutsplus has a jQuery course with usefull videos.
http://tutsplus.com/lesson/head-first-into-plugin-development/
This is one of the videos that explaines how te make a plugin.
There are a lot of ways to create a plugin, but this is a good one.
I understand that content, presentation, and behavior are supposed to be separated by using HTML, CSS, and JS to implement them independently. Is there a best practice for binding these elements concretely while maintaining loose coupling in a dynamic web app? Is it even possible? Optimally without depending on jQuery?
To clarify what I'm talking about: HTML has no mechanism for the definition of new tags, so when your JavaScript model needs to generate content, the tags and structure for its presentation are necessarily defined in JS or somehow made accessible to it, tightly coupling behavior to content.
Before someone calls over-OOP, the reason I want to keep tags and CSS classes out of JS is that I don't even want to commit to HTML as a front end. There are at least five different representations of my underlying model that I'll eventually want, and tightly coupling the model to HTML rules out at least two of them.
Is there some way to late bind the model to the target representation without sacrificing dynamics or loose coupling? Like an XML document corresponding model elements to template HTML snippets?
UPDATE
Though it seems backward to provide concrete details of a question about factoring and OO best practice, I want to provide a much fresher example of the entanglement of form & function inherent to HTML. The entanglement of content & behavior between HTML and JS is the problem, though, not the example, and I want an answer that doesn't break when I change the details. It's from a very different project than the one I was working when I first asked this question, but the gist is the same:
I have some HTML for a UI widget. It is a view that represents a model object - a selection of palettes - to the user. Palettes themselves are part of the app's task, so they're not view, they're model.
I want to use this widget in at least 2 different dialogs (and any I might want in the future). In one, I need a changed selection to cause immediate action, the recoloring of a set of images in canvas elements that are part of the same dialog. In another, I just need to have two different sets to select from - one selection in each set.
I do not want to copy and paste this widget's HTML form or JS behavior because I want maintenance and revision to propagate from one base thing to all of its instances. Thus, only one instance of the widget, whatever its form may be, may exist in my source.
I do not want to have my JS rendering HTML tags directly because doing so will forfeit my IDE's error checking and content assistance on the HTML. Further, if there are problems with the HTML output, their source in my JS will be less clear because the process of generating the HTML doesn't look like HTML or necessarily reflect its structure. Finally, I want to test the effects of changes to the widget's CSS and HTML independently of my JS.
I do not want to involve additional dependencies e.g. separate templating & parameterization languages in my source because changes to various standards or evolving needs may break their compatibility, or they may themselves become unmaintained, in the future, leaving me with a massive quantity of useless source. Depending on jQuery is okay because it does more for normalizing between browsers (not to mention for convenience) than it is likely to ever break given its ubiquity, but other libraries will be regarded with extreme suspicion.
I want to specify the details of altering and retrieving the widget's state (what colors compose the palettes, how the user chooses among them) in JS that references only the widget and its component parts, since it's going to be a part of multiple dialogs that use its information in different ways.
Simultaneously, other JS code (the dialog's behavior) needs to be able to observe and initialize the widget's state - but without including any specific references to the widget's internal structure, which may some day change to accommodate new features, fix bugs, etc.
For simply making multiple copies of the widget's HTML, I can settle on calling jquery.clone on a template node that exists in an HTML file, and inserting the contents where I need them, from the function that sets up the dialog. HTML makes things difficult when any of the cloned elements have id or name attributes, but careful handling during cloning can make unique identifiers, point their corresponding label elements and href attributes at the new identifiers, and keep the old ones accessible in data attributes. So all is well and good for structure & content, and obviously the CSS presentation propagates to the clone just fine.
The rub comes when I try to implement the widget's interface with its dialog's controller. What is the most future-proof way to expose the widget's state's abstraction? I.e. I don't want to use widgetJquery.find('input:checked').val() to get the selected color from code that doesn't absolutely have to commit to a selection being based on a checked input element whose value attribute is a set of serialized colors.
I hope that makes it more clear what I'm looking for without muddling the question with details.
You can always have different XSLTs parse an XML.
But, it seems you try to abstract tooo much.
use the MVC, use different views to parse.
The methodology you write about is common in old systems, I worked with more than 10 years ago, there is probably a good reason evolution killed it.
Loose coupling is best achieved archtecturally using design patterns. A great example of how to achieve loose coupling is found in the Mediator Pattern. However, there are several patterns to use.
I suggest reading Addy Osmani's 'Essential JavaScript design Patterns' for comprehensive coverage of a range of patterns.
Enjoy!