I am running my XHTML file through W3C validation and an error is coming up. However, I am unable to understand the error - it says, "No p element in scope but a p end tag seen".
Can some with fresh eyes see it?
Here is my code:
<div id="mainBody">
<div id="text">
<p>
<img src="images/billyGraham.png" alt="Billy Graham">
<blockquote>
Billy Graham:<br><br>
Is it not arrogance or narrow-mindedness to claim that there is only one way of salvation or that the way we follow is the right way? I think not. After all, do we fault a pilot for being narrow-minded when he follows the instrument panel [while] landing in a rainstorm? No, we want him to remain narrowly focused!
</blockquote>
</p>
</div>
</div>
A blockquote element can't be inside a P element. It's invalid HTML. Although if you've tested in your target browsers and there's no issues I wouldn't worry too much, validation is just a guideline and shouldn't be taken too literally (IMO)
Related
I stumbled across this weird behaviour recently while trying to find a generic front-end way of capitalizing the first letter in a string. Normally, i would just call it quits, but i kept on trying to find a solution. However, that's when i came across this strange behaviour.
snippet:
.capitalizeWord::first-letter {
text-transform: uppercase;
}
<!-- example 1 -->
<p class="capitalizeWord">
<span>
<i></i>
test1></span>hello
</p>
<!-- example 2 -->
<p class="capitalizeWord">
<span style="float:left;"> <!--float causes it to work -->
<i></i>
test2></span>hello
</p>
According to caniuse ::first-letter chrome is supporting this.
So, my first question is: What is causing this behaviour? This has been "somewhat" answered in the comments
My initial thought was that the compiler interpreted the <i>-tags as chars. But no, the issue is still prevalent when they're removed.
Can anyone else verify that they are experiencing the same results?
Posting image for reference if your browser isn't seeing what mine is:
Anyhow, my second question: Is there a frontend way to accomplish the result of test2 but with test1's structure?
Off-topic but still relevant to answer my first question. See below
Update:
After some discussion in the comments, the problem has been narrowed down to be about the <i>-tag after all.
However, I would still classify this as a bug. Here's why:
An empty <i></i> should not trigger ::first-letter. Like, that should be self-evident by just looking at the name of the selector.
Why is ::first-letter triggered by a non letter character (an EMPTY html-tag in this case), and then stops looking within that scope when nothing has been found in the EMPTY tags, which isn't where the root-elements (p/div) scope ends... Like, whyyyyyyyyyy?
I can break the entire selector by just doing:
.box::first-letter {
text-transform: uppercase;
}
<div class="box">
some text
<!-- wooohoo, works! -->
</div>
<div class="box">
<i></i>some text
<!-- doesn't work now... I broke it, without adding ANY characters/letters to the dom -->
</div>
<span class="box">
some text
<!-- doesn't work now... I broke it again, just changed to a span-tag -->
</span>
<span class="box" style="display:block;">
some text
<!-- wooohoo, works! -->
</span>
Maybe this is me being stubborn, but, i really hate this approach they've taken with this selector. It really could have been used as "the way to go" for capitalizing strings on the web, instead of all these javascript workarounds has had to be created in its place.
You are asking two specific distinct questions, so I will answer them both.
my question is: what is causing this behaviour?
To answer your question: When you float the element, it is taken out of the document flow and no longer counts as part of the content of the block in regards to pseudoelement selectors. From the CSS visual formatting spec:
An element is called out of flow if it is floated, absolutely positioned, or is the root element.
Visual formatting model - W3
So in accordance with the spec, we can see the exact same result if we take the element out of the flow by using a different method, e.g. absolute positioning:
.capitalizeWord::first-letter {
text-transform: uppercase;
}
<!-- example 1 -->
<p class="capitalizeWord">
<span>
<i></i>
test1></span>hello
</p>
<!-- example 2 -->
<p class="capitalizeWord">
<span style="float:left;"> <!-- float causes it to work -->
<i></i>
test2></span>hello
</p>
<!-- example 3 -->
<p class="capitalizeWord">
<span style="position: absolute; left: 50px"> <!-- absolute positioning causes it to work -->
<i></i>
test3></span>hello
</p>
is there a frontend way to accomplish the result of test2 but with test1's structure?
As far as I know there is no way to do this in pure CSS, because you would necessarily need to take the offending element out of the flow to get the selector to find the desired pseudoelement. And by taking the element out of the flow, your elements would no longer have the same visual hierarchy.
I would still classify this as a bug
The behavior follows the spec, so it is not a bug. You might argue that it's a poor design choice.
Let's say I want to create a simple responsive one page homepage. I find several alternatives to do this, but what is the best option? I have read several articles on the net including the ones fron W3C, but I don't get a clear answer!
I'm going to have two column layout with text to the left and an image to the right. On a desktop computer they will be besides each other, styled left and right. But in smaller devices like a mobile, the right column will be changed to left and be placed below the text column.
Is alternative 1 bad in a HTML5 point of view? My thought was to devide the page with several parts of alternative 1 or 2. There is also a third alternative(I guess there almost endless with other options aswell) to use two article elements inside the section element and use a article element for the image instead of the aside element.
I guess some of you might also suggest me to use article element instead of section elements and use nested article. It's confusing with all this options!
Should I also use article and header element in alternative 1?
Preciate some feedback and guidelines! Sorry for all my questions, I just want to improve my coding skills!
Alternative 1:
<div id="intro">
<div class="content-left">
<h2>Headline</h2>
<p>Text</p>
</div><!-- end class content-left -->
<div class="content-right">
<img src="...."/>
</div><!-- end class content-right -->
</div><!-- end id intro -->
Alternative 2 with HTML5 elements:
<section id="intro">
<article>
<header>
<h1>Headline</h1>
</header>
<p>Text</p>
</article>
<aside>
<img src="...."/>
</aside>
</section>
The answer is: it doesn't really matter much, apart from code readability. Please see Why use HTML5 tags? for more on that.
You could have a <section class="articles"> that contains all <article> elements. You could have a <div class="articles"> that contains all <div class="article"> elements. I think it's safe to say there's no doubt the first one is easier to read for developers. Your pick.
There is, however, one issue: you self-close <img> -- no need for that in html5 anymore. See Are (non-void) self-closing tags valid in HTML5?.
In HTML 5, <foo /> means <foo>, the start tag. It is not a "self-closing tag". Instead, certain elements are designated as having no end tag, for example <br>. These are collectively called void elements. The slash is just syntactic sugar for people who are addicted to XML. Using the slash in a non-void element tag is invalid, but browsers parse it as the start tag anyway, leading to a mismatch in end tags.
I'm running my website through the W3C validation service. I'm getting an error message for the following HTML:
<section class="about">
<article>
<header>
<h1>Mission</h1>
</header>
<div class="content">
<p>bla bla bla</p>
</div>
<aside>
<img src='/images/logo-hse-250x250.png' />
</aside>
</article>
</section>
The W3C validation error is:
Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).
<h1>Mission</h1>
I thought with HTML5, it was allowed to use more than one h1 tag on a page. And that h1 tags could be used inside article elements.
Does anyone have a clue why W3C isn't validating this HTML?
It is valid to use h1 there.
The W3C Markup Validator does report a warning, not an error. You can ignore warnings if you like to.
The HTML5 spec "encourages" authors to use "headings of the appropriate rank" instead of h1 everywhere. But an encouragement is not a normative requirement.
<h1> Tag must be used as top-level heading, i.e, as page heading/tittle. Here you are the W3C Reference
That's is because SEO purposes; ensuring content is formatted in the best way possible to aid search engine indexing; and because technical correctness; ensuring that markup is written in accordance with the appropriate W3C spec.
Depending on the strucutre of your page, you can use more than one perhaps, but it's better not tu use more than one <h1> tag
I'm trying to find the best way to code a search result page in HTML5.
Here's how I've done it.
<section>
<header>
<h2>Results for <kbd>this terms</kbd></h2>
</header>
<!-- list of results -->
<ol>
<!-- First result -->
<li>
<article>
<header>
<h3>
<cite>
This is a result
</cite>
</h3>
</header>
<blockquote cite="http://addressofthepage.ch/">
<p>So, setting about it as methodically as men might smoke out a wasps' nest, the Martians spread this strange stifling vapour over the Londonward country. The horns of the crescent slowly moved apart, until at last they formed a line from Hanwell to Coombe and Malden. All night through their destructive tubes advanced.</p>
<footer>
<p>Published <time datetime="2010-07-15T13:15:05-02:00">MMMM DDth, YYYY</time> at the <abbr title="Uniform Resource Locator">URL</abbr> http://addressofthepage.ch/</p>
</footer>
</blockquote>
</article>
</li>
<!-- Second result ... and so on -->
<li>...</li>
</ol>
</section>
The main questions are
<header> mentions the search terms. What is the best tag to use? <kbd>?
Is the <cite> tag related to the <blockquote> if it is positioned in the <header>?
Is not better to put the <cite> in blockquote > footer like <p>[...] at the URL <cite>http://addressofthepage.ch/</cite></p>
All this is also available on a Gist
is meant as a way to show keys. That's why many sites style that tag as a keyboard key. You're not showing keys, you're showing a search term. A <span> should be fine. Maybe add a class like <span class="search-term">.
Semantically speaking, no, it wouldn't be related as it's not a child.
The "correct" HTML for using cite and blockquote would be:
A quote here...
— Foo Bar
gist here of the HTML: https://gist.github.com/OscarGodson/5a3e87ce895b3af952de (stackoverflow appears to have issues rendering HTML when in code tags?!)
Notice the cite and footer tags. As per spec:
The blockquote element represents content that is quoted from another
source, optionally with a citation which must be within a footer or
cite element, and optionally with in-line changes such as annotations
and abbreviations. Content inside a blockquote other than citations
and in-line changes must be quoted from another source, whose address,
if it has one, may be cited in the cite attribute.
Source: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-blockquote-element
The main thing to remember, and coming from someone who's been doing this for a long, long time, semantics matter, but don't overthink it. Sure, the blockquote has some strict rules about how to properly use it, but browsers will handle whatever you give it fine. Do what makes sense for your app and that should be semantic enough 90% of the time as long as everything isn't a span and div. If you over analyze this stuff you'll spend more time deciding which tag to use instead of just getting stuff done ;)
What are people's opinions on semantic HTML for confirmation, error and warnings messages?
Currently I have something simple like:
<div class="message message-warning">
<h3>Message Title</h3>
<p>Message text</p>
</div>
Whereby the message-warning class gets replaced by message-confirmation or message-error if the message is a different type.
Is there a more semantic way of marking this up?
May I suggest <figure>?
Excerpt from HTML5 Doctor (and they, from W3C):
The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that can be moved away from the main flow of the document without affecting the document’s meaning.
Lets answer the questions first:
Is such a dialog a single unit? Yes
Is such a dialog self-contained? Yes
Can such a dialog be moved away from the document without affect the document meaning? Yes
Yes, it fits a <figure> perfectly.
And, the <figcaption> is especially good for title bars / headings.
So, I'd go with <figure> without even trying to look further:
<figure id="dialog-box" class="warning">
<figcaption>Message Title</figcaption>
<p>Message text</p>
</figure>
Use the <dialog> element, and call .show() instead of .showModal(), or give it the open attribute if rendering server-side.
As long as it’s not shown modally, it won’t block interactions with other page content.
Old answer (before <dialog> was a thing):
Alerts are one of the semantics that ARIA added to HTML, because there's no straightforward way of doing in "pure" HTML. Hence:
<aside role="alert">
<h2>Message Title<h2>
<p>Message Text</p>
</aside>
I personally like to use <aside> as the element to slap the role on — it's technically not part of the page content, as described by Jeff Lindblom's answer.
Having a "semantic" CSS selector for this is easy enough:
[role="alert"] {
font-size: 2em; /* or what have you */
}
The <figure> idea is interesting, but I don't think it fits here. What it's missing is the actual content to justify use of the tag. According to the spec, <figure> represents a "unit of content" - meaning an image, diagram, code block, etc. that may optionally have a caption for this content (<figcaption>). It would be a stretch to say that the message outside the <figcaption> represents an appropriate unit of content.
We should also be cautious of using <h#> tags in this instance, as the message is secondary content, and should probably not be part of the document outline.
One could argue, under the revised spec, that an <aside> would be appropriate. It's now considered "tangential content" when used outside an <article>.
<strong> would be appropriate for the "title" of the message, since it's a semantically more important part of the message, but not a document header. So the code might look so:
<aside class="warning-or-whatever">
<strong>Message Title</strong>
<p>Message Text</p>
</aside>
One could also argue, since there's nothing specifically created for such a feature, that a good old-fashioned, semantically meaningless <div> might be the best element. I guess it comes down to how "tangential" you feel your messages are.
Thanks,
Jeff
No. There is no element in HTML that denotes a confirmation, error, or warning message.
Technically, the samp element has been defined as “sample output from programs, scripts, etc.” in HTML 4.01 and in HTML 3.2, though originally in HTML 2.0 as “sequence of literal characters, typically rendered in a mono-spaced font” and being somewhat redefined in HTML5 as “(sample) output from a program or computing system”. So its meaning is rather vague, and it’s not used much, so there is no real point in using it. But it might be argued that it is acceptable to use samp markup for any message from a program. It is a text-level element, so you would need to use it separately inside h3 and inside (any) p, more or less breaking the structure.
It might also be said that the messages are quotations from an external source, so they could be wrapped inside blockquote.
The use of h3 vs. some other markup isn’t really a semantic question, but structural: is this a heading for some content at the 3rd level of nesting?
I think the strong element is an appropriate element for such messages.
You could use several strong elements to indicate the importance of the message:
<strong>Login successfully.</strong> <!-- confirmation -->
<strong><strong>Wrong login data.</strong></strong> <!-- warning/error -->
If it’s stand-alone message for which a heading is warranted, use a section element instead of a div. In case of serious errors that apply to the whole page, it should be the first element on the page.
Various variants are possible:
<section class="message message-error">
<h1><strong><strong>Error:</strong> Wrong login data.</strong></h1>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<h1>Error</h1>
<p><strong><strong>Wrong login data.</strong></strong></p>
<p>The username and/or password is wrong. Try …</p>
</section>
<section class="message message-error">
<strong><strong>Wrong login data.</strong></strong>
</section>
<section class="message message-error">
<p><strong><strong>Wrong login data.</strong></strong> Try …</p>
</section>
Which one to use depends on the kind of message, if the exact error is know, if additional help text is provided, and if several message could come up at the same time.
Note that you probably don't want to use a heading for messages that apply to a single input element (e.g. when the user didn't fill out a required field or entered wrong content etc.), as these error messages should be in the corresponding label or directly next to the input element.
For accessibility, you should have a look at WAI-ARIA. Maybe aria-live="assertive" might be an appropriate way to mark error messages.
If you want to go semantic, you can use a semantic-web approach by making an ontology for messages and warnings and use RDFa to embed it in your HTML.