I have HTML that includes symbols such as the Trademark "TM" as superscript (™). In normal HTML, I would use "™" or to display the Trademark TM. However, I can find no way to import HTML like this into Flex and have it displayed correctly. I am having similar issues with the <li> tag.
My HTML:
<p>This information is intellectual property of My Company.</p>
<p>Available features:</p>
<li>Feature 1</li>
<li>Feature 2</li>
<li>Feature 3</li>
<li>Feature 4</li>
<p>COPYRIGHT INFORMATION:</p>
<p>Copyright © 2008, My Company. All rights reserved.</p>
The only way that I've gotten this to work is by copying and pasting the content directly into Flex:
<mx:Text width="100%" height="100%">
<mx:htmlText>
<![CDATA[
This information is intellectual property of My Company™.
Available features:
• Feature 1
• Feature 2
• Feature 3
• Feature 4
COPYRIGHT INFORMATION:
Copyright © 2008, My Company. All rights reserved.
]]>
</mx:htmlText>
</mx:Text>
I want to use an external HTML file that I can import into my Flex App at run time, so that I don't have to recompile the app for a simple content change.
I've heard of too many issues with the iFrame option, so I want to avoid that, if possible.
Does anyone have any other good suggestions for dealing with this issue?
Thank you.
Okay, this is a tricky one. I just finished a project where we used this open-source library to display HTML: http://code.google.com/p/flex-htmlfilter
It handles lists, tables, etc, and is pretty easy to work with. But, I don't think it supports the trademark symbol. It does support some of the others, though.
I'm using it to pull content from a CMS and display in my flash movie. It has worked great, and allows me all the flash styling flexibility I need.
I don't know if this is a good solution for all problems, but if you want to use a RichText control you can load FlowText in to it which allows you to use more HTML, including superscript and other glyphs, like the ones you want to use.
How to use superscripting in flex?
Related
I've got a webpage in standard FAQ format, with each question listed as a link to its answer.
We have several hr elements that have been used as anchors - each with a unique assigned id attribute - but links don't appear to be functioning properly.
Anchor links appear to work with other elements, but not hr - and I can't find anything online suggesting that hr elements cannot be targeted as anchor points.
Can I not use hr elements for anchor link destinations for some reason?
Example, using edited content:
<ul>
<li>What are the technical requirements for using the online application system?</li>
<li>Which job board should I use to apply for a position?</li>
</ul>
<hr id="requirements" />
<h3>What are the technical requirements for using the online application system?</h3>
<hr />
<p>The COMPANY uses an online application system for most of our job postings. This system lets you create a profile to keep track of the positions you’ve applied for, provides confirmation that your application has been accepted, allows you to edit submitted applications up until the posting closing date, and notifies you via email of jobs that match your skills and interests.</p>
<hr id="jobboard" />
<h3>Which job board should I use to apply for a position?</h3>
<hr />
<p>COMPANY has a variety of employee groups, and certain groups may apply for positions on specific job boards. Here is a summary of what job board you should be checking:</p>
I can't find anything online suggesting that hr elements cannot be targeted as anchor points.
The spec mandates that any element with an ID may be designated as the target of a URL fragment. No exceptions are stated, which implies that the rule applies to hr.
Linking to an hr element not working appears to be an issue with Google Chrome. It works just fine on every other browser. I'd consider that a Chrome bug.
As a workaround, remove the hr elements (all of them) and reassign the IDs to the h3 elements. That is how IDs are intended to be used. The hr element is only needed when dividing a single section into discrete subsections where subheadings are unnecessary or inappropriate. Since each entry in the FAQ is a section in its own right with its own heading, those hrs are superfluous at best and inappropriate at worst. If you want horizontal lines to appear between sections, add borders with CSS instead of using hr elements.
<ul>
<li>What are the technical requirements for using the online application system?</li>
<li>Which job board should I use to apply for a position?</li>
</ul>
<h3 id="requirements">What are the technical requirements for using the online application system?</h3>
<p>The COMPANY uses an online application system for most of our job postings. This system lets you create a profile to keep track of the positions you’ve applied for, provides confirmation that your application has been accepted, allows you to edit submitted applications up until the posting closing date, and notifies you via email of jobs that match your skills and interests.</p>
<h3 id="jobboard">Which job board should I use to apply for a position?</h3>
<p>COMPANY has a variety of employee groups, and certain groups may apply for positions on specific job boards. Here is a summary of what job board you should be checking:</p>
In theory, the HTML 5 Specification does support the use of an ID attribute on an <hr> element (via support for Global Attributes) , however in reality, it's going to come down to an issue of which browsers support this practice.
If you're finding that some browsers aren't working, I would highly encourage you to re-write your HTML code using more common coding techniques, like using <div> or <a> elements instead.
I'm still trying to familiarize myself with HTML5, and there's this stuff which feels a bit confusing....
I once read in Jeremy Keith's book and HTML5 Doctor (via this question) which say that HTML5 makes it possible to use multiple h1s. In HTML5, each section can have its own heading element so it is okay to have more than one h1. I've seen a Wordpress theme framework, "underscores", which seem to apply this in the fullest.
However, this may seem to pose problem for older browsers (yet to support HTML5) in defining the site structure/document outline. Also, it poses problem for SEO.
I stumbled upon Matt Cutts's (from Google) video and re-read Keith's book which recommend limiting the use of h1 and use the conventional document outline (only use one or two h1 per page, followed by multiple h2, h3, etc). Matt Cutts also imply that multiple h1 is not too good for SEO.
However,
I previously never paid serious attention to site structure/document outline. So I never know how old browsers (pre-HTML5) read a site structure/document outline. There exists a HTML5 outliner, but I can't find outliner for HTML4.
Matt Cutts's video (regarding HTML5 and SEO) is published in 2009. I
don't know if Google already support the new HTML5 way of outlining
document.
So my question is, if I want to:
Support older browsers (e.g. Firefox 3.0 and IE 6) to display correct site structure/document outline
Have a good result in SEO
Which one should I use: multiple h1s (the way it is done in HTML5) or the conventional way?
This HTML5 one (example taken from HTML5 Doctor):
<h1>My fantastic site</h1>
<section>
<h1>About me</h1>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<section>
<h1>What I do for a living</h1>
<p>I sell enterprise-managed ant farms.</p>
</section>
</section>
<section>
<h1>Contact</h1>
<p>Shout my name and I will come to you.</p>
</section>
or the conventional way?
<h1>My fantastic site</h1>
<h2>About me</h2>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<h3>What I do for a living</h3>
<p>I sell enterprise-managed ant farms.</p>
<h2>Contact</h2>
<p>Shout my name and I will come to you.</p>
Use the new format.
Plenty of people will use h3s or h2s, and that's perfectly fine as well.
In fact, they'll use the section or article or header or footer elements offered by html5, and then use h3 or h4 as headings for that document-segment (for fear of SEO penalties / legacy styling|layout quirks).
And that's fine, too.
If you watch Cuts' video again, he says to keep the h1 use to a minimum -- only using multiples when they're really warranted.
That hasn't really changed at this point.
Google isn't going to murder you for having multiples.
Google IS going to expect each one to mean that there was a fundamental change in content.
That's true whether or not you have the sectioning (section/article/etc) elements in there or not.
Google has also gotten to the point where they're properly spidering AJAX-only, or JavaScript-dependent websites, and have their own rich-content metadata system... ...they're sophisticated enough to parse section or article.
Worry more about the quality of the content, and if you're ready to take it on, the Google-specific metadata which they use for search-results, etc...
...and let Google worry about navigating the semantics (as long as you're using them well, and not doing anything shady).
Lesser crawlers, who knows... ...but that's on a per-crawler basis, and most people only need to be concerned with Google and Bing and Yahoo, with other crawlers either feeding off of Google, or being very domain-specific (like if you want to rank highly on an opt-in, car-rental crawler for some reason... ...at which point you should be supplying an XML/JSON feed of some sort, anyway).
deathlock, your second example doesn't contain any sectioning elements. However, you could use sectioning elements with headings other than h1. I think that's the point of your question:
h1 in every sectioning element
<section>
<h1>…</h1>
<section>
<h1>…</h1>
</section>
</section>
or "calculated" heading level
<section>
<h2>…</h2>
<section>
<h3>…</h3>
</section>
</section>
Semantically/technically, they are the same.
SEO shouldn't be a problem, because "h1 everywhere" will be (and already is) used all over the web, and the major search engines know this. If they want to support HTML5, they have to understand the outlining algorithm. I bet that their crawler/APIs already correctly calculate the real heading level, like the HTML5 outliner does, for example.
The only reason why you'd want to use h2-h6 as sectioning element heading would be old accessibility software, e.g. screenreaders. They usually offer an outline menu, so the user can jump directly to a certain heading. So if you always use h1, older screenreaders, that don't know HTML5, would announce all headings as h1, because they don't calculate the correct outline levels. However, Jaws 13 for example (current version of a screenreader), only gets "h1 everywhere" for HTML5 correct in IE, AFAIR, and it gets confused if you use other heading levels in a HTML5 page. This is, of course, a bug, but it's a nice example that sticking to the "old way" will not always work for newer software.
So you might get problems either way.
In my opinion you should stick with what the HTML5 spec recommends, and this would be: use h1 for all sectioning element headings. Because this specification is what future user-agents, accessibility tools, search engines and other services/softwares use to build their product.
However, it depends on your use case, of course. If you know your visitor statistics, you should use them to make the right decision for your special case. E.g. if your site will not live for many years in the future, use what is now best supported.
The best way is to use HTML5 and use this link to make them work in the old browser since Google is ready your website way better and consider you use new technology (so that your site is better) if you use the new tags.
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
Put it in the head section of your site and it'll work fine for old IE versions
I wonder many websites put tag inside tag, from the specification the nav tag has anchors tags, and here the example in w3schools, why many sites make like this:
<nav>
<ul>
<li>Home</li>
<li>About</li>
</ul>
</nav>
Is that correct or we should only make like this
<nav>
Home
About
</nav>
In general it's not required, however it's very common practice to put your navigation items in list and using CSS displaying them inline (if required). That is not only advice for HTML5 - if you'll disable for an example CSS in the browser, your menu will be displayed as:
start about me contact (can you read this?)
with list it will be:
start
about me
contact
Consider yourself which version would you like to see in case of problems with displaying design.
What is important to note here is what the new tags like nav, section, header, footer, etc were designed for. In and of itself, these tags behave no differently than a div. The reason people are starting to use them on their html5 sites is to provide context to the document. While I roll my eyes when I hear terms like "Web 2.0", these terms do convey a change in thinking about how we use the web. Whenever you hear "Web 3.0"... ugh, all it really means is that people are trying to think about how to make the web more semantic, meaning the user experience is more customized based on user behavior and preferences. Tagging your document with these types of tags helps provide that context. The implementation of how it will present itself, however, is still up to you, and I believe both examples you provided are perfectly valid.
There is a decent article here which discusses this in more detail:
http://html5doctor.com/lets-talk-about-semantics/
I have always taken the view that any tag that exists purely to house another, single tag, is extraneous.
However semantic and sensible mark-up is an inexact science, so people have different views.
As per "nav" element specification, it represents a section of a page that links to other pages or to parts within the page. Specification does not mandate any particular structure whithin "nav" element. "ul" block, on the other hand, groups navigation links together for logical and/or practical purpose. Using lists for blocks of navigation benefits users who are navigating the Web with assistive technology, because screen reader may skip entire blocks of navigation, jumping from one navigation level to another.
References:
http://reference.sitepoint.com/html/ul
http://html5doctor.com/nav-element/
I would say:
Yes, if is multilevel nav (so will have it hierarchical ordered).
No, in all other cases: you save data, you gain speed, and readability.
IMHO UL should be use for showing actual Unordered List, the same is said about tables, that should show tabular data.
I was walking through the new html 5 features and I saw and tried a lot of new tags to see what kind of affect they have on the browser but honestly I didn't see much difference.
So lets talk about <time> tag as an example :
If you write down <time>10:00</time>
obviously it shows 10:00 on the page
but I mean I was expecting something
advanced like formatting. For example,
if I write <time>10</time> it could
format it to 10:00 instead of just
showing 10 on the page.
Also another example can be <time
datetime="2008-02-14">Valentines
day</time> it also shows just
Valentine days on the page and
nothing more. No tooltip, not a fancy
animation nothing like them.
They are tags like this, and if it is needed I most probably will use span or something else and use some kinda js code to make it more appealing and that's all.
So I am not just talking about <time> tag here, any other tags like that.
Eventually, my question is why and where we need to use them.
My best guess it to make source code more readable by codes and crawlers maybe or they can be used for semantic web. But even these answers didn't satisfy me.
They are definitely used for adding semantic meaning to the markup. For instance:
<div class="post">
<h1>Example Blog Post</h1>
<div class="entry">
<p>Blog text goes here...</p>
</div>
<div class="entryFooter">
<p> Posted in example category.</p>
</div>
</div>
is not as readable as using the HTML5 tags of:
<article>
<header>
<h1>Example Blog Post</h1>
</header>
<p>Blog text goes here...</p>
<footer>
<p>Posted in example category.</p>
</footer>
</article>
It also helps to make the markup more readable to developers and I think it makes styling a lot easier. The <time> tag falls in this boat as well as it provides more semantic meaning in your markup than a <span> tag would. This way programs in the future or browsers might be able to use that semantic data to change the time per the user's local time zone as an example.
Semantic markup gives power back to users
It is possible that you can write something like:
<time datetime="2010-10-20" />
and the browser will render it as:
3 days ago
or in some other languages of the user's preference.
Semantic markups are all about these kind of things. We are tagging text for their 'meaning', instead of for visual styling. The styling is just an extra. Once you get the meaning right, the user can style these markups to their preference, not to the author's preference. This wasn't possible with style markups, a bold markup may be used for adding emphasis, or it may be used for headings, while in other places it may be used for the first paragraph of an article. A time markup is always used for time, an emphasis markup is always used for adding emphasis, and nothing else.
Many browsers support user stylesheet to allow a user to override the stylesheet used by the website, but they are very rarely used since they are currently useless, because they apply styling indiscriminately (and because of the lack of tool support, not every users fancies writing CSS code; but we can argue that the lack of tool support is because there are not many that will use these tools, given the limited usefulness they have with formatting markup).
Then, there is the non-visual browsers; some people with visual disabilities uses aural browser. These browsers doesn't work well with formatting markups.
The semantic tags are, as you guess, used for adding semantics to web pages. Browsers won't generally render the differently by default, but you certainly can style them how you want with CSS.
I don't think html tags should be used to provide any style information - that's for css. However, you should use the new tags when appropriate. If you're making an html 5 website, why use the <span> tag for a time, when you could use the time tag? A lot of these new tags are no different that their predecessors in their functionality, but they do allow you to add more meaning to your mark-up.
When a web site is licensed under Creative Commons, I use the rel-license microformat. When a web site is licensed under regular copyright, I have a boring paragraph element.
<p id="copyright">© 2008 Example Corporation</p>
That id attribute on there is just for CSS styling purposes. I'm wondering if there's some better way to markup a copyright notice that is more semantic. Is this a job for Dublin Core metadata? If so, how do I go about it? (I've never used Dublin Core before.)
Some web sites advocate using a meta tag in the head element:
<meta name="copyright" content="name of owner">
Which might be seen by search engines, but doesn't replace the user-visible notice on the page itself.
Thanks to Owen for pointing me in the direction of RDFa, I think I've got the solution now:
<div id="footer" xmlns:dc="http://purl.org/dc/elements/1.1/">
<p id="copyright" property="dc:rights">©
<span property="dc:dateCopyrighted">2008</span>
<span property="dc:publisher">Example Corporation</span>
</p>
</div>
Depending on the situation, it might be better to use dc:creator instead of dc:publisher. From the Dublin Core web site:
If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser or ambiguous responsibility, other than creation, use Contributor.
I will also be adding a meta tag to my head element for search engines that don't support RDFa yet.
<meta name="copyright" content="© 2008 Example Corporation" />
Have you taken a look at RDFa? It was recently accepted as a W3C recommendation. I mention that just in case you want to take a look at other aspects of semantic structure it recommends. The licensing part is the same as the format you currently use. (So in that sense to answer your question, I think you're handling it correctly, assuming people adopt RDFa)
For lazy people who don't want to click links:
// RDFa recomendation and rel=license microformat
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
a Creative Commons License
</a>
Probably the most semantically correct way to mark it up is with a definition list.
<dl id="copyright">
<dt title="Copyright">©</dt>
<dd>2008 Example Corporation</dd>
</dl>
Why not use the CC format, but indicate that no rights are granted?
In any case, the main problem with the use of the CC formats is that people do not clearly identify which elements of the webpage that they appear on they apply to.