In trying to learn MathML, I found that the mfenced element used in this tutorial has been deprecated, so that Firefox no longer supports it. This example in the official MathML documentation simply uses <mo>(</mo> and <mo>)</mo>, respectively, to surround fractions in parentheses. When I tried this, I found that the parentheses had normal height and did not stretch to the height of the fraction. Yet the example code had no special attribute to control the parenthesis height, suggesting that it should have adjusted automatically (as it would in LaTeX). What is missing? Below is my code.
<html>
<head>
<title>MathML in HTML5</title>
</head>
<body>
<p>
<math>
<mo>(</mo>
<mfrac linethickness="0">
<mrow><mn>5</mn></mrow>
<mrow><mn>2</mn></mrow>
</mfrac>
<mo>)</mo>
<mo>=</mo><mn>10</mn>
</math>
</p>
</body>
</html>
you also need mrow to surround the mo stuff:
replace <mfenced> with <mrow><mo>(</mo>
replace </mfenced> with <mo>)</mo></mrow>
Related
CSS writing mode doesn't work for some characters, in particular for symbol '№'. Here example
<html>
<head></head>
<body>
<p style="writing-mode: vertical-lr;">
Номер № 2
</p>
<body>
</html>
http://cssdeck.com/labs/3pc5ihz5
All symbols are rotated and only this symbol not changed. What am I doing wrong?
Replace Номер № 2 with Номер N° 2
This is a known bug with some symbols
№ is not the only symbol, which won't change, there are more.
Some symbols are just not supported.
As the question title states, is it okay to write just
<math>a <msup>x 2</msup> + b x + c</math>
or do you really need to write
<math>
<mrow>
<mi>a</mi> <mo>⁢</mo> <msup><mi>x</mi><mn>2</mn></msup>
<mo>+</mo><mi>b</mi><mo>⁢</mo><mi>x</mi>
<mo>+</mo><mi>c</mi>
</mrow>
</math>
As far as Firefox goes it doesn't render a
Invalid Markup
error, but that hardly means other browser might not in the future if the spec actually prohibits it officially.
As the question title states, is it okay to write just
<math>a <msup>x 2</msup> + b x + c</math>
No, it isn't.
do you really need to write
<math>
<mrow>
<mi>a</mi> <mo>⁢</mo> <msup><mi>x</mi><mn>2</mn></msup>
<mo>+</mo><mi>b</mi><mo>⁢</mo><mi>x</mi>
<mo>+</mo><mi>c</mi>
</mrow>
</math>
Yes, see http://www.w3.org/TR/MathML3/chapter2.html#fund.syntax.
As far as Firefox goes it doesn't render a "Invalid Markup" error, but that hardly means other browser might not in the future if the spec actually prohibits it officially.
At the begin browsers render a "Invalid Markup" error for anything that doesn't follow the spec. Today browsers try to correct the markup. For example
<p>
<ul>
<li>foo</li>
<li>bar</li>
</ul>
<p>
is invalid since you need to use
<p></p>
<ul>
<li>foo</li>
<li>bar</li>
</ul>
<p></p>
but no browser will stop rendering the page because of it.
MathML is intended for mathematics presentation markup. It is aimed to provide all information needed for correctly typesetting a mathematical formula.
In mathematical typesetting, identifiers (or, simply "variables"), operators and numbers are typeset differently. There are a lot of subtle differences, but to name a few: identifiers are normally italic style (and use a mathematical serif font), whereas numbers are roman style. Operators use subtle spacing rules on either side. These are just a few examples.
As presentation MathML is not intended to describe the meaning of a formula, merely how it looks, all this information must be encoded in the markup. The MathML renderer does not interpret the formula, either. It looks at the markup and renders accordingly.
Authoring MathML directly is not easy, and, in fact, it is mostly done programmatically, rather than inputting directly. If you need a more straightforward way, try ASCIImath or LaTeX. A renderer like MathJax renders those as well.
Does anyone know if it is possible have the output of knit2html (i.e. markdownToHTML) wrapped in an HTML container?
Currently, everything gets dumped into <body>, which does not provide a lot of flexibility for controlling the layout.
For example, what I would like to from something like:
example.md
<div id='main'>
Markdown
========
some text, etc. here...
</div>
To:
example.html
<!DOCTYPE html>
<html>
<head> ... </head>
<body>
<div id='main'>
(HTML VERSION OF MARKDOWN
</div>
</body>
</html>
If I leave out the div container, the markdown is translated perfectly and placed at the top-level of <body>. What I would like to do is simply place in in a child container of body, thus allowing me to have finer control over the formatting of the contents.
Any ideas?
In your call to markdownToHTML set an option called fragment_only:
markdownToHTML(..., options=c('fragment_only')
That'll skip putting it in a body, I believe, and then you should be able to do with it as you will.
You should be able to specify that in a call to knit2html as well, as part of the ... argument.
I have a web page like the following one:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
<main>
<h1>Page heading</h1>
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
The page structure is similar to one example in the current HTML5 draft: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element and I think it is semantically correct.
Now I would like to style this document using CSS. I would like to be the header at the top and footer at the bottom, which is, of course, easily doable. Inside the header I would like to put the logo to the right and the navigation in the center, which is also okay (e.g by using the flexible box layout model, which is in one or the other way supported by modern browsers, or by using floats).
My problems begin when I want to put the main's content heading (the h1 element) visually in the left of the header. I could do with position: absolute but such a layout is not very flexible and would break as soon as the header's or the heading's sizes change. The proposed CSS grid layout http://www.w3.org/TR/css3-grid-layout/ may be able to do exactly what I want but it is, as far as I know, only supported (somehow) in IE 10.
One simple and working solution would be to simply restructure my page:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<div>
<h1 id="heading">Page heading</h1>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
</div>
<main aria-labelledby="heading">
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
This solution, while easily layoutable, however, has its full semantics only expressed via aria-* attributes and seems to go against the spirit of the HTML5 semantics (especially the main element).
While my example page may be simple, you can easily imagine a more complicated one where the visual position of many more elements are not in the same order as the flow order of the HTML5 markup (and nested so that the flexible box layout order property won't suffice). How would you solve the problem? Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so that it corresponds more to the visual layout and then exchange the non-semantic elements by semantic ones (e.g. footer or main) wherever possible with the new structure?
I am running into the same conundrum as you, and I appreciate the frustration. I will attempt a negative answer, because I feel both of these positive ones (which say you can achieve both your ends) are missing the point.
Firstly, the way I see it, your principle difficulty is that CSS cannot move an element to a new container. The two answers fall into two categories:
Some are ultra-specific hacks (subjectively speaking) involving floats, negative margins, and/or absolute positioning which can move an item presentationally out of its container. These can be effective, but only in very specific cases. As your needs grow, it becomes difficult to maintain and it requires putting a rather large thinking cap on to address each new need or edge case that you had missed earlier. The answer by #jennifit attempts to move you in this direction. It is, I believe, the normal route taken by those trying hard to follow the spirit of semantic HTML5, which is admirable. But it can be a quagmire that makes you begin to ask exactly who you're maintaining your semantic purity for? Is it for the search engines, the screen readers, or ease of maintenance? I'll get back to this after the next classification.
Some are pragmatic rationalizations that claim to be equivalent semantically but are, in truth, a different semantic meaning. These are really semantic hacking in my opinion. #volker-e 's answer is an instance of this. He's right, this is an alternative markup that could work -- but, it doesn't equal the same semantic meaning. The h2 belongs in main as an h1 -- it makes no sense to move it within the page's header. In fact, you're saying that your heading is unrelated to your main content. This, in some ways, is worse than using that div you wanted to use, because you're making a false semantic relationship by grouping the page-header and site-header into the same semantically-significant header. A semantically meaningless container, such as div, for both header and main, is actually less perverse in my opinion.
So, getting back to what I said about who you're maintaining semantic purity for, this is the real philosophical question at play. There is often an obvious, effective, and maintainable solution without rationalized mis-uses of existing semantic elements or css 'tricks'. In your case, of having an item which is semantically a child but presentionally not a child, the answer is the one you've already put forth as a question:
Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so
that it corresponds more to the visual layout and then exchange the
non-semantic elements by[sic] semantic ones (e.g. footer or main) wherever
possible with the new structure.
This is the right thing to do whether you're semantic-purity was intended for
accessibility: in this case you can achieve that in a non-hierarchical way with ARIA roles.
search engines: search engines still understand the old way to do things, so you're not going to get into SEO trouble if you follow older approaches to semantics.
maintenance: this is the reason most people are lured in by -- but the problem is, what's the point of maintainable HTML but unmaintainable CSS, or the other way around? you have no choice but to see your maintenance as a combination of both CSS and HTML, and you have to find the middle ground where they are both deranged equally when you run into a difficult presentational problem.
The only other possible answer, if you feel that HTML semantics are all that matter, is to accept the limitations that hierarchical HTML semantics places on your layout. The problem is, there is no way in CSS to re-create the layout hierarchy. Until that happens, you'll have to accept that HTML is both a presentational and a semantic language, and, therefore, semantics will always be a matter of "better" and "worse". Truly beautiful or rich or perfect semantics will be unachievable in many, if not most, layouts.
My approach would be the following:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<a class="aural" href="#content">Jump to content</a>
<header role="banner">
<h1 class="site-logo">Logo</h1>
<nav role="navigation" aria-labelledby="nav-heading">
<h6 id="nav-heading">Navigation</h6>
<ul>…</ul>
</nav>
<h2 id="heading">Page heading</h2>
</header>
<main id="content" role="main" aria-labelledby="heading">
Page content
</main>
<footer role="contentinfo">
Content information
</footer>
</body>
</html>
and then go for a CSS ruleset like:
header h1,
header h2,
header nav {
float: right;
}
Diff:
You have appropriate accessible headings for page's content
You save otherwise seemingly useless div in header & main
You've got a nice HTML5 structure outline, which helps SEO.
I've included (was not part of the question) the navigational landmark roles as of WAI-ARIA 1.0 draft specification
I've included a skip link, which is still recommended best practice
Minor change: I know, charset value case is insensitive, but as you also write DOCTYPE uppercase, UTF-8 is the more correct value, see http://en.wikipedia.org/wiki/UTF-8#Official_name_and_variants
The first structure may still work if there is position:relative in < main > and using position:absolute on h1 with a z-index and a -ve margin. That way, the heading will always float on top in the same position in relation to the main content. While it may not be the best solution, I think it will not break the layout (?)
This is one of those things that you read once, say "aha!" and then forget. Exactly my case.
Why is the line-break tag in xhtml preferentially written with a space <br /> and not in the also ok format <br/> ? I remember the reason was interesting, and as you can imagine it's not easy to find with google.
For sure it's not an issue of xml well-formedness. From W3C
[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'
Empty-element tags may be used for any element which has no content, whether
or not it is declared using the keyword EMPTY. For interoperability, the
empty-element tag should be used, and should only be used, for elements which
are declared EMPTY.
Examples of empty elements:
<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>
So the space at the end is optional.
w3c specifies this as the grammar:
EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'
That means open bracket, a name, a number of (space and attribute) tokens, an optional space, a slash, and an end tag. According to this, both are correct.
If I recall correctly it's simply because some older browsers had problems with a self-closing tag without a space before the slash. I doubt it's an issue nowadays, but a lot of developers (myself included) got into the habit of including the space.
Edit: Ah, here we are:
http://www.w3.org/TR/xhtml1/#guidelines
Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents.
Some older browsers didn't parse the element correctly without the space, so most web developers use <br />. I don't remember which browsers offhand, but I believe they're just about extinct.
EDIT: The browser was Netscape 4.
There is no right way in XHTML. They are formally identical in XML. Whitespace is not significant in that location.
For XHTML: both of them. For HTML4 and earlier: neither.
<br /> is valid (old) HTML, while <br/> is not. If you are serving your XHTML as XML, it doesn't matter. If you are serving it as text/html, then it needs to be valid HTML in addition to being valid XHTML. (Why serve XHTML as HTML? Because IE doesn't understand XHTML as XML, and because no major browser will start rendering XHTML mid-way through downloading the text, but they will do that to HTML. My blog appears to load slowly not because the site is slow, but because the browser won't start rendering the page until everything has been fetched. I hate browsers.)
A little background to add to Matt Hamilton's answer.
A least one problem browser was Netscape 4. A quick check shows that in that browser, <br/> (i.e. no space) doesn't cause a line break. In fact, it doesn't appear to do anything. <br /> (i.e. with space) does perform a line break.
When creating polyglot documents that can behave as XHTML or HTML (Note: "behave as" - not "valid") it's necessary to use either <br /> or <br></br>. However, when parsed as HTML, </br> is treated as if it was <br>, so <br></br> produces two line breaks.
Both <br/> and <br /> are correct. The reason that <br /> came about in the first place was to support older browsers that didn't understand the new <br/> syntax. It's really kind of a hack where the / is interpreted as an attribute with no value and ignored.
Both are correct, and both will be accepted by web browsers. You may as well save yourself the extra character, and use <br/>
Both are correct. But I would use <br /> just to keep my code consistent... because I would never write
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
instead of
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
just to save a byte... and the second version is imho better readable. But that's just a matter of taste. Do it as you like, but do it consistent :-)
Either will work just fine. Assuming you are asking for evangelical reasons, I prefer <br/>
Both are correct.
<br>. You aren't using XML anyway.