I've been learning (X)HTML & CSS recently, and one of the main principles is that HTML is for structure and CSS for presentation.
With that in mind, it seems to me that a fair number of images on most sites are just for presentation and as such should be in the CSS (with a div or span to hold them in the HTML) - for example logos, header images, backgrounds.
However, while the examples in my book put some images in CSS, they are still often in the HTML. (I'm just talking about 'presentational' images, not 'structural' ones which are a key part of the content, for example photos in a photo site).
Should all such images be in CSS? Or are there technical or logical reasons to keep them in the HTML?
Thanks,
Grant
If an image is "content" say in a newspaper article, the editorial image, then use img tag. If it is part of your UI, theme or skin or whatever the name is, then yes put it CSS.
Suggested readings
Designing with Web Standards (Zeldman)
Bullet Proof Web Design (Dan Cederholm)
CSS Mastery (Andy Clark, Andy Budd, Cameron Moll)
One reason to put those images in CSS might be to serve different browsers from the same web site, just by changing the CSS: for example, if you detect a mobile/embedded/pocket browser you could give them the same HTML but with a CSS that doesn't include images.
I put them to CSS if possible. One reason is that I think they belong there like you mentioned and the other one is the possibility to use sprites. This can reduce the loading time of your page significantly.
The src property of an img tag is required according to HTML 4.01/XHTML 1.0 DTD. That is why it should always be included in the HTML.
You can specify it in the CSS for skining purposes, but most images in most cases are static and non changing so putting it in CSS is an unecessary step.
Well, it depends. For example, if you want to do some effects when the mouse is over an image, it must be in the HTML. When you put the image in the HTML you can positionate it more freely than in CSS. Also, as far as I know, CSS included images are not crawled (You can have interest in have your company's logo crawled by searchers).
If you think about accesibility, the HTML embedded images can have an alt and title information. So, for example, when you put the mouse over the logo of your company, the browser could show the motto of your company if you embed it with title="motto" attribute in the img tag. You can't do that with CSS.
Also people are used to put images in the HTML not the CSS and behaviours are a hard thing to change.
In conclussion, depending of your needs, CSS isn't flexible enough to fit your needs and you should put the images in the HTML. But if CSS fits your needs for UI images, then CSS is better idea.
Sometimes, loading UI images using CSS, also prevents the users from downloading your UI images to their drives, while saving a page.
But of course there are other ways to save them, but just a point to add.
And browsers tend to prioritize CSS more than HTML, so loading images through CSS might be a little faster compared to HTML.
Related
I've been using SVGs for a multitude of things and I was able to get the exact result I was looking for. This got me wondering why we can't build entire websites with them...
I don't mean like replace index.html with index.svg. More like having the basic HTML framework (for meta tags, styelsheets, scripts, etc.) and then giving <body> a single inline <svg> child where everything else happens. (text, layout, scaling, etc.)
My initial assumptions are that the website will fall short when it comes to form functionality, SEO, and accessibility. But then again if those can somehow be circumvented, then powerful SVG features can be used to render lightweight graphical effects that can effectively scale to any device dimensions.
Has this been attempted before and what are the potential pitfalls of "replacing" HTML with SVG? Should form functionality, SEO, and accessibility be a valid concern?
Maybe it is time to answer this question again. Contributions and edits are welcome.
Accessibility
SVG content is visual content. That in itself poses restrictions on accessibility. Nonetheless, the upcoming SVG2 spec has a paragraph on ARIA attributes that tries to give at least a bit of assistance. If you look more closely, you will find that for example a graphics primitive will get a default aria-role="graphics-symbol", which is not really helpful.
Whether screen readers implement any of this I don't know.
SVG gives you the opportunity to add <title> and <desc> tags anywhere. But the standard semantics that HTML5 offers through tags are lost. No header, no sections, no TOC or navigation. Try to imagine what the Firefox Reader View could make out of such a page: nothing.
Even linking to partial content of a page is difficult. While the spec is there, the semantic remains constricted: do you really want to highlight a link target by scaling it up to cover the whole viewport?
SEO in the end is just a specialized aspect of accessibility. Having an HTML <header> segment, a few things might be possible. Maybe someone else can comment on what Google implements.
Responsiveness
Problems start with the current inability of automatically line-wrapping text. Layout facilities are still a future project without working implementations. (While Firefox knows CSS inline-size, it is only implemented for HTML and does not work in SVG.)
CSS has put a lot of effort into providing layout mechanisms like flex and grid layout. In SVG, you lose all these techniques for reordering content in favor of simple automatic scaling.
Interaction
Text input is a solvable problem. You can use HTML inputs wrapped in a <foreignObject> tag, or you can build text input widgets from scratch by capturing keyboard input into a <text> element.
For most other forms of user input SVG might even be the superior platform. For example, clicking on/touching something to mark it and dragging it around/swiping it turn out to be only two aspects of basically the same interaction.
Especially Web components are the perfect complement to SVG for building interactive widgets. (Despite you still have to go through polyfills for compatibility with Firefox.)
Form submission
While HTML form submission for initiating HTTP requests might be absent, the advent of single-page apps has shown that it is possible to employ XHR requests instead.
Conclusion
If your content depends on or benefits from the standard semantics HTML5 offers, SVG is clearly not appropriate.
If you need to change the layout of your page in a responsive way, SVG will not be helpful.
SVG gives a lot of additional possibilities for creative, visually-oriented user interactions. As long as you find fallback solutions for visually-impaired users, your page will gain from it.
Overall, SVG gives you creative possibilities for specialized areas and widgets on your page, but falls short on the basic semantic questions a web page has to answer: How does your page relate to other resources on the web? What on your page is content, what is meta information, what is decoration?
The best of both worlds is to be gained by using a mix-and-match approach: structure your page with HTML, decorate it with SVG graphics, and build interactive/animated widgets with SVG and maybe Web Components.
You can build an entire website with SVG. I do it all the time, using Adobe Illustrator to create the pages.
You can go to my site, ozake.com to see a nice example. Even that is pretty basic compared to what is possible.
At first I did it all by hand, but the repetitive parts were annoying so I built a tool called Svija (svija.love, also SVG only).
Essentially you just put an SVG inside of the html body tag.
There are a few things to be aware of:
Microsoft browsers need exact pixel dimensions to be specified or the SVG will be drawn at the wrong size.
The Safari browser does not smoothly scale fonts (see my answer on this page). The consequence is that if you have two adjacent text blocks the space between them will vary randomly if the SVG size varies.
If you want to have several SVG's (one for the page, one for the footer, one for a menu, and one for a special event, for example), you need to be careful that the internal ID's are different.
Otherwise, a color style from the second SVG could be applied to the first SVG, with unpredictable results.
You will probably need to update the font style definitions inside the SVG's to make them work with web fonts. I use both Google Fonts and uploaded WOFF's.
You can make forms as a separate HTML layer based on the Adobe Illustrator system of coordinates. I just build the form in Illustrator, then copy the location and size of each element into absolutely-positioned HTML elements.
It's easier to build separate SVG's for repetitive elements, as I alluded to above. Rather than having to copy a footer to each SVG, just make the footer a separate SVG that's draw on top of the main page.
I built Svija in part to make sure that each SVG has unique internal ID's and to handle the font naming conversion.
You can link to external fonts and images as you would in HTML.
You can animate anything you want using GSAP.
The site is listed normally by Google, but the text will be in the order that it appears in the SVG. You need to pay attention in constructing the SVG if this is a priority.
To handle accessibility, I put the page text in a separate DIV before the SVG. Theoretically, a page reader should read the text inside an inline SVG but I have been unable to find out if this is the case.
I don't want to come across as trying to push my project. It's totally possible to do it all by hand.
At the moment I have on my website some images which are defined in the CSS file as a background image.
The code looks like this.
The HTML:
The CSS:
.image {
background: url("../img/deelnemende-organisaties/arcadis.png") no-repeat;
}
Due to some other CSS3 effects with this background it isn't possible to change the background to a normal <img> tag.
Now I was wondering what is the best way to use background images and keeping the SEO ranking as high as possible.
I saw some solutions as:
Putting text into the <a> tag and then hiding it with CSS with text-indent: -9999em
Only put a title attribute on the tag with the text in it
Placing a transparent in the tag with the same title as your tag
Leave it as I have in my example and building up a so called Image Sitemap in a XML file
Now I'm not sure what is the best solution and I don't wanna screw my SEO ranking by doing something what they call illegal.
I saw some solutions as: - Putting text into the tag and then hiding it with CSS with text-indent: -9999em - Only put a title attribute on the tag with the text in it. - Placing a transparent in the tag with the same title as your tag - Leave it as I have in my example and building up a so called " Image Sitemap " in a XML file.
Speaking as someone with two years' experience both as a copywriter and an SEO lead, two of those techniques are going to get you punished and it's hard to recover from, it's definitely considered Black Hat. As far as images are concerned, the only thing you can do is write good alt image tags that concisely and accurately describe the image for image searches like Google's. Use an alt tag like:
<img src="myimage.png" alt="Dog running in front of Redwood Trees"></img>
This is two years old, pretty old for SEO, but most of the basics are still true and SEOMoz is a place you can generally trust the information.
http://www.seomoz.org/blog/image-seo-basics-whiteboard-friday
Now, there is a 'best practice' when it comes to images. Images can't do much for SEO, but they can really help people stay on your site if they're pretty and interesting. It helps if you put your nice images on sites like Facebook and Pintrest which also drive traffic to your site and help you get found. While these are SMO (Social Media Optimization) instead of SEO, it's still part of good web design that will give you more traffic and eventually increase your PageRank. Never do anything Black Hat. Hope that helps!
Image replacement via text indent is a common pattern that if Google were to be penalizing that technique, that would be common knowledge. If your goal is to maximize the SEO surface or at least be on par with the standard img with alt, then of your options the text indent adds the text content you would have added if it had been an img and is not currently frowned on by Google's indexing algo. Using a transparent image with alt text on it might be identical SEO exposure but it is possible that Google may factor in a tiny sub KB spacer-like image and that could have an indexing effect however that is speculation.
The OP specifically states that he has to use a background image in this spot. There is no alt attribute for a background, so Copenhaver doesn't provide an answer.
I'm building my first website for an internship. My instructors always told me to never embed any styles on my html page.Now that I'm actually creating a site I find it annoying that, if I want to change the color of my font for a span tag - I have to I.D. it and reference it in a css file. Is there some other reason then organizational purposes for using CSS? Would embedding a single style be such a convention breaker? Thanks for reading this and I'd appreciate any feedback.
There are a couple of reasons.
Times when you want to change the style of a single element on a single page should be exceedingly rare, so it shouldn't be such a hardship. Any other time, it is going to be more efficient (from an HTTP caching perspective) and easier to maintain (from a separation of style and structure perspective) to externalize the style information.
Since there is a good chance that you'll want to style it differently for different media (e.g. screen and print), you'll need a proper stylesheet for that too.
If you embedd a style to several HTML pages, and want to change it later, you have to go file by file changing it. That is one good enough reason for me.
The key word here is maintainability. Organized code is maintainable code! It is far better to add an id to a tag and reference it in the global css file than to do it inline, because if you want to change that style later, you know where to find it, and you only have to change it in one place.
The reason you want to offload the CSS into a different file is so the browser can cache it. Otherwise, the browser has to load all the CSS as well as all the markup on every page. If you keep it in a separate file, the browser only has to load the CSS once.
The basic argument for this is that HTML's purpose is to provide structure while CSS's job is to provide styling, by embedding CSS in HTML you're breaking this basic rule. Plus, you'll have a tough time in maintaining pages.
Ideally, a design should be consistent enough that you can use generic rules for such situations. If you want to emphasize something, then <em> or <strong> is likely the way to go. After styling your <em> or <strong>, you can easily add the same emphasis to other areas of the site.
It's not simply about performance or style, it's also about consistency and ease of maintenance.
Find the similar elements in your design and mark them up similarly. It's as easy as that.
Even if it's "just 1" you should still do it because it helps you get in the habit of it.
embedded css has the following problems:-
1. It has browser compatibility problem. Example Ie has problem understanding inbuilt styling.
2. If you want to use the same css style again , it is better to have a class for it.
Is it possible to convert HTML + CSS into HTML for a system that doesn't handle CSS, not even inline CSS?
What options do I have?
No. Much of what CSS does is not possible with HTML alone. Your best option is to design your site in such a way that when it loses CSS, it still renders in a nice and orderly fashion. Pay very close attention to things like Heading Tags, paragraph tags, lists, etc. Be sure to build semantically-correct sites, and they (in most cases) will degrade quite nicely.
The only thing you can do is add styles that were possible with old html3+ attributes and font tags. Quite a bit of stuff is possible, but none of it is going to be automatic. You can go through pretty much everything in css and try to find it's html3+ attribute equivalent.
Things like background font b i center width height are examples of old attributes (or tags in the case of font) that define style (and should generally be ignored these days). I don't envy the work ahead of you, but just make a happy medium between reasonable things and unreasonable styles. Tables also might come in handy for floats as well.
Sounds like an old mobile device?
If you can't use any CSS, I would imagine you would have to resort to possibly deprecated HTML tags/attributes, like font tags and attributes like bgcolor.
This would probably be rather difficult, because to my knowledge you can't achieve everything you can do with CSS, like positioning for example. You would have to switch your layout to use tables and set align, valign, etc.
use this first
http://www.mailchimp.com/labs/inlinecss.php
then replace css with deprecated html
http://www.highdots.com/css-editor/articles/css_equiv.html
Two words: Image Maps :) (I've actually seen sites that, in order to "render correctly on every browser" literally just make a big fancy image the background, and add links accordingly via an image map)
When it comes to web-design, I am horrible at producing anything remotely good looking. Thankfully there are a lot of free sources for design templates. However, a problem with these designs is that they just cover a single page, and not many use cases. If you take a look at CSS Zen Gardens, they have 1 single HTML file, and can radically style it differently by just changing the CSS file.
Now I am wondering if there is a standard HTML layout (tags and ids), that covers alot of use cases, and can be generically themed with different CSS files like Zen Garden. What I am imagining is a set of rules off how you write your html, and what boxes, lists, menus and styles you are supposed to use. A set of standard test pages covering the various uses can be created, and a new CSS file while have to support all the different pages in a nice view.
Is there any projects that covers anything similar to what I am describing?
Check out the Grids framework from YUI. Particularly awesome is the Grid Builder. Also, they have a set of reset, base, and font CSS files that will give you a good baseline to build on.
I generally just try to follow the guidelines set by the HTML standard itself.
Headings go in "h" tags (so one H1 tag for the main heading, then one or more H2 tags under that etc).
Free text gets grouped in paragraphs in P tags.
Logically-grouped sections of information go in DIV tags.
Any kind of list (even menus that you eventually might want horizontally laid out) belong in list tags like UL, OL or DL.
Tables of information go in TABLE tags. DON'T use table tags for layout.
Be smart with your ID and CLASS attributes. Keep IDs unique and assign them to elements that you know represent something unique on the page, like a navigation menu or a page footer. Assign the same class to elements that are repeated but similar (which you might want to render with a similar visual style).
I always start with a very plain, vertical page - just run everything I want down the page in black and white. Then I start adding CSS to make sure the bits are formatted and laid out the way I want.
Take a look at the source of my home page for an example of what I'm talking about.
I've used Bluprint CSS, it's easy and useful as you'll see. It also has some ruby scripts that allow you to change the number of columns and the distance between them. By default it's 950px for a span-24 element.
BluePrintCSS was, from what I know, the first CSS framework.
As YUI CSS Framework, It's help you to handle layout.
That kind of framework will help you to build multiple CSS for your site.
BluePrintCSS is a quite mature project so I encourage you to check it out.