using SharePoint 2010 web editor
I created a (sub-menu) page with title CO<sub>2</sub>. When rendered in browser, the title of the page is: CO<sub>2</sub> whereas the menu item shows CO2.
Apparently it is escaping the HTML tags in page but rendering correctly inside the menu.
How to make the page title looks same as menu item?
No tags are recognized in a title element by HTML rules (and by browser practice); they are indeed rendered as such. In principle, you can use special characters like “₂” SUBSCRIPT TWO U+2082 in a title element. You can even denote them using character references:
<title>CO₂</title>
However, only some fonts support SUBSCRIPT TWO, and it is quite possible that the rendering of title elements e.g. in a browser top bar or tab label uses a font that does not support to it. In that case, a rectangle, vertical bar, space, or other generic indicator of missing glyph probably appears.
Note that the appearance is usually not quite the same as in the menu, since browsers implement sup by reducing font size and putting the glyph in a lower position. Only by accident would this coincide with the design of “₂” in a font. But if the texts are displayed in two different fonts, as they probably are, this is usually not a serious problem.
Related
I recently created a web page that uses HTML5 and CSS3 to draw a bar graph. This is my first time doing this, and I followed the instructions given here: http://www.htmlgoodies.com/html5/tutorials/bar-graph-with-css3-and-progressive-enhancement.html#fbid=gG6mmpDnQDn
The long and the short of it is to create a DIV tag for each bar and use CSS to set the size and color of each bar. Specifically, use the background-color CSS attribute.
This works great until the user prints the page, and I do expect the page to be printed many times.
The problem is that web browsers typically omit background images and colors from the printed version of the page. This results in the bars not printing at all!
Chrome allows the user to check a box indicating that background images and colors should print, but it isn't practical for me to say, "To print this, use Chrome and be sure to check that box yada yada yada."
One stop-gap measure I've deployed is to use CSS to specify that when the document is printed, a border should be drawn around the bars, but this is just a border; it doesn't fill the bar at all.
How can I make a bar graph with HTML5 and CSS3 that will print correctly under most browser configurations.
Add this style for Chrome:
:root {-webkit-print-color-adjust: exact;}
That reduces your user instructions to simply, "To print this, use Chrome."
Otherwise, you may need to resort to SVG like #MiltoxBeyond suggested.
I am trying to insert a placeholder icon into a select2 input field.
View on desktop:
View on mobile:
Here is the code I use to integrate font awesome using unicode, to place the icon in a input field.
jade (element in which I initialize the select2 on)
#tags.icon(type="text", name="tags", placeholder= " tags...")
and CSS
.select2-input, #searchPosts
font-family 'FontAwesome'
The weird thing is, when I click into the input field, type and then clear the typing, and click outside, the tag icon shows correctly. But it does not show correctly on load.
Font Awesome and other icon sites often have compatibility issues across various different platforms. You should have back up options if unicode appears - such as a sprite.
Often mobile browser encoding is different to web version of the browser.
There are many ways to handle this and this article is a good place to start:
http://www.creativebloq.com/app-design/icon-fonts-in-apps-21410734
Without debugging it I'd say you're experiencing a z-index issue or an actual engine rendering mistake. Try setting the value later if you can. If you know the placeholder text is achieved through a dom element addition, try increasing its z-index. Good Luck.
Is it true that there are semantically correct & incorrect ways of displaying pictures/icons?
I mean of course it's not very friendly to include all pictures of a newspaper article as background images because that way, screen readers can't read out the alt text, but what about icons or user interface elements? Is it justifiable from a semantic oriented point of view to include these as background-images?
There are some semantically correct and incorrect ways of displaying different kinds of images.
Normal images It's better to use standard <img> tags, because they are often the main content of a site. These should have alt tags to inform users about important parts of content.
Icons are a kind of image which isn't the main content of your site, but they should also be displayed by using <img> tags because it's important for usability to show what specific icons do if it's not displayed correctly.
Not important pictures which make the site nice and are not main content of the site should be displayed as background, because then you do not use unnecessary Nodes in your DOM.
I don't think you should include icons as an separate element just representing that icon; e.g. an img or i.
Instead each icon represents a specific function – therefore you should use an element that could be used for that functionality, e.g. an anchor a or a button. Each of those elements should have a non-graphical content that could be parsed by screen readers and web spiders. You could then beautify those elements by using background images for some graphical icon.
Using separate markup for icons is a semantic error/mistake. The icon itself does nothing. It's just there to memorize the function of the underlying element. But in fact those elements are still there when you remove the icon.
So yes, I always would include icons as background images to an element directly or to a generated pseudo element.
Why do images defined in CSS (like backgrounds, lists marker, ...etc.) not behave in the same way in the browser as HTML images? For example, they can't be selected by the mouse, and you can't right click on them.
Images are generally used in CSS for one thing, backgrounds. Which means they aren't used for the same things HTML images are being used for (displaying the actual image as part of the content).
When an image is part of the content, it can be saved and copied etc, because it
is likely to be considered interesting by the reader. Backgrounds (or list-markers etc) however, are less likely (unless the reader is a developer) to interest the reader enough to want to copy them. Instead, the focus is on the actual content of the element (which the background was applied to).
I guess it is a question for browser vendors why they allow certain behavior only when dealing with <img> tag.
However, you can use dev tools/Firebug/whatever and you can download the image file.
Is it possible to print a HTML page with truly absolute positioned elements to paper? It seems all browsers are doing a big mess here. It is easy to define a body by absolute units (eg. cm) and place elements by position: absolute inside. However, every browser seem to try to make it impossible to print such a page. FF for example is adding print margins, even when printing to a PDF on linux despite 0-margin page settings. Chrome seems to shrink the page in every case.
So how to print something with absolute positioning, eg. paper form fields, markings etc.?
Have I overlooked something?
Sadly, the CSS3 Module: Paged Media allows all this to happen. This are the rules concerning pages which are too big:
3.3.3. Rendering page boxes that do not fit a page sheet
If a page box does not match the target page sheet dimensions, the user agent MAY choose (in order of preference) to:
Render the page box at the indicated size on a larger page sheet.
Rotate the page box 90° if this will make the page box fit the page sheet.
Scale the page box to fit the page sheet. (There is no requirement to maintain the aspect ratio of the page or of any elements on the page when scaling; however, preservation of the aspect ratio is preferred.) [done by Chrome]
Reformat the page contents, including 'spilling' onto other page sheets. [done by many other or older browsers]
Clip overflowed content (least preferred).
The user agent should consult the user before performing these operations.
3.3.4. Positioning the page box on the sheet
When the page box is smaller than the page size, the user agent should center the page box on the sheet since this will align double-sided pages and avoid accidental loss of information that is printed near the edge of the sheet.
And this is the rule which breaks all your positioned stuff:
3.7. Content outside the page box
[...] Also, when boxes are positioned absolutely, they MAY end up
in "inconvenient" locations. For example, images MAY be placed on the
edge of the page box. Similarly when boxes use fixed or relative
positioning, they MAY also end up outside of the page box.
A specification for the exact formatting of such elements lies outside
the scope of this document. However, we recommend that authors and
user agents observe the following general principles concerning
content outside the page box:
User agents SHOULD avoid generating a large number of empty page boxes to honor the positioning of elements (e.g., you don't want to
print 100 blank pages). Note, however, that generating a small number
of empty page boxes MAY be necessary to honor the 'left' and 'right'
values for 'page-break-before' and 'page-break-after'.
Authors SHOULD not position elements in inconvenient locations just to avoid rendering them. Instead:
To suppress box generation entirely, set the 'display' property to 'none'.
To make a box invisible, set the 'visibility' property.
User agents MAY handle boxes positioned outside the page box in several ways, including discarding them or creating page boxes for
them at the end of the document.
Have a look at the second paragraph of section 3.7: A specification for the exact formatting of such elements lies outside the scope of this document. Since there is no other document and no other guideline then the general principle following this paragraph, every browser can do whatever it want.
It's one of the flaws that are currently in this CSS3 module. However, I think those flaws cannot be removed by a CSS4 or revised CSS3 module, as the variety of possible stylesheets and resulting layouts is too huge too cover. Also note a little footnote given in CSS Print Profile:
‡ The printer MAY ignore positioned elements that are placed on the page before the position of the current element in the normal flow.
So it's basically not possible to create the same effect in every browser. As for the time being, the only possible way to achieve a portable document is to create a PDF with a third-party application or via a PDF printer and your most favorite browser. Every other way is bound to fail as long as either the W3C's recommendations aren't strict or the browser vendors implement whatever they want.
See also:
CSS3 Module: Paged Media (Working draft, last revision 2006)
CSS Print Profile (Working draft, last revision 2006)
Additional notes
If you have a bunch of position:absolute elements which need to be printed it's sometimes a good question whether an element actually needs to be positioned absolute, or if the same effect can be achieved in a slightly different or easier way. Also note that you should use display:none on each element that isn't truly needed for the printed media, such as ads, navigations, etc...
As you say, web browsers tend to do crazy things when printing. Print-oriented engines are often better.
WeasyPrint is an open-source engine that renders to PDF and supports absolute positioning as well as CSS 3 Paged Media to set the page margins:
#page { margin: 1cm /* or 0, if you want */ }
Make your container to have relative position. That's the only way to keep absolute positioned elements in the same place at every screen and paper. so if your main div (the div where all of your content is located) add following to your css:
#maindivname{position:relative;}
Should do the trick.
I have tested browser status for printing "position:absolute" elements with the following results:
IE 11: Fail. Doesn't matter what OS, 7,8,8.1.
IE 10: Pass. However, you cannot revert to 10 on 8.1 so folks with that are stuck.
Firefox up to 38.05 = Fail. Unknown if any version ever worked.
The good news is that it looks like the Blink/WebKit people did their homework instead of using poor code.
Chrome: Pass
Opera: Pass
Media Queries will do the trick -- check this link and previous question out, maybe it will help.
Suggestions for debugging print stylesheets?
Media Query transitioning px into inches/cm/whatever needed for printing requirements.
That border/margin you mentioned is probably your printer's printable area (the grip edge). Most printers need some type of edge to grab and feed the stock. That's why when one prints a full-bleed document (ink to the very edge), it's printed on stock larger than needed, then trimmed down.
set the margin with page setup is the first and primary solutions for printing the HTML page or a DIV .
After all not expected result will come then you need some digs on your HTML page.
Make a window without title bar or any custom bar using java script.And put all Original data into that window with a position:relative and also set the media type as print.
position:relative;
media:print;
Hope it will helpful.
Use in CSS this property:
body{
-webkit-print-color-adjust:exact;
}
This help positions absolutes and backgrounds in tables.