Like many people I suspect, I have an existing website that I am trying to modify so it works well on much smaller mobile screens. I am happy to make a great deal of concessions in order to do this. However my main problem is the site's logo. Happy to swap it out for something small and static, but what I have in the original site is a Flash file for the logo. Yes, big mistake but then hindsight is a marvelous thing. What I have to deal with is a logo which is:
> * Specified in an external style sheet
> * Specified in an external XML file
> * Has additional hard coding in the HTML (size, placement etc)
> * Has an actual external Flash file too of course
So my historical decision to go with Flash has consequences in at least four different kinds of file as well as every HTML and PHP page in the site.
My question then is what is the minimally disruptive way I can modify the existing site to specify something smaller and simpler than I have at the moment? I am happy to not have the Flash file feature in the mobile site, if that helps. Thank you.
I found the answer in a web technology I was not previously familiar with called "media queries" and I urge anyone unfamiliar with the concept to Google it and find a good primer. In a nutshell, media queries allow you to insert a section in your style sheet that queries the maximum (or minimum) screen resolution of the device your site is being viewed on and specify an alternative set of styling instructions for that event. It's like introducing an If/Else construct to your style sheet.
In my case I simply created an alternative logo - smaller and a static .jpg image. Then I worked out the screen size threshold below which I wanted the smaller logo to appear in, and then wrote my media query, which looks like this:
#media screen
and (max-device-width: 1023px) {
#flashContent { display:none; }
#altlogo { background-image: url("/images/mobile_logo.jpg"); width: 318px; height: 43px; margin-left: 2%; margin-bottom: 1px;}
}
The first part says not to show the Flash logo, while the second specicies an alternative. Of course you also need to create a hook inside the HTML for this to operate, hence adding the following div right after the original flashContent div:
<div id="altlogo" role="img" aria-label="My Smaller logo"></div>
Note I don't want to stray too far from my original question into the realms of an extensive introduction to media queries, but I will add that the parameters to my additional div serve as a way round the accessibility issue of being unable to add an 'alt' tag to the substitute logo image. Screen readers will detect and read out these parameters in lieu of an alt tag. There are other issues unaddressed here such as loading two logos when you only display one, but these are completely solvable issues that are beyond the remit of my original question to address here which I leave to interested parties to research.
Related
I'm just learning html and css and have just completed a landing page project. When I reviewed my css at the end, I realised that I had multiple media queries all for the same conditions (max-width) but applied to different elements.
I know that you can put multiple elements within a media query but what is best practice?
Currently I have each separate media query located just after the setup css for that element
i.e. #header is followed by #media (max-width:640px) #header{stuff;}}
Media queries were introduced in CSS3 are used for responsive CSS over different media types. Since usually the CSS code itself is applied for describing the presentation of the document or page, responsiveness is a separate feature altogether, so usually they are kept separate at the end of the CSS formatting codes. However, let me answer this question by stating the usage of both of the formats mentioned in the question.
At the end of code
Most templates of CSS available online usually keep their media queries at the bottom of the entire code making it easier to access and work with the responsiveness feature. Whenever the focus is more on "chasing device-widths" then this type of coding practice helps.
As observed, this allows to group together many basic CSS attributes that are applied over many elements.
Also, considering the cascading nature of CSS, the styling below usually (not always, refer this to know more) overwrites the styling present above. With #media queries present at the bottom of the stylesheet, it allows easy overwriting of relevant styles present above.
Finally ,as mentioned by #rguttersohn, media queries along with #keyframes are kept at the end with #keyframes usually above #media. This makes coding cleaner and easier to comprehend by others as well.
Below relevant styling counterparts
If styling is more layout-centric, it's highly useful to place #media queries next to their styling counterparts. This allows ease in editing the style and its corresponding #media query both in a single go.
This does mean that there is slightly more code, but these too can be cut down by grouping at breakpoints and section ends.
This type of styling is rarely seen in templates available online, however it's an ongoing trend.
To Summarize: I personally am of the opinion to keep all of the #media queries together at the bottom, but if I had to divide the labor of styling, I would opt for keeping the styles and #media queries together.
Also, given the broad and opinionated scope of this question, I think no answer can determined as right or wrong. I hope this answer brings enough light and information to the question.
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 trying to figure out if there's a way to achieve sane printing straight from HTML. Our users often want to print a few pages for their own records. The printouts contain Google Charts and the grid is handled by bootstrap. Very frequently we want a set of content per page and thus page breaks are very much required.
Traditionally we've used print media queries, but it's been nigh impossible to achieve consistent results across browsers, say Firefox, Chrome and Mobile Safari etc. Pieces will spill over, page breaks will be ignored etc.
Some companies like Amazon and Newegg provide customers with the ability to print out invoices and other pages. It seems that usually that involves having a separate print-only version of the content that's either all tables or very simplified -based markup that looks extremely basic when printed out. Generally there's little to no styling, few if any images, definitely no and no page breaks as far as I can tell.
Another option is to just convert everything to PDF, but that has its own pitfalls and expenses. Now you have to re-generate the same content in a second format for every page that needs to be printed, and perfectly styling PDF is non-trivial as well.
Is there anything out there can can help with this? Any commonly accepted solutions?
We use wkhtmltopdf and PrinceXML to get consistent styling. Both are command line tools that can take a URL plus a custom CSS file. They generate consistent output, and are browser independent, because they are the rendering engine.
We used to use wkhtmltopdf, but we're starting to move to PrinceXML because it supports margin-boxes and two-column layout. (The main caveat with PrinceXML is the price.)
Perfectly styling PDF doesn't seem any worse or harder than styling for web display. My experience is that it takes an hour or two to get a print page styled correctly. I've never tried to handle Google Charts.
All of the popular desktop browsers now support the CSS #page rule for setting page margins, and the CSS properties page-break-inside, page-break-before, and page-break-after for handling page breaks. These will generally provide enough control to achieve consistent cross-platform printing, but there are a few things that only one or two of the browsers can do. Some examples are:
page numbering
running page headers and footers
orphan/widow control
control of background colors
If you need any of those things, PDF might be your best option; otherwise, it might be overkill. A PDF converter isn't going to automatically determine the ideal way to paginate whatever content you throw at it; human judgement will still be required.
That doesn't mean you need to explicitly declare the location of every page break, though. It's usually a lot easier to prevent bad pagination than to force good pagination. In other words, instead of telling the browser where you do want page breaks, tell it where you don't want them.
Examples of places you might want to prevent page breaks:
between a section title and the first line of section text
between a table's column headers and the first row of data*
between closely-related form fields.
The go-to CSS declaration in these situations is page-break-inside: avoid;**. It would be easier to use page-break-after: avoid; in the first two examples, but Firefox only supports the always and auto values for that property. So instead, you have to create an unbreakable div that contains or overlaps the stuff you want to keep together. Here's one way to do it:
<style>
.section {
line-height: 1.25em;
}
.title {
page-break-inside: avoid;
padding-bottom: 1.25em;
font-weight: bold;
}
.overlap {
margin-bottom: -1.25em;
}
</style>
<div class="section">
<div class="title">
Title of This Section
</div>
<div class="overlap">
</div>
This is the section text. It could be any length, so we have to
allow page breaks in it. However, we don't want the first line to
be separated from the section title. The title is unbreakable, so
we just need to add some bottom padding to it and make it overlap
the first line of text.
</div>
*Tables are probably the most challenging thing to print consistently across browsers, but it is possible.
**Old versions of Firefox, Chrome, and Safari don't support the CSS declaration page-break-inside: avoid;, but you can achieve the same effect with display: inline-block;, if needed.
I am building a responsive website using media queries. I need to switch to a different navigation method for very small screens.
For desktop/tablet screens, I am using a sprite based UL/LI list method. For small smart phone screens, I will have simple link text.
If I use, Display: none; to hide the sprite based navigation for smart phones, will the sprite image still be loaded, but just not shown? Do I need to parse the image reference in my css media query for smart phones? Or should I just leave the image reference out of the initial css altogether since I am designing small to large (i.e. the default css is for small screens, and then media queries change things as the screen gets larger).
To answer your question, display: none does not reduce load time. It still loads the content/classes/code in question, but the browser doesn't display/render them.
It sounds like you're using a mobile-first approach, so you could either:
Load all assets/classes/scripts regardless of mobile/tablet/desktop class you're aiming for and adapt the layouts using your media queries.
This means all content (sprites et al) will be loaded by default even if they aren't used by certain device-types.
Content/layout will either be shown or hidden based upon media query rules.
Load the required assets/classes/scripts as and only when the media query states change. The advantage of this is that the experience would be more relative the the device-type in question:
More reactive/timely experience and loading of functionality
Potentially less bandwidth
A more tightly design experience for each device-type
Some assets (images/backgrounds etc) can be selectively loaded
If you consider looking at option 2, then there are a variety of open-source asset-loaders that allow you to load CSS and Javascript code based upon media query state changes. [Note: More effort/design would be required to use this technique].
A simplified example of this using enquire.js (there are others asset loaders) would allow you to do the following:
<script type="text/javascript">
// MQ Mobile
enquire.register("screen and (max-width: 500px)", {
match : function() {
// Load a mobile JS file
loadJS('mobile.js');
// Load a mobile CSS file
loadCSS('mobile.css');
}
}).listen();
// MQ Desktop
enquire.register("screen and (min-width: 501px)", {
match : function() {
// Load a desktop JS file
loadJS('desktop.js');
// Load a desktop CSS file
loadCSS('desktop.css');
}
}).listen();
</script>
So, if a browser is 501px or above in width, then both desktop.js and desktop.css would load - enabling features/assets that aren't available under 501px and that aren't required.
All items will be loaded, but not displayed to the end user.
I searched for the same question and can't agree with nickhar's words:
display: none does not reduce load time
I made speed tests and with display: none DOM loading 2 times faster.
But +1 for useful advices.