I would like to put a date of article on ky site. I there a semantic tag for this?
[font=verdana]In HTML5, there’s the time element. You would put something like
<p>This article was written on <time datetime="2012-12-08">8 December 2012</time>.</p>
See more on Best of Time by Bruce Lawson.[/font]
Thanks. Ya that’s all I find googling. Can you use that tag with a html4 doctype?
It won’t do anything … browsers will treat it just the same as <tagijustmadeup attribute="random">...</tagijustmadeup> … there is no way to indicate a date/time in HTML4 that I’m aware of.
Ok thanks . I tried.
There is no difference. Since all browsers with an “HTML5” parser will consider all text/html as “HTML5”, there is really no difference whatsoever between an “HTML4” doctype and an “HTML5” one regarding tags like these.
The sole difference Eric would see is whatever the validator wants to whine about… and in this case I wouldn’t bother listening to it.
That and he’d need to create it for IE with JS if he wanted to style it for everyone. It’s usually an inline I believe.
Indeed. That’s not new with browsers that have an HTML5 parser, though, browsers have always supported whatever elements they support even if the doctype doesn’t “match”.
Browsers have never made use of the doctype to determine how to parse the associated code - unfortunately.
They lose all the real benefit of having their standards defined using SGML (which was introduced in HTML 2) as a result of that which is why those working on HTML 5 decided to drop the SGML doctype completely and add a new HTML tag in its place (that just happens to look identical to the short version of the SGML doctype for HTML).
I just used “em” for the date. No reason other than I wanted it italisized. Seems appropriate.
Isn’t that what they called parsers who did the “unified error rendering” (since that’s about when they also started adding in the new tags as well)?
,
Once someone decided to call it a versionless “living standard”, the idea of speaking about who supports what got even harder.
I’m not sure what you mean. Browsers certainly added support for some post-HTML4 features before implementing the HTML5 parser (canvas was one of the earlier ones). The HTML5 parser didn’t change anything for the case we’re discussing here – whether an element is supported depending on the declared doctype.
How so?
How so?
With versions (of anything), you can state in broad strokes things like “x supports y”. Like I can say, of a whole bunch of features, “Those are new in Javascript 1.8, I can’t use them because IE on XP (which happen to also be versioned: IE6, 7 and 8, but certainly not 9) blah blah” and other developers know what I’m talking about, without me needing to name every individual feature.
I could also say “specific feature X is not supported in [IE6, Safari 4, completely broken due to a trunk regression in FF 2.0.0.8…].” Back when browsers had versions.
With HTML versions, I could make statements like “In HTML4, a fieldset must be accompanied by a legend, while in XHTML1.0, this requirement has been mysteriously and silently dropped.” Every developer would know exactly what I meant, and how it would affect them or not. Whether it matters more for a developer, a browser (version), or just the validator, isn’t really the issue, but more that we have names for things created in certain times. Versions.
While many have been promoting the idea of “living standard”, which I assume is partially to encourage developers to speak on a low, per-specific -thingie/feature/bug/joe’s validator/nightly build basis, it does remove our wants and needs as developers communicating with each other to be able to talk about generalities of time. Which is why on forums everywhere, developers are still saying “HTML4”, “HTML5”, “XHTML”, “CSS3”, etc. Like this thread’s original question for example.
Maybe we developers are wrong to want to continue to do this, now that neither specs nor features are being released in big batches anymore, but currently this is ending up with me trying to explain stuff like this to my boss:
“Well, despite your user-hating insistence of using the new placeholder attribute in place of a label, we still need to give direction to those using IE-on-XP, Firefox before they started releasing new versions every second, Safari on Windows and on OneOfThoseBigCats-OSX, oh and those versions of Safari and Opera who support placeholders but not on textareas, Opera Mini users, and your mom’s Blackberry…”
Because we’re sometimes forced to explain technical things to non-technical people, where listing gritty details doesn’t really help, even if it’s more accurate.
What makes more sense to the boss is:
“Placeholder is an HTML5 thing, and according to our stats we still have 32% users of HTML4 browsers, so we’d better at least sneak in a label for them.”
Or
“The bugs mentioned recently on this mailing list have been fixed and commited in Orca 3.7, which finally has support for Python 3, and requires that you have Gnome 3 installed.”
(or for that matter, things like “Print is not a function in Python 2.x, but is a print() function in 3.x…” this is why we have versions, so we can refer to stuff in a way that others understand).
With a versionless living standard, it’s like asking “Does Firefox support x?” (answer: some firefoxes do, did you update on the 22 of March 2012?), or (and we all hear this one) “Does this software support the latest HTML?” (uh… what is the latest HTML? Everything’s, like, in the flow, man)
I suspect some of us will simply resort to using actual dates when we need to discuss things like support, since version numbers are going away. I can imagine something like this:
“Well, before commit:9a7h7d231498.1.12 in May, print was not a function, but in that commit we changed it to a function, oh and we added unicode support. Pull from master if you want print as a function in your programs.”
Browsers still have versions, though.
If you want to use names that are lies, that’s fine, nobody stops you from continuing to use “HTML5” and “HTML4” when communicating with your boss. However, for this case, I don’t see what’s wrong with, e.g.:
“Placeholder is a relatively new thing (only a few years), and according to our stats we still have 32% users of browsers that don’t support it, so we’d better at least sneak in a label for them.”
How is that question different from “Does Firefox support HTML5?” before HTML5 was renamed to HTML? Or why would you answer it differently?
I don’t see why that is a bad thing. 
but it isn’t
(appropriate, that is)
if you want italics, use the I tag
if you want emphasis, then okay, go ahead and use EM
True. Ok I mean to day I wanted it italisized and emphasized.