I have a website with newspapers frontpages so pages contain only big images and no text (neither description, because images change daily).
What's the best way to insert context keywords in the pages?
Is correct insert in body only keywords without link?
if you can change image names put keywords in those & also use related words, synonyms, plural / singular
also add alt & title attributes
Even though your pages do not have any content (only images), you still can provide proper page descriptions which will be used by Google (and other search engines).
A couple of handy tips:
Create unique, accurate page titles using <title> tag placed within the <head> tag.
Please bear in mind that Google does not recommend putting keywords into the title tag. So it is very good practice to make sure that your title effectively communicates the topic of the page's content.
Use the description meta tag (<meta name="description" content="">) to gives any search engine a summary of what the page is about. It is very good practice to use unique descriptions for each page.
Use the keywords meta tag (<meta name="keywords" content="">) to give page related keywords.
Also, as far as images are concerned, I would recommend using proper use of alt and title attributes providing description of your image content. Image names can sometimes be composed of some identifiers which are meaningless for customers.
Please have a look at Matt Cutts Blog page: Gadgets, Google, and SEO where Matt describes in details importance of correct informations in alt and title attributes of an image tag.
Related
I have a lot of ASCII docs at different locations and I want to create an index page which should render these documents. But the condition here is that I want to list all the document link on the index page and if the user clicks on any link then only the document should be displayed. I don't want to display the documents below the table of content. I just want to display the table of content on the index page.
Is there any way to do this?
If I understand you correctly, you wish to generate a multi-document website, but you want an index page that displays just the TOC, with the other documents served elsewhere. I believe the best way to get this effect would be to generate chunked XHTML output using the DocBook toolchain. I believe this should be possible with Asciidoctor tools, but I have only implemented this particular post-rendering toolchain with the original (Python-based) AsciiDoc rendering tool, as documented here. This setup is configurable to generate a TOC index page that links to chunked output (you can configure the level of chunking).
As you have already figured out, AsciiDoc's automated TOC generation only works on the present document, which requires including the subordinate document to get their headings for the TOC. I can think of ways to sort of game this, such as to include just the heading of the included document (include::path/to/document.adoc[lines=1]) and then hiding even those headings with CSS or something. The problem is, the links in the TOC will be pointing internally, so you'd need to handle that somehow.
Another way is to use any of the static-site generators that support or can be readily extended to support AsciiDoc. What you're talking about is not an out-of-the-box feature that I'm aware of, but they all at least make it possible to generate an organized TOC-type navigation.
I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
I'm trying to use markup tags to link to info pages within the "description" attribute of a product. However, it's not giving me a clean URL path when the description is printed to the page.
Trying:
Contact Us
does not give the expected url. I've confirmed i'm doing this outside of WYSIWYG mode too.
When the text is rendered is returned to the browser as this html:
Contact Us
A resulting click on the link then ends up as:
http://example.com/prod-category/my-product/%7B%7Bstore%20url=
From what I can tell the markup tags aren't designed to be used in this way. Is it possible to extend it so it could work? Otherwise I guess I need to include the actual URL in the description?
Thanks for suggestions.
You can´t use the double-curly syntax because the attributes value is not being processed by magento´s template filter, which does the magic. You can use them e.g. in CMS or email Templates out of the box.
Right now, I see a lot of website they use text logo replace image logo. What is different between text and image on the our website? If you any one have any idea please share.
Example:
http://getbootstrap.com/
https://ghost.org/
Inspect element on logo for both websites above. I saw they use text not image for they logo.
A good reason to use text instead of an image is SEO (search engine optimization).
Search engines will look for text in the <h1> element as one of the strongest indicators for what the page contains. If you don't have an <h1> element, or if it just contains an image, the search engine will be less sure of what the page contains.
Pages with a <title> and an <h1> that are at least partially equal, have a better chance to make good search results.
One way to have a nice image as logo and still present the text to the search engines, is to put text in the <h1> element, then use CSS to hide the text and show an image instead.
How would you solve this problem?
You're scraping HTML of blogs. Some of the HTML of a blog is blog posts, some of it is formatting, sidebars, etc. You want to be able to tell what text in the HTML belongs to which post (i.e. a permalink) if any.
I know what you're thinking: You could just look at the RSS and ignore the HTML altogether! However, RSS very often contains only very short excerpts or strips away links that you might be interested in. You want to essentially defeat the excerptedness of the RSS by using the HTML and RSS of the same page together.
An RSS entry looks like:
title
excerpt of post body
permalink
A blog post in HTML looks like:
title (surrounded by permalink, maybe)
...
permalink, maybe
...
post body
...
permalink, maybe
So the HTML page contains the same fields but the placement of the permalink is not known in advance, and the fields will be separated by some noise text that is mostly HTML and white space but also could contain some additional metadata such as "posted by Johnny" or the date or something like that. The text may also be represented slightly different in HTML vs. RSS, as described below.
Additional rules/caveats:
Titles may not be unique. This happens more often than you might think. Examples I've seen: "Monday roundup", "TGIF", etc..
Titles may even be left blank.
Excerpts in RSS are also optional, but assume there must be at least either a non-blank excerpt or a non-blank title
The RSS excerpt may contain the full post content but more likely contains a short excerpt of the start of the post body
Assume that permalinks must be unique and must be the same in both HTML and RSS.
The title and the excerpt and post body may be formatted slightly differently in RSS and in HTML. For example:
RSS may have HTML inside of title or body stripped, or on the HTML page more HTML could be added (such as surrounding the first letter of the post body with something) or could be formatted slightly differently
Text may be encoded slightly differently, such as being utf8 in RSS while non-ascii characters in HTML are always encoded using ampersand encoding. However, assume that this is English text where non-ascii characters are rare.
There could be badly encoded Windows-1252 horribleness. This happens a lot for symbol characters like curly quotes. However, it is safe to assume that most of the text is ascii.
There could be case-folding in either direction, especially in the title. So, they could all-uppercase the title in the HTML page but not in RSS.
The number of entries in the RSS feed and the HTML page is not assumed to be the same. Either could have more or fewer older entries. We can only expect to get only those posts that appear in both.
RSS could be lagged. There may be a new entry in the HTML page that does not appear in the RSS feed yet. This can happen if the RSS is syndicated through Feedburner. Again, we can only expect to resolve those posts that appear in both RSS and HTML.
The body of a post can be very short or very long.
100% accuracy is not a constraint. However, the more accurate the better.
Well, what would you do?
I would create a scraper for each of the major blogging engines. Start with the main text for a single post per page.
If you're lucky then the engine will provide reasonable XHTML, so you can come up with a number of useful XPath expressions to get the node which corresponds to the article. If not, then I'm afraid it's TagSoup or Tidy to coerce it into well formed XML.
From there, you can look for the metadata and the full text. This should safely remove the headers/footers/sidebars/widgets/ads, though may leave embedded objects etc.
It should also be fairly easy (TM) to segment the page into article metadata, text, comments, etc etc and put it into fairly sensible RSS/Atom item.
This would be the basis of taking an RSS feed (non-full text) and turning it into a full text one (by following the permalinks given in the official RSS).
Once you have a scraper for a blog engine, you can start looking at writing a detector - something that will be the basis of the "given a page, what blog engine was it published with".
With enough scrapers and detectors, it should be possible to point a given RSS/Atom feed out and convert it into a full text feed.
However, this approach has a number of issues:
while you may be able to target the big 5 blog engines, there may be some blogs which you just have to have that aren't covered by them: e.g. there are 61 engines listed on Wikipedia; people who write their own blogging engines each need their own scraper.
each time a blog engine changes versions, you need to change your detectors and scrapers. More accurately, you need to add a new scraper and detector. The detectors have to become increasing more fussy to distinguish between one version of the same engine and the next (e.g. everytime slashcode changes, it usually changes the HTML, but different sites use different versions of slash).
I'm trying to think of a decent fallback, but I'll edit once I have.
RSS is actually quite simple to parse using XPath any XML parser (or regexes, but that's not recpmmended), you're going through the <item> tags, looking for <title>, <link>, <description> .
You can then post them as different fields in a database, or direcrtly merge them into HTML. In case the <description> is missing, you could scrape the link (one way would be to compare multiple pages to weed-out the layout parts of the HTML).