I need to change my font family in my Matheditor but I am getting this,
error: "'fontfamily' is deprecated in MathML 3, superseded by 'mathvariant'",
Can any one solve this for me?
fontfamily is deprecated since MathML 2.0 (2003).
It is normally discouraged to set font properties within math markup.
As the standard says (MathML 2.0):
"direct manipulation of these rendering properties by whatever means should usually be avoided".
Link to some explanation:
http://www.w3.org/TR/MathML2/chapter3.html#presm.deprecatt
font attributes are usually (if at all) set by / for the renderer. However, my experience is that tweaking fonts by whatever means is a bad idea. Default settings work best with virtually all renderers.
Related
The W3C maintains an excellent list of all CSS properties, both current and proposed. Of the 115 properties marked as CSS 2.1, sixteen of these are not part of any CSS module (for level 3 and above). These are:
azimuth,
elevation,
line-height,
page-break-after,
page-break-before,
page-break-inside,
pitch,
pitch-range,
play-during,
richness,
speak-header,
speak-numeral,
speak-punctuation,
speech-rate,
stress,
volume
Now I'm aware of the W3C statement, from CSS Snapshot 2015 that states "Each module adds functionality and/or replaces part of the CSS2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS2.1 specification: only that they will add functionality and refine definitions." However there seems to be no upgrade path or list of deprecated properties.
I'm pretty sure modern browsers, will, for backward-compatibility reasons, choose to honor the well-defined and stable CSS 2.1 properties. But someone (perhaps the folks in charge of a particular module) decided that the CSS 2.1 properties were clunky, hacks, or otherwise did not fit into the clean world of CSS 3 modules.
For example, I searched the CSS Speech Module looking to see whether speak-numeral (one of the missing 16) was mentioned. It wasn't, but I found speak-as which appears to capture the same functionality.
So the programming and programming-related questions here are:
Why are these 16 properties not marked deprecated?
Is there an "upgrading to CSS3" guide somewhere?
What is the appropriate strategy for new web applications? Do we continue to use these old properties until the module makes Recommendation status and/or they get better browser support? Is it a good idea to use both properties (old and new) in a style sheet?
Let's take one example, I suspect by far the most commonly used of those listed, line-height.
The CSS Inline Layout Module Level 3, Section 2. Line Heights and Baseline Alignment says
This section is being rewritten. Refer to section 10.8 of [CSS2] for
the normative CSS definition or the 2002 Working Draft if you want
pretty pictures. (But ignore the old text, half of it’s wrong. We’re
not specifying which half, that’s to be determined.) The CSS2
specification should be used as the guideline for implementation.
So it's not deprecated, it's just that the description from level 2.2 holds until such time that a level 3 definition can be written. Level 3 is huge, and work has to be prioritized. Line-height obviously works well enough for that priority to be low. No doubt, it will be addressed eventually.
The others are probably similar. Their level 2 definitions have simply not yet been superseded.
Why don't browsers autocorrect CSS3 transitions? The only difference between the Safari/Chrome and Firefox CSS transition is "moz" and "webkit". Surely firefox could just add an autocorrect feature to change every instance of "webkit" in the css to "moz" and the problem would be solved. Or is there something more?
Normally the -moz and -webkit are for CSS selctors are properties that are are specific to the the browser engine. The selector could be unstable, or act differently in each browser as they refine the behavior.
They don't want to "autocorrect" to the other implementation because the other browsers interpretation of the CSS property could be different. It could cause problems about what CSS property should "win" in the event of a conflict. Lastly, it could increase development time for each browser since they would need to figure out what the other browser engine is doing.
In the end what you want is to not use any -* prefixes at all. For that to be possible there needs to be a standard syntax and behavior defined by the, wait for it, CSS standard. Then instead of repeating *-opacity: ... several times with different prefixes, you just write opacity: ... once, like any other CSS declaration.
Vendor specific prefixes are there to allow browser specific behavior regardless of what the current standard says. It allows vendors to implement new features for which no standard exists yet, or to test the implementation of features before committing to it. The end goal is always to implement all features defined by the standard in the way the standard defines it; but you won't get there over night. New features need to be tested as widely as possible to find problems with their implementation or possible problems in the standard itself. This testing happens by making features available through vendor specific prefixes.
When you use a documented standard feature like opacity, it's pretty sure that it works consistently across browsers (*cough*letsforgetabout*cough*IE*cough*forasecond*cough*). When using a vendor specific prefix feature, it means you're using a feature at your own risk which is subject to change and/or may not work consistently (yet). Browser vendors don't touch each others prefixes for a reason, they work towards the standard and eventually make the feature available without prefix.
I noticed this woo theme for example has it set on the HTML tag and therefore the whole site's text has it set. I read that it can cause performance problems but that was a while ago. Some people suggested only adding it to headers and big text.
Have the rules changed now? Do browsers perform well with it?
No: there have been many bugs over the years on various platforms which cause text not to be displayed or displayed incorrectly (see below). If your goal is to enable ligatures, there's actually standard property font-variant-ligatures defined in CSS Fonts Level 3 which offers full control:
font-variant-ligatures: common-ligatures;
font-variant-ligatures: common-ligatures discretionary-ligatures historical-ligatures;
See font-variant for other typographic features which can be enabled such as small caps, alternate letter forms, etc.
History
Before font-variant-ligatures & the related properties were added, the older font-feature-settings property allowed the same feature to be enabled. This is a lower-level interface and is no longer recommended except to enable OpenType features which do not have a higher-level interface.
http://blog.fontdeck.com/post/15777165734/opentype-1 has a simple example:
h1 {
-webkit-font-feature-settings: "liga", "dlig";
-moz-font-feature-settings: "liga=1, dlig=1";
-ms-font-feature-settings: "liga", "dlig";
font-feature-settings: "liga", "dlig";
}
http://elliotjaystocks.com/blog/the-fine-flourish-of-the-ligature/ has more discussion as well.
Bug Gallery
The popular HTML5 Boilerplate project removed it two years ago due to various rendering problems:
https://github.com/h5bp/html5-boilerplate/issues/78
Two Chromium bugs which I just fixed this morning caused Chrome 21 on Windows XP to either fail to perform font substitution at all, displaying the missing character symbol rather than using one from a different font, and displaying text incorrectly overlapping other elements:
http://code.google.com/p/chromium/issues/detail?id=114719
http://code.google.com/p/chromium/issues/detail?id=149548
See http://aestheticallyloyal.com/public/optimize-legibility/ for a few other concerns.
http://bocoup.com/weblog/text-rendering/ highlighted compatibility problems on Android and general performance issues
from the MDN text-rendering page, last updated on 18:27, 29 Apr 2012, it reads:
The text-rendering CSS property provides information to the rendering engine about what to optimize for when rendering text. The browser makes trade-offs among speed, legibility, and geometric precision. The text-rendering property is an SVG property that is not defined in any CSS standard. However, Gecko and WebKit browsers let you apply this property to HTML and XML content on Windows, Mac OS X and Linux.
which tels us that it is not defined in any CSS standard, thus leading to cross-browser issues, as seen on the Browser compatibility table.
By default
The browser makes educated guesses about when to optimize for speed, legibility, and geometric precision while drawing text.
So, is safe to assume that the best option is to let the browser take care of details like this, since this feature is not a standard (yet), and most browsers don't support it.
text-rendering: optimizeLegibility; was used in one of our web apps. it rendered properly in all browsers, except one - chrome (64) on windows 7.
Had to remove the property as most of our end users were from that category.
I've just fixed a bug where Chrome was refusing to render web fonts (it always fell back to a non-web one, for no reason we could discern). In the end - after considerable amount of head-scratching - the problem was fixed by setting text-rendering from optimizeLegibility (which had been set by Twitter Bootstrap, for what it's worth) to auto.
So I would say for the moment the answer is probably "no". Which isn't to say don't use it, but don't apply it to everything. Use it where needed and test it carefully for weirdnesses or unexpected effects (especially in Chrome!).
using "text-rendering: optimizelegibility" also causes rendering errors in android native browser (4.2 & 4.3). If you use this attribute in combination with loading new fonts via #font-face, the font will not display at all (only fallback). without "text-rendering: optimizelegibility" and #font-face the font loads and gets displayed as expected.
CSS text-rendering looks shaky. Instead of grinding time with a poor CSS property, it may be worthwhile to go with this...
If Javascript is an option for you, Kerning.js looks promising, a javascript approach to kerning and kerning pairs hosted on Github.
http://kerningjs.com
Also worth noting, if you are getting serious about typography, there is Font Squirrel free use web fonts.
http://www.fontsquirrel.com
How do I find the version of CSS that I am using?
Although the CSS specification is defined in several versions (v2, 2.1, 3), the CSS version isn't really relevant to the developer; you need to be more concerned with which web browsers support a given feature.
It is useful to know that a given feature was defined in CSS2, 2.1 or 3 because that can give you an idea of how old the feature is, and therefore how likely it is that browsers will support it -- for example border-radius is a CSS3 feature, so browsers more than a couple of years old may not support it fully.
You can find out what CSS features are supported in which browsers from the following sites:
http://www.quirksmode.org/css/contents.html
http://caniuse.com/
The version is only defined by the CSS selectors, propreties and attributes that you use.
You are free to mix elements of CSS 1, 2 and 3 in any styles that you write.
You can refer to the CSS specifications to see more details. The specifications and drafts at the W3C is available via this index: http://www.w3schools.com/w3c/w3c_css.asp
Just an addition of what #Craig said.
In my .net 2.0 framework I have a property to show scroll bars. As I want just the vertical, I've added both properties and, if the browser that user is using support this new CSS 3.0 property (overflow-x), he will see just the vertical one.
In my opinion you should use object detection instead - check the MDC to understand the principle.
On Internet Explorer you might find compatMode and documentMode useful.
As far as I know, there's nothing in CSS code that specifies the version. Browsers are designed to interpret one or more versions of CSS at runtime. Therefore, I would imagine that you would need to get the version of the browser via javascript and then determine what version of CSS is understood by the browser.
Is there a structured language for declaring styles in a sensible way, which can then be rendered into browser specific css files, similar to what GWT does to Javascript?
It would ideally be a language that supports variables, deals with browser quirks and differences (e.g. filter:alpha vs opacity), provides an intuitive syntax for common tasks such as centering, and has a way to express fallbacks for less capable browsers.
Sass, as in Haml and Sass has some of what you're looking for.
It has variables, math, and other goodies.
The official version is Ruby based, but there are versions for other languages like PHP and Python.
It might not do EVERTHING you mentioned, but it's worth checking out.
GWT's ability to generate code on the fly and it's powerful "deferred binding" capability could definately be applied to stylesheets and allow for build-time optimization of CSS.
Right now, the "GWT way", according to styles is to include all the styles you'll need and use apply them by making use of "dependent style names". But this definitely leads to lost of useless CSS being included where it's not needed.
I know there is at least one attempt to optimize CSS at build time. This would involve combining multiple seperate stylesheets into one, and removing all non-essential whitespace (minifying). I think this might also allow you to make use of deffrred binding to essentially "optimize out" CSS from where it's not needed (ex: browser specific styles).
StyleInjector
To answer my own question (again): Less seems like one of the most interesting projects so far. CSS extension supporting variables, mixins (complex variables), nested rules, and simple arithmetic.
you might want to try HSS.
Thanks for your comments! Sass and HSS seem very similar in scope: simple and block variables, nested blocks, single line comments. HSS has the advantage of being a superset of CSS.
StyleInjector looks more ambitious and interesting. By leveraging GWT's deferred binding capabilities and introducing CSS syntax extensions like conditionals, this approach should make it easy to define not only browser specific but also locale specific styles. Also being able to reference other GWT resources directly, and automatically minimizing styles by removing and merging selectors is pretty cool. I'll definitely follow this project closely.