Screen readers will read out things like   when formatting a <title> tag to be clean for people that can see.
<title>contact • company</title>
Is there any way to make this less confusing?
I don't believe that it's technically invalid to include formatting like you're doing. That said, I'd question the utility of this approach for any visitor regardless of whether they are sighted or not.
If you want to make it less verbose, you could use unicode characters, but be aware that HTML does strip out extra whitespace, and the only way to make more than one consecutive space is to use the non-breaking-space ( ) character.
<title>contact • company</title>
As far as whether it's correct or not, the WHATWG HTML 5 specification states that the <title> element's content mode is "Text", however the definition of a Text content model states that it also includes Phrasing content.
The W3C HTML validator doesn't seem to complain about phrasing content being included in the title element. Search engines may handle this differently, and some may truncate your content based on length of characters or pixel widths.
Related
Is there a way to word wrap only when there's white space? Right now I have it breaking one some special characters (?-!) but I only want to it to break at the tabs to keep the columns straight.
Example:
gw5g7#IVKNcvP02r pFJxywU#B-L.Qp.f u#hGsrr8g.S4,GtR !t1oa(2%?tb()lML -cky!YT8-/*xsCfT nbjAekWZenH8udR8 sM*e#aSM#89C#$4Z (r6+$]1j9mw)U72+ !V2O2_UO7(mMM6HP o6u?D&97&QNJ93D1 .a,,hg%vtl[^PGLO F(v*CP#aJD13_m&. /9?[OL?ktCmv8gRP 6CSZuRuu98MT3*,R O/cclHD+HrG4G^h9 JI]edN.F]hRg8,&n -6S/S9U[Ai]Sh[8D LM+Gpkk7-BP1pgpR -XX4EZjb24Kl9Kgm j!eK#0?i&kwo&ADg lvZ#)T%xRFYOV#-.
No, there is currently no way in CSS way to word wrap only when there’s white space. The reason is that browsers apply, rather inconsistently, some of the Unicode line breaking rules. The rules allow line breaks at many points, e.g. after some punctuation characters in some contexts. In the CSS3 Text draft, there are some proposed additions that would let authors have better control over such issues, but mainly as regards to rendering East Asian languages.
You would need to wrap pieces of text in elements (like span) and set white-space: nowrap on them, or use the more concise nonstandard but widely supported nobr element. In the example case, this would be rather straightforward and could be done with a small piece of JavaScript code (or server-side or in a preprocessor when the page is generated):
<nobr>gw5g7#IVKNcvP02r</nobr> <nobr>pFJxywU#B-L.Qp.f</nobr>...
However, it is not clear whether the multiple spaces should be preserved and what the rendering context is (pre? textarea?). This is a different problem and best addressed as a separate question.
This question already has answers here:
Why should I use 'li' instead of 'div'?
(15 answers)
Are new HTML5 elements like <section> and <article> pointless? [closed]
(8 answers)
Why use HTML5 tags? [duplicate]
(1 answer)
Closed 9 years ago.
Why use HTML5 semantic tags like headers, section, nav, and article instead of simply div with the preferred css to it?
I created a webpage and used those tags, but they do not make a difference from div. What is their main purpose?
Is it only for the appropriate names for the tags while using it or more than that?
Please explain. I have gone through many sites, but I could not find these basics.
The Oxford Dictionary states:
semantics: the branch of linguistics and logic concerned with meaning.
As their name says, these tags are meant to improve the meaning of your web page. Good semantics plays an important role the automated processing of documents. This automated processing happens more often than you realize - each website ranking from search engines is derived from automated processing of all the website out there.
If you visit a (well designed) web page, you as the human reader can immediately (visually) distinguish all the page elements and more importantly understand the content. In the top left you see the company logo, next to it is the site navigation, there is a search bar and some text about the company, a link to a product you can buy and a legal disclaimer at the bottom.
However, machines are dumb and cannot do this:
Looking at the same page as you, all the web crawler would see is an image, a list of anchors tags, a text node, an input field and an image with a link on it. At the bottom there is another text node.
Now, how should they know, what part of the document you intended to be the navigation or the main article, or some not-so-important footnote? They can guess by analyzing your document structure using some common criteria which are a hint for a specific element.
E.g. an ul list of internal links is most likely some kind of page navigation and the text at the end of the document is something necessary but not so important to the everyday viewer (the legal disclaimer).
Now imagine instead of a plain div, a nav element would be used – the machine immediately knows what the purpose of this element is:
// machine: okay, this structure looks like it might be a navigation element?
<div><ul><li><a href="internal_link">...</div>
// machine: ah, a navigation element!
<nav><ul><li><a>...</nav>
Now the text inside a main tag – this is clearly the most important information of the page! Over there to the left, that text node, the image and the anchor node all belong together, because they are grouped inside a section tag, and down at the bottom there is some text inside a footer element (they still don't know the meaning of that text, but now they can deduce it's some sort of fine print).
Example:
You, as the user (reading a page without seeing the actual markup), don't care if an element is enclosed in an <i> or <em> tag. In most browsers both of these tags will be rendered identically – as italic text – and as long as it stands out between the surrounding text it serves its purpose.
However, there is a big difference in terms of semantics:
<i> means italic - it's simply a presentational hint for the browser on how to render it (italic) and does not necessarily contain deeper semantic information.
<em> means emphasize - it indicates an important piece of information. Now the browser is not bound to the italic instruction any more, but could render it in italic or bold or underlined or in a different color... For visually impaired persons, the screen readers can raise the voice - whatever method seems most suited in a specific situation to emphasise this important information.
Final thought:
Semantic tags are not the end. There are things like metadata, ontologies, resource description languages which go a step further and help connect data between different web pages and can even help create new knowledge!
E.g. wikipedia is doing a really bad job at semantically presenting data.
https://en.wikipedia.org/wiki/Barack_Obama
https://en.wikipedia.org/wiki/Donald_Trump
https://en.wikipedia.org/wiki/Joe_Biden
All three are persons who at some point in time where president of the USA.
All three articles contain a sidebar that displays these information, and you can compare them (by opening both pages and then switching back and forth), but they are not semantically described.
Instead, if wikipedia used an ontology to describe a person: http://dbpedia.org/ontology/Person
<!-- President is a subclass of Politician which is a subclass of Person -->
<President>
<birthname>Barrack Hussein Obama II</birthname>
<birthdate>1961-08-04</birthdate>
<headOf>country::USA</headOf>
<tenure>2009-01-20 – 2017-01-20</tenure>
</President>
Not only could you (and machines) now directly compare those three directly (on a dynamically generated page!), but you could even create new knowledge, e.g. show a list of all presidents of the United States - quite boring but also cool stuff like who are all the current world leaders, how many female world leaders do we have, who is the youngest leader, how many types of leaders are there (presidents/emperors/queens/dictators), who served the longest, how many of them are taller than 175cm and have brown eyes, etc. etc.
In conclusion, good semantics is super cool (but also – on a technical level – hard to achieve and maintain).
There's a nice little article on HTML5 semantics on HTML5Doctor.
Semantics have been a part of HTML in some form or another. It helps you understand what's happening where on the page.
Earlier when <div> was used for pretty much everything, we still implemented semantics by giving it a "semantic" class name or an id name.
These tags help in proper structuring and understanding of the layout.
If you do,
<div class="nav"></div>
as opposed to,
<nav></nav>
OR
<div class="sidebar"></div>
as opposed to,
<aside></aside>
there's nothing wrong, but the latter helps in providing better readability for you as well as crawlers, readers, etc..
In the div tag you have to give an id which tells about what kind of content it is holding, either body, header, footer, etc.
While in case of semantic elements of HTML5, the name clearly defines what kind of code it is holding, and it is for which part of the website.
Semantic elements are <header>, <footer>, <section>, <aside>, etc.
I'm working on an ASP.NET website that needs to be internationalized. I'm using .resx files (essentially key-value pairs in a file) to populate static string fields on a page in different languages depending on the chosen culture/locale. I'm implementing Japanese and getting some stubborn vertical strings.
When copy and pasting them into the .resx file, they are horizontal (source of strings is Google Translate, for testing purposes). All of the strings appear normal, but one always displays vertically. The misbehaving string is a few div's deep (like all of them) and only has font-size, font-family, color, and an uppercase transform applied to it.
Removing any or all of the above rules does not change the orientation of the text. I've cleaned the formatting off the offending text with Notepad and shortened it (to ensure it wasn't a length problem). I'm stumped as to why this particular string is stubbornly vertical.
Here is the text in question: ログアウト
(Translation: Logout)
Edit
Clarification of the issue.
What it should look like:
The vertical text in question:
How can I force vertical text to be
horizontal?
Other than the title, I don't really understand your question. I'll take a guess anyway.
Try adding white-space: nowrap to the div that's misbehaving.
Recently I was doing some learning about right-to-left on the web and learned that Unicode characters have a directional property associated with them at the character level. So this might have something to do with that, though I certanily wouldn't know how to ascertain that or fix it, especially given that Google Translate is the source of the strings.
It happens quite often for Asian scripts (not just Japanese but also Korean and Chinese) to have text rendered incorrectly. Usually you just need to play with element width, especially if it is part of HTML table.
What is the benefit to add null alt=""? is it only to pass validation or it has more reason
and how it should be write?
like this, no space
alt=""
or this with one blank space
alt=" "
To get your XHTML validated. The alt is a required attribute on images.
Adding it empty is however a sign of laziness from programmers (although I admit I also do it for images that are not key to site navigation like little decorative elements and so on).
P.S. If you have decorative elements like shadow components, certain ornaments you can add them not with images but as a CSS background, thus avoiding the need to write an alternative text and keeping your markup clean of non-content stuff.
Other answers have pointed out the requirements in the standard. Here is a practical example:
Given blank alt text, lynx will render:
Given a missing alt attribute, lynx will render:
filename.jpg
You don't want your content to have irrelevant filenames scattered throughout.
For images that have no suitable alternate text (i. e. pictures that don't carry any semantics, such as decorative elements), the alt attribute should be empty. Empty meaning empty, not a single space (which is a convention and recommendation but a good one).
The alt attribute must be specified for the IMG and AREA elements. It is optional for the INPUT and APPLET elements.
While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines:
Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead.
Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output.
Implementors should consult the section on accessibility for information about how to handle cases of omitted alternate text.
—HTML 4 specification. Section 13.8 How to specify alternate text
I'll add this as an answer as well (originally a comment on another answer), since it kind of makes sense to do so.
Images used for styling the page (and therefore has no real "alt" usage) should be inserted through CSS and background-image and its relatives, not through markup. That way you do two good things at once. You keep your design in your stylesheets, and you keep unsemantic code out of your page.
Although I do think the "semantics is god"-movement has failed to see the fail that is div and span, and the inherent ambiguity they produce, I still think a div with background-image is better than an img tag for styling.
How Screen reader behave with <hr> <b> <i> <big> <small> <br /> ?
I am a jaws user and tags such as
<b> <big>
etc are not read in any special way to distinguish them from the rest of the page by default. If you want to point out a specific region of a page follow the stackoverflow example and use headings. I can quickly go from question to question since they each have there own heading, and when viewing a question can quickly jump from the question to the answers. ANother good example of heading usage is the way that google reader gives each headline it's own heading.
Really depends on the screen reader. Typically they will ignore tags they're not expecting, read some tags and change the tone of text surrounded by others.
The best way to find out is to run it through the one you're intending to support. For example, JAWS (a widely used screenreader) has a 40 minute demo that you could use. Bear in mind that this will be different for other screenreaders.
The rule of thumb is to make sure your markup is as semantic as possible and also conforms to what users of screenreaders are expecting (trying to be clever or overly helpful can actually be counterproductive if it is different from every other site your visitors have been to).