Do you think the hiding particular content from the mobile version of a website can harm your SEO? I have a page that has around 3 long paragraphs of content. On the desktop, this looks fine - but on a mobile there is far too much content before being able to click my categories on the page. What I've decided to do is write a media query to hide all but the first paragraph in this section. Could Google think that I'm trying to use black-hat techniques or would they understand that my content is visible on mobile?
Thanks!
The {display:none} tag within your CSS for the para you're trying to hide will be read by Google. But the question here lies whether they will consider it after parsing the media query.
Highly doubtful considering they read "present" code and do not read multiple instances of it, as recorded spider data is mainly the code on your HTML page without considering the ifs and buts of CSS & JS.
IMO, you should not be penalised for this as long as your content is unique and you're not indulging in any black-hat tactics.
Maybe you need this one for hiding content for mobile devices.
#media all and (max-width: 479px) {
.content .mobilehide{
display: none;
}
}
<div class="content">
<p class="mobilehide"> This will hide on mobile version </p>
</div>
It's hard for most of us to know at what point Google will draw the line and say that your site is breaking cloaking rules.
Maybe take a look at this forum post on Google's Product Forum for a little more info.
I've read one place that aural stylesheets are no longer in use? Is there something that has replaced them? I'm sure something is being used to make things easier for those who are visually impaired?
If aural CSS is in use still, is there a way to specify what should be said in a specific place, similar to using "alt" for images? For instance, I'm using an iconfont for my logo. I'd like to be able to have the user hear the name of my company, but because it's just done with a span, there's no place in that particular span that indicates the words (I'm assuming here that the system reads the words displayed on the screen, and not all the code with it, so obviously this works better if there's actual text to read). Maybe include a content: 'whatever text you want' is added somehow?
The gist is that I'm working on a site about opera for a client, and the client would like for the content to be accessible to everyone. And obviously someone with visual impairment is going to be especially wanting to hear things.
1. Is there a replacement for aural?
Aural stylesheets have indeed been deprecated as of CSS3. Major browsers such as Firefox removed the implementation a while ago. There is still a speech media included, but I haven't seen any implementations so far (it just seems to be a proposal at this point).
Many people with visual impairments use screen readers and to a lesser degree refreshable braille displays to view the content, so you usually don't have to worry about a direct implementation of speech. Important points for that to work are:
People have to be able to navigate through your content using the
tab key
All relevant rich content such as images etc. need to have a text equivalent.
Your html should be semantic (have a look at the aria attributes)
2. How can you make icon fonts (and other non-legible items) accessible?
In this article on bulletproof accessible font icons they propose a pretty good solution:
Since the characters don't have any direct semantic meaning, you could include them in the :before pseudoclass of your span:
.logo:before {
font-family: YourIconFontFamily;
content: "★";
}
And then include the company name directly in the span:
<span class="logo">Your company<span>
According to W3 it's defined in CSS 2 - but is already been deprecated with CSS3. You also can have a look at the Speech module: http://www.w3.org/TR/css3-speech
You can use another span with the specific content only for the screen reader which would look something like:
<span aria-hidden="true">Here could be your company name</span>
Source: http://www.456bereastreet.com/archive/201205/hiding_visible_content_from_screen_readers_with_aria-hidden/
I'm having some issues with css and inline styles on an email campaign I'm doing.
Firstly I ended up cheating a bit in that I was hiding elements (display:none;) to make them appear in the right order when using the #media css. The issue here was when displaying on a desktop isp (gmail) it ignored the (display:none;) and ended up showing double content in places. So to the double content disappear I used (display:none !important;) which then affected the mobile version.
There are some mobile templates I've seen online which don't appear to have had much testing as they simply do not work across multiple mail clients.
The code is here if anyone has any suggestions or help http://www.makeyourownmarket.com/test/test-doc.html
Some tips for responsive emails:
Put your !important declaration on all of your #media only screen and (max-width: 480px) CSS
Think of workarounds, if display:none; isn't working, try width:0;height:0; on your inline CSSand then override with width:100px !important;height:100px !important; in your mobile styles
You will need to do extensive testing, having an account/device for all the significant email clients is the best, but http://www.emailonacid.com works in a pinch.
I'd recommend doing a little more research into HTML emails and their limitations.
This article is a good starting point:
http://kb.mailchimp.com/article/how-to-code-html-emails
Some tips:
Don't place CSS in a STYLE tag as this won't work across all email clients.
Use inline CSS only
Use Tables for layout
I would be very surprised if media queries would work consistently in email clients. I'd avoid trying to use those and instead concentrate on creating a basic, solid email template which displays consistently across the most popular email clients.
I dont think responsive design is the right way for emails. Usually emails are made inside the table because of many mail clients. You could find more about this here Nettuts
Best practices in normal web development call for putting your styles between style tags or loading a style sheet; however, I've found out that several email clients will ignore any style tags and only execute inline styles (www.campaignmonitor.com). I can deal with that, but I'm not sure if CSS supports inline media queries. I would like my email to display a little different on the desktop. Is something similar to this supported?:
<div id="myDiv" style="#media screen and (max-width:480px;){ color:black; }"></div>
HTML emails are an entirely different beast. You need to code them like it is 1999. Use a very limited set of tags and make sure all or your styles are inline. Use tables for your layouts.
To make use of media queries you need to do both.
What I recommend doing is to first create your email with all inline styles. Then when you are happy with it you can add support for mobile.
To add support for mobile add the media queries to the head tag and use !important to override any inline styles.
Here is an example:
Optimizing for mobile email
Here is a helpful chart that details which css support for email clients.
http://www.campaignmonitor.com/css/
I don't think they work inline like that, you would probably have to embed the stylesheet in the HTML email template itself (e.g. <style>#media {...}</style>).
Even that seems like a VERY dodgy thing to rely on. HTML emails are a huge pain in the ass because standards and CSS support are about a decade behind and there is massive variation among popular email clients in terms of which properties and types of styling are supported.
In general keeping it simple and using old school table based layouts with all inline CSS is the way to go. Campaign Monitor has a great chart of support for various CSS properties in major email clients and devices.
A common workaround to the problem of HTML not rendering correctly in email clients is to do the best you can and have a prominent link at the top that says: "Email not displaying correctly? View it in your browser."
Ray Kurzweil's weekly newsletter blast does this, and it's very well formed, and well done, and I always read it. (It's a brilliant blend of content and presentation).
What should be written first while making CSS layouts XHTML code or CSS code?
Write Whole HTML first then write
CSS according to HTML
Write HTML for an design element and
CSS simultaneously
Write whole CSS first then write
HTML according to HTML
I read on this article's point # 7 "Create Your HTML First" is this advice best to follow?
Edit:
and in this tutorial author also write HTML First then write css using Edit CSS option of web developer toolbar i think this is best way.
In practice, you generally wind up needing to intermingle the two. Start out with HTML to rough out the basic areas of your design, then work in CSS around that rough idea. Typically you'll find yourself needing to add some more markup to allow for additional flexibility (perhaps you need a couple of nested containers to properly align something, et cetera).
I used to ponder about this long ago, when designing websites.
My conclusion was, and I believe it still stands today, that even though XHTML and CSS are meant to be isolated from each other as content and presentation respectively, the reality of the matter still makes the look of the website pretty much depend on the document structure - i.e. markup, XHTML - and thus CSS alone will not give you the magic wand to make your website change its look completely based on a stylesheet. I wish it were so however - certainly, that is the main purpose of CSS. And certainly, that would be the beauty of it - since each is completely isolated from the other, website developers can in peace of mind program the structure of the website documents, almost while the CSS authors can work in parallel and write the stylesheets. Then both are combined, and with the knowledge that the markup does not need to be changed ever again. That is the theory anyway.
In practice this often fails to work - because a document has a top-to-bottom left-to-right (usually) bound semantics, it becomes difficult to for instance, make an element appearing at the bottom of the document structure, appear at the top of the browser page to the user. The limitations work against the theory.
Because of the above implications, and some other real-world limitations of the CSS and markup technologies, I have decided to simply consider markup as something in between the content and the style. I.e. some of the markup will unfortunately dictate style, no matter stylesheet - the sequence of elements being one (see above), pagination limitations, etc - and so, while most of the structure may be isolated from its appearance, some of this appearance will be dictated by it. For this reason, if we don't regard client side scripting (which may aid styling by re-arranging elements of a document) - one way to do it is use XML as content, XHTML as content-style hybrid layer, and CSS to finally dictate the appearance.
Where does XML come into this? Well, you transform (either in browser or server-side) it with XSLT into a XHTML document, which you consider as relevant in the styling process. I.e. if you have an artist list of 1000 entries, and you want to customize how the page looks like, you use the following content XML:
<artists>
<artist name="Moby" />
<artist name="Cocorosie" />
<!-- and so on -->
</artists>
This is considered as an unchanging content, no matter the final style - part of the point of separating content from presentation, something you could not have done fully with XHTML because CSS cannot do certain things. With XSLT however, you can further transform the above into a desired markup ( you can then apply CSS to):
<xsl:transform>
<!-- XSLT is beyond the scope of this... -->
</xsl:transform>
will transform the XML into something like:
<h1>Artists</h1>
<h2>Page 1 of 10</h1>
<ul>
<li><a>Moby</a></li>
<!-- Only 100 artists per page -->
</ul>
And then you style it.
Bottomline is, you get to control each point of the transformation of your raw database content into final end-user application.
Much of what XSLT does with XML, can be instead done with JavaScript on XHTML, but I consider client-side scripting an addition, not replacement to things like XSLT. Then again, Firefox and most other modern browsers can do XSLT client-side, which blurs the distinction between scripting and document serving.
I think it's a mistake to do one before the other. Programming is an iterative process. Write them both until you have something small that works, then do it again. Build on it. Iterate.
If you write just HTML without writing any CSS, you'll find out later that you'll have a bunch of technical debt that needs to be paid off.
It really depends how big is your site... If it's a small website the order doesn't matter. If it's a big website i generally design basic structure in HTML then basic CSS and then move to details in HTML and then CSS.
Few advices.
re-use already made CSS and HTML.
ie. if you already have template
with basic HTML wrappers save it
for the next project or page or
if you set all images to
border:none in your CSS you can
easily save some CSS file with
basic settings
see an object in your head before
designing it
check in 5 major browsers (ie6 ie7
ie8 chrome and firefox)
I usually go with the second option:
Write HTML for an design element and
CSS simultaneously
This really helps, for example, when I am writing html, i write the CSS along the way too which helps me quickly spot any possible layout or cross-browser compatibility issues. If i wrote whole html first and then css, then things become little complicated and you have hard time correcting/styling the entire html which you already created.
As for the link you provided, i would simply say author has his own view and personal way of working. In other words, this also depends which way you are most comfortable with or rather fast.
You can't write CSS before writing the HTML (except for the body tag!), or you'll be working like a blind.
For me, I make a mock-up of the website layout, write down the whole HTML and then write CSS that just makes the layout.
I use Expression design to slice images and add/modify HTML/CSS until I get the final template.
I don't like the idea of going back and forth with code. If I'm at #header in html, it seems pretty logical to me to stylize the header right now. Is good for my mental sanity :D
So I go with the second option: I wrote code simultaneously.
You have to write HTML before CSS.
Your question is like, Is it better to design a car Interior, before having a car ?
Is it possible ? or Is it a intelligent work ?
Given that most designs are not simple, and following basic semantical rules, you will always need to adjust the html code when trying to get the layout looking as you have in mind. So doing both simultaneously is probably the most pratical way, although the other two options work as well; You just need to made adjustments then later.
Sorry , I am not choosing anyone of these..
In first you can't able to write the whole css for your page. although it's better you should write the common css classes and page layouts in the first.ie, after creating the page layout , you just design the page using table or div tags. after , while adding controls to the pages , you just identify the common styles u are using. These styles you can use like css classes. or seperate id. I am following this method for my designing.
i think its better.
By creating the HTML first, you can guarantee what the page will look like on the most basic browsers - it'll be legible on an old phone, everything's in logical order, and you aren't forcing screen readers to recite your site navigation first thing on every single page. That's design #1.
Design #2 is the CSS part, where you actually make things look visibly decent without limiting your user base.
Not that they can't be done simultaneously, mind. Just that's most likely what the author of that article was trying to get at.
See also: Progressive Enhancement.
I personally write much of the CSS first, then HTML, then tweak the two together - one page at a time (apart from common elements). At first it sounds counter-intuitive, but when you think of the CSS as not only styles but as elements that either have a style or have a style of nothing, it's actually very fast and produces lean code.
Once I've got some core styles in place, the HTML is just a question of...
<wrapper>
<div header>
<div this>
<div that>
<form>
<div footer>
... and it all slots roughly into the styles and layout that I've already defined. For elements that needed no styling, I just mentally skipped over when writing the CSS.
My 3 cents:
What's the goal of the webpage? Most of the time that goal is strongly related to it's content.
Thus, the first thing is content. HTML gives content gets it's semantics. CSS gives the semantics a context.
So the order:
content
html
css
But of course, it's an iterative process.
I write them at the same time, iteratively, in modules.
I will build out the general template (or base template) in html/css, do a full cross-browser test, then move on to the additional templates.
This fits in well with .net where I'm using master pages and nested master pages.
I may change this behaviour once IE6 is off the books, as you often have to completely restructure your markup to accommodate it.
I'd go with the second option. HTML in todays web dev is seen as a template to hold content. CSS should be used to format the layout and content within the web page.
Because of this, HTML and CSS should be used parallel in creating web-pages and individual elements.