I want to create a configurator in React. The configurator will be used to configure pictures on the wall by customers, where fonts, strings and images will be changed. The question is:
What styling to choose for such a configurator? Should I reach for the tables, or rather the grid? My point is that the configured image must be in the same proportions (text vs images, images vs image position,...) for all devices. How would you style such an app?
Related
TL;DR: Is it possible to load other images based on media-query from svg included via img tag?
I generate a bunch of svg files with have tables with text and icons inside. A PDF would be semantically a better container, but I need to keep such "documents" as images for seamless embed/preview and it probably won't solve my problem. So the story is about icons.
I wrote inline styles with media queries picking icons corresponding to user's screen DPI. Icons are already bundled into sprites, so I use pattern/image[xlink:href] + fill:url(#id). Everything works as needed when I embed svg directly into HTML (DOM islands). But if I embed svg via img tag (i.e. <img src="foo.svg">), it doesn't load icons at all, let alone showing them.
I understand, that I can embed icons via data-URL, but embedding icons for all supported screen dpis seems too much. The irony is that icons are raster ones, hardly vectorizable pixel-art, so I cannot have one set of icons for all DPIs.
Is there a way to have proper icons picked by media query w/o embedding them all?
You can't load external files from an SVG used in an <img> tag (or used in other "image" contexts, like CSS background images). For security and performance reasons, SVG used as image has to behave like any other image -- a single file, no secondary resources and no scripts.
If you don't want to use inline SVG, you might consider embedding an SVG file with an <object> tag or <iframe>. However, I recommend that you actually test carefully to see whether browsers are downloading the image files even if they aren't using them because of CSS.
So since it's not possible to load conditionally: either embed or not, I should do some clever detection about raster sets. Technically not a direct answer, but in case someone needs.
I decided to go with cookies. People visit normally the same site that hosts those SVG.
I'd set a cookie for their DPI and then all SVGs served would pick proper DPI images.
For people who haven't visited the site yet, I'd go with UA sniffing: mobiles and macs get 2x, others 1x. Or just 1x for everyone.
I develop a MVC + Angular js Ecommerce site with huge number of images been loaded. I have a few queries regarding the performance of the site.
There is huge number of images been loaded. Shall I create thumbnails of different size needs and then show them or should i resize with css or any other technique.
How can i cache the images for the site.
If you care about performance and load times, you should create thumbnails server side. Css will only scale the image to your desired width but will still load the bigger one.
I suggest to make your thumbnails and then use those different image sizes for your different needs (smaller ones for product lists, bigger ones for product pages...).
You could even make use of different image src's for the same place toggling them depending on device width so you go even further improving load times on mobile devices. You could achieve this via ng-src or even with css with srcset
I'm using MDL for a desktop-only web application and I do not need the content to be responsive. That is, even if the user resizes the browser window, I don't need to re-arrange the content. Neither it will ever be browsed on a mobile device. How do I prevent the content from being responsive?
https://getmdl.io/components/index.html#layout-section/grid
I have provided reference to the MDL grid at the above link.
The content should not be responsive without initiating something like the mdl-grid class and mdl-cell class which would then allow you to label pieces like a content card with specific sizing, which will resize based on the device. If you are using your own style sheets you could create a card class which would have a specific pixel width you believe would work best for the project on a desktop.
We have a medium size application with around 30 views. We have many CSS files laying around. Some are specialized (popup styles) but the rest contains style for different parts of the application, in addition of the style embedded in the *.ui.xml and it's start to get pretty messy.
Is there any guideline on how to structure the styling in a GWT application and in a web application in general ? How do you structure yours ?
There are two schools of thought on this. Some developers prefer to use CSS Resources.
My strong preference, after 7 years of experience with GWT and multiple projects, is to have a single external CSS file for all styles. I even do not include any GWT stylesheets (including DataGrid styles) - I copy their content into my CSS file. These are the reasons for this preference:
CSS is called a cascading style sheet for a reason - it is build around inheritance. A professional web designer builds an app design starting from the very top (html, body elements) and defines the rules for the entire application: font or fonts to be used, color palette, standard margins and paddings, standard grid (columns width), etc. These rules must propagate throughout the entire app. Once developers start defining their own styles at the view/widget level, it's nearly impossible to ensure any design consistency across the app.
Even more importantly, when the CSS rules are split between many different sources, it becomes very hard to predict their interactions. Why is this element not positioned correctly or has the wrong font size? Is it because I used the wrong selector in the widget CSS, or is this because some other rule from some other CSS resource overrides or conflicts with it? Now you find yourself jumping back and forth between different stylesheets trying to make it work.
Even if you do find a source of the problem and fix it in one of the stylesheets, now you have to check how this change affected other views and widgets. Making a change at the top of the DOM tree can impact every element at the bottom (again, it's cascading!). Often it's not easy to anticipate this impact in every browser possible.
These considerations become even more important when you try to make your app design responsive and make your app adjust nicely to different screen sizes. What happens to your view or widget-level CSS when you add a media query in your main CSS file?
Another important point is the speed of development. If you use a professionally designed CSS file, you almost do not need CSS at a view or widget level. When I add a new form, for example, I never need any CSS - I just throw a sequence of labels and input widgets and they all suddenly look right and they are positioned correctly, because the rules have been already set and they apply to all forms, input elements, labels, etc. in the app. I do not think what font size or color to use in a widget. I just use a <h2> header, for example, and it has one color in a light skin and a different color in a dark skin, and it changes its size and margins according to the screen size.
Finally, moving as much CSS away from the widgets makes it easier to reuse them in new projects. Using the same example, if a header does not have a font-family, font-size, color or margins specified in a widget, it will take these values from another app's CSS file (which may or may not be the same rules as the contributing project's file). So you can reuse the widget in a new project without touching its code, which again speeds up the development process and makes maintenance so much easier.
To summarize, a single CSS file makes it easier to enforce style consistency across the entire app and maintain code, and considerably speeds up the development.
I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.