I would like to single letters were not on the end of a paragraph i site. I know it 2 ways:
A)
<p>... <nobr>a może</nobr> tak ...</p>
B)
<p>... a może tak ...</p>
Which one is better and should be used today? Or maybe another?
It would be nice if it was as easy to work with.
Mozilla states, that <nobr> is deprecated and also never was standard HTML. So it isn't recommended to use it at all:
<nobr> on developer.mozilla.org
But Mozilla doesn't recommend using as a substitute, but to use the CSS style white-space instead:
white-space: nowrap;
My understanding is, that you should use only when single word pairs shouldn't get divided. For example, if you have abbreviations of units behind an amount, like 5 ml:
<p>Lorem Ipsum dolor sit amet 5 ml</p>
This also is more like a piece of content-based information since it describes, that those two words belong together and should not get separated in order to maintain readability and a good understanding.
Whereas <nobr> has been designed to make whole paragraphs do not add line breaks.
And this already explains, why <nobr> is not a standard HTML tag, since HTML should only contain content-related information, and everything about style/design should go into the stylesheet.
Related
Let's suppose I have the following paragraphs:
<p>one two </p> <p> three </p><p> four five </p>
Now let's suppose I want to style the words two, three, and four green, in place, without having any other effect on the document's structure or other layout. I basically want a <span> that transcends block level elements like <p>s. How can I accomplish this most simply? I could
<p>o <span>t</span></p><p><span>t</span></p><p><span>f</span> f</p>
But that makes things really messy due to the fact that I employ a markdown parser and have my own custom preprocessing code. What could I do so that there's only one "style begin" mark, and only one "style end" mark per contiguous length of green text?
You can have your text wrapped in a single <p> </p> and have a <span> inside that wrapping around the text you want to style, so:
<p>one <span>two three four</span> five</p>
http://jsfiddle.net/asbd9rdj/
edit
To target specific words in your multiple <p></p> tags, use a <span></span> as an inline element so you can attach styles to it.
<p>one <span>two</span></p>
<p>three <span>four</span></p>
example here: http://jsfiddle.net/79be8L6L/
"Interleaving" HTML tags is invalid. You should use 3 separate <span> tags, like in your second example.
Making your HTML generator handle this is unfortunately a necessary complexity in order to produce proper HTML.
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.
Recently a friend decided not to close his tags or attributes in HTML because it's not required and he'll save some bandwidth and download time. I told him it's a bad idea and to be "better safe than sorry", however, I could only really find 2 resources on the issue:
http://css-tricks.com/13286-problems-with-unquoted-attributes/
http://www.cs.tut.fi/~jkorpela/qattr.html
#1 is good, but even as he said, they aren't really real world examples, which is why I went to #2, but they only really show an <a> which is much more different than most other tags/nodes.
Is there another resource or test cases as to a better reasons to quote your attributes and close your tags?
You can often leave the closing tags off many elements without changing 'the way it looks'. However, even though one of the main goals of HTML5 is to standardize how browsers deal with bad markup, not closing tags can impact your content in unexpected ways. Here's a simple example, a list of items where some of the items are blank, both without explicitly closed tags and with:
<ul>
<li>Item
<li>
<li>Item
<li>
<li>Item
</ul>
<ul>
<li>Item</li>
<li></li>
<li>Item</li>
<li></li>
<li>Item</li>
</ul>
Looking at the two in a browser they look identical. However, if you add a bit of CSS to hide the empty ones:
li:empty { display: none; }
Now they don't look the same, even though the markup hasn't changed from the previous example. The underlying reason for this is that the two versions produce different DOM trees, this version iterates through all the nodes in both lists and counts them, then shows the results and the list of nodes found in alerts. You can see the top list has 12 DOM nodes, the lower list has 15. The results are at least consistent cross browser, and the difference is in text nodes which you'll frequently skip over when scripting anyway, but this shows that even if the visual output looks the same when tags are closed or not, there are underlying differences even in an example as simple as this.
Not closing tags can lead to browser incompatibilities and improperly rendered pages. That alone should be enough reason to properly close your tags.
Saving bandwidth and download time is a horrible excuse, if you ask me. It's 2011, and even on dialup the few bytes you save on not closing a few tags will not be even close to noticeable. A mangled page due to improper rendering, however, will be.
Not closing tags can create unexpected blank spaces between elements in the markup.
Consider the following example.
<!-- English quoting rules. -->
<style>
blockquote > p::before { content: open-quote; }
blockquote > p::after { content: no-close-quote; }
blockquote > p:last-of-type::after { content: close-quote; }
</style>
<!-- This is ok. -->
<blockquote>
<p>Lorem ipsum dolor sit amet.</p>
<p>Lorem ipsum dolor sit amet.</p>
</blockquote>
<!-- This isn't. There are blank spaces after the last (unclosed) <p> element.
Thus, the closing quote appears separated with a space from the text. -->
<blockquote>
<p>Lorem ipsum dolor sit amet.
<p>Lorem ipsum dolor sit amet.
</blockquote>
That's just bad coding practice in my opinion.
There are two types of programmers; those that care, and those that don't.
It's lazy programming, the same as not having coding standards, or not formatting your code... it's like being a carpenter and not sanding the edges of the table you just built.
Most browsers support it, but some might complain.
Most HTML tags are containers. Consider:
<style>
section {
color: red;
}
</style>
<section>
Stuff inside a section
</section>
Stuff outside a section
<p>
Other text
</p>
In this example, "Stuff inside a section" would be red text, "Stuff outside a section" is not red. In this example:
<style>
section {
color: red;
}
</style>
<section>
Stuff inside a section
Stuff outside a section
<p>
Other text
</p>
... in this example, "Stuff inside a section", " Stuff outside a section", and "Other text" would ALL be red - that is, the section never ended. The browser may try to assume where the section could have ended, but in my above example the only assumption possible is that the section continues to the end of the document, which is not what was intended.
In short, not closing HTML tags just makes things more confusing for you, will cause pages to render inconsistently from expectations and between browsers, and is just generally a bad idea. So bad, in fact, that it shouldn't even be taken as a serious suggestion at all. Your friend has clearly never developed an actual web site.
You can't do much in terms of site design/layout if you don't close tags.
I'm writing a new webpage for a company and I have (a sane subset of) HTML5/W3C recommendations in mind.
After reading the semantic meaning of <hr />, I was wondering if this was a good place to use it:
<section name="historyItem">
<h2>2002</h2>
<p>Dolorem ipsum dolor sit amet in 2002, consectetur [...]</p>
<hr />
<ul>
<li>Link A</li>
<li>Link B</li>
</ul>
</section>
My line of reasoning is that, yes, that <hr /> represents a thematic change from section description to section links, but I'm unsure about that.
Maybe "thematic change" means to have a new paragraph later on another subject, and thus my example wouldn't be "correct". What do you think?
(ps.: Yes, that <ul> is CSS-styled to fit a single line and look cool)
I see what you mean. But personally I just wouldn't bother. Ask yourself why you're using the tag in the first place. If you want to delineate a change between the paragraph and the links, then in terms of pure mark-up I don't reckon it's required. If it's about the look and feel of your page (i.e. you want a rule demarcating the two areas), then again I'd question its usefulness, given that you can apply a border to either the paragraph or unordered list tags.
Of course, given that this is html5, you could go the whole hog and use the <section> tag…
Thematically speaking, <hr> means the end of one "section" and the start of "another". Essentially these should be appearing after your <section> tags, not within. Although semantically speaking, it doesn't really matter where you want to use them.
If your list of link items are relevant to the items ABOVE the <hr> tag (meaning relevant to your other elements within the <section> tag, then I do not recommend using <hr> there. Instead, use CSS to differentiate border and underlines.
If you'd like additional reference, I've located this for you:
http://html5doctor.com/small-hr-element/
I'm making a small web-chat utility and am looking for advice on which elements to use for messages.
Here's what I'm thinking of using at the moment:
<p id="message-1">
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
<cite class="admin">
Ross
</cite>
Lorem ipsum dolor sit amet.
</p>
I'd take advantage of CSS here to add brackets around the timestamp, icons for the cited user etc. I figured it would be silly (and incorrect) to use a blockquote for each message, although I consider the cite correct as it's referring to the user that posted the message.
I know this isn't a) an exact science and b) entirely essential but I'd prefer to use meaningful elements rather than spans throughout. Are there any other elements I should consider? Any microformats?
HTML isn't very semantic in a customizable way. Nevertheless your format should be understandable in any browser (with proper CSS, as you have pointed out).
What I see in the code example above is very similar to XML. It might be cumbersome and overkill for your needs, but I'd like to point out that you can use XML with XSLT as a substitute to both (X)HTML. This way you can get your tags as semantic as possible, and don't need to compromise with the limitations of the HTML tags.
w3schools has an article about the topic. I could swear that I saw a webpage in sun.com that was done in XML, but I can't find it anymore.
If you don't intend this to be interpreted or parsed by third party software, I'd nevertheless advise against this method, and stick with the proven HTML.
Seems reasonable to me, except that the ‘id’ is invalid. NAME tokens can't start with a number or contain ‘+’.
Plus if two people spoke at once you'd have non-unique IDs. Perhaps that data should go in another attribute, such as ‘title’ (so you can hover to see the exact timestamp).
If you're going for semantic HTML, you'll probably want to know that HTML5 doesn't consider your use of the <cite> element correct anymore.
A person's name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people's names.
<ol>
<li class="message" value="1">
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
<cite class="admin">
<address class="email">
<a href="mailto:ross#email.com">
Ross
</a>
</address>
</cite>
Lorem ipsum dolor sit amet.
</li>
</ol>
I would try something like the above. Notice I have placed everything in an Ordered list, as comments can be construed in the linear manner fitting an ordered list. Also, I have embedded, inside your Cite tag, an Address tag with an Anchor element. The unfortunately named Address element is actually meant to convey contact information for an Author, so you would probably want to link to the author's email address there.
What you suggested is already very good. If you want to take it a step further and be able to allow tons of different presentation options with the same markup (at the expense of heavier html) you may want to do something like:
<dl class="message" id="message-1">
<dt class="datetime">Datetime</dt>
<dd class="datetime">
<span class="day">Wed</span>
<span class="dayOfMonth">11</span>
<span class="month">Mar</span>
<span class="year">2009</span>
<span class="hourMin">17:34</span>
<span class="sec">33</span>
</dd>
<dt class="author">Author</dt>
<dd class="author">Ross</dd>
<dt class="message">Message</dt>
<dd class="message">Lorem ipsum dolor sit amet</dd>
</dl>
Since you mention microformats in the question, you are no doubt already familiar with the microformats wiki. It contains a good number of examples for different situations.
Another possibility would be to borrow parts of SIOC, which among other things is an ontology for forums - pretty similar to chat.
By re-using existing formats, you can take advantage of plugins and tools like Operator and maybe get more out of your app for free.
I'd use XML with XSLT to transform (style) the data.
It makes sense semantically here, but you also have the conversations in a suitable format for archiving (i.e. XML) - I assume you will have some sort of log or 'history'.
As #bobince said, the id="2009-03-10T12:04:01+00:00" is invalid.
You should change this:
<span class="timestamp" id="2009-03-10T12:04:01+00:00">
12:04
</span>
To this:
<time class="timestamp" datetime="2009-03-10T12:04:01+00:00">
12:04
</time>
You can get more information about the time tag at HTML5 Doctor and W3C:
The time tag on HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.
The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.
...
I agree with the ordered list (ol) solution posted by #Robotsu, except by the time tag I just posted and the incorrect address inside cite tag!