Forum Moderators: open
So this:
"< p >Text here
< br / >And here< /p >"
Becomes:
"< p >Text here
< line >And here< /line >< /p>"
(Spaces added to prevent HTML working.)
Makes sense if you think about it, but what will happen to older browsers who view the page, such as NS4? Will we see a mix of code to ensure pages work in all browsers?
Also, will we see new XHTML-only browsers emerge?
The p element represents a paragraph.
In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent the conceptual idea of a paragraph, and so may contain lists, blockquotes, pre's and tables as well as inline text. They may not, however, contain directly nested p elements.
<p>Here is some text.
<line>Here is another line.</line>
<line>Here is another line again.</line>
<line>Here is yet another line.</line>
</p>
You only use <line></line> where you want to sctrucure your 'subparagraph' with line breaks.
It can be used in conjunction with CSS to count line numbers.
Here is the w3c text:
The line element represents a sub-paragraph. It is intended as a structured replacement for the br element. It contains a piece of text that when visually represented should start on a new line, and have a line break at the end. Whether the line should wrap or not visually depends on styling properties of the element.
Attributes
The Common collection
A collection of other attribute collections, including: Core, Events, I18N, and Hypertext
By retaining structure in text that has to be broken over lines, you retain essential information about its makeup. This gives you greater freedom with styling the content. For instance, line numbers can be generated automatically from the stylesheet if needed.
For instance, for a document with the following structure:
<p class="program">
<line>program p(input, output);</line>
<line>begin</line>
<line> writeln("Hello world");</line>
<line>end.</line>
</p>
the following CSS stylesheet would number each line:
.program { counter-reset: linenumber }
line:before {
position: relative;
left: -1em;
counter-increment: linenumber;
content: counter(linenumber);
}
It will be awhile before I get 'un-confused'.
What is really confusing to me is that after the past few months of trying to remember the difference between CONTENT and STRUCTURE/STYLE it appears that some of these new XHTML elements are Structural/styling elements.
In short:
Structure represents the elements used to build a page. Each element has default display properties associated with it.
Most elements serve as containers for content, several, act only as structural elements and cannot contain content (empty elements).
Style can be applied to elements to modify their default appearance and display properties. Style instructions can be handled using CSS and may be served externally via style sheets.
[edited by: papabaer at 3:04 pm (utc) on Aug. 7, 2002]
nl sounds cool -- it looks like it's intended to be some kind of a drop-down or cascading menu. Wow.
I notice b and i have gone. Okay, they were presentational tags, but they were useful presentation tags. Now we have to use <span> and CSS, more code bloat.
Somebody mentioned h. What's h?
what about older browsers
What about older browsers my bum! What about New Browsers!
All these new tags look really cool, I really like <line>, but we won't be able to use any of it for quite some time I guess.....
anyone have any info on what the first browsers to support it will be?
Nick
h is the top level for the traditional h1, h2, etc. Not sure how it is used though.
Also a new section element that is used with the h element. Here is their example:
<body>
<h>Events</h>
<section>
<h>Introduction</h>
<p>....</p>
<h>Specifying events</h>
<p>...</p>
<section>
<h>Attaching events to the handler</h>
<p>...</p>
</section>
<section>
<h>Attaching events to the listener</h>
<p>...</p>
</section>
<section>
<h>Specifying the binding elsewhere</h>
<p>...</p>
</section>
</section>
XHTML 2.0 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2.0 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions. Application developers familiar with earlier its ancestors will be comfortable working with XHTML 2.0.
Shane McCarron, Applied Testing and Technology
Jonny Axelsson, Opera Software
Beth Epperson, Netscape/AOL
Ann Navarro, WebGeek, Inc.
Steven Pemberton, CWI (HTML Working Group Chair)
I don't see any reps from MicroSoft, probably a good story behind this one.
Oh... I see, you have your own version, well in that case...
Sheeesh!
Nick
rewboss, instead of using b and i, i'm pretty sure you can use strong and em.
Actually, no. strong and em are for emphasis, b and i are for presentation. The difference becomes clear if you imagine how an audio browser would read out the following sentences:
<p>You should <em>never</em> try this at home.</p>
<p>She felt a certain <i lang="de">schadenfreude</i>.</p>
That second paragraph will now have to be rewritten:
<p>She felt a certain <span lang="de">schadenfreude</span>.</p>
plus, in the style sheet:
span:lang(de) { font-style: italic; }
This will affect me more than most of you, I expect, since I work in a bilingual environment. It's just a pain, that's all.
<h> is easy, it's an alternative to <h1> through <h6>. To be honest, I've been wishing for a long time for a way to style all heading tags in one go without having to write h1, h2, h3...
<nl> stands for "navigation list". Sounds perfectly logical to me; it's analogous with <ol>, <ul> and <dl>.
Formatting poetry in HTML is next to impossible, because the line is the basic structural unit, and with current HTML there is no way to style lines. The line element will allow very elegant liquid layout that will bring web publishing of poetry up to the most basic print standards. You can see why it's important if you consider poems with very long lines that must wrap, as you find in Whitman or Ginsberg, for example:
<line>and rose reincarnate in the ghostly clothes of jazz in the goldhorn shadow of the band and blew the suffering of America's naked mind for love into an eli eli lamma lamma sabacthani saxophone cry that shivered the cities down to the last radio</line>
<line>with the absolute heart of the poem of life butchered out of their own bodies good to eat a thousand years.</line></p>
Now this can be perfectly formatted with hanging indents and fluid layout, etc. Aren't you thrilled? ;)
I think old browsers will simply ignore this markup, so it should be possible to go through and insert it now and wait for the browsers to catch up, yes?
<p>ACME Widgets,<br />
24, Somesuch Street,<br />
Anytown</p>
with
<p><line>ACME Widgets,</line>
<line>24, Somesuch Street,</line>
<line>Anytown</line></p>
which is just extra work and nothing to show for it, except the ability to add styles to each individual line (which we can already do with <span>, if we really need to -- which I usually don't).
Older browsers, of course, will ignore <line>. As a consequence, they will display the whole lot in one line:
ACME Widgets, 24, Somesuch Street, Anytown
1) XHTML isn't supposed to be backwards-compatible with HTML browsers like Navigator 4 because XHTML isn't HTML, and shouldn't be served as text/html. The ability to serve XHTML 1.0 as text/html was a transitional strategy: if you're serving XHTML 2.0 (or even XHTML 1.1) to an HTML browser, you're breaking spec. (I've ranted about this distinction before in this forum.)
2) If XHTML 2.0 is served as text/xml+xhtml to a real XHTML-compatible browser, you can do what this guy did [w3future.com] and write an XSL style sheet to allow older (XHTML) browsers to convert XHTML 2.0 to XHTML 1.0.
So don't use it, I'm almost not using <br /> why should I use line? I don't see many cases when it can be used anyway.
Point taken about XHTML 2 not designed to be backwards compatible, but it does pose a slight problem. We now have two entirely different standards: HTML/XHTML 1 for older browsers, and XHTML 2 for newer browsers, and they won't be compatible. That's an awful lot of extra work for an awful lot of people.
I would congratulate Sjoerd Visscher, but his solution won't work for a lot of browsers that will almost certainly still be in use in two years' time, and will be tricky to implement anyway. And his site is broken in IE5, by the way.
And his site is broken in IE5, by the way.
ah...must be one of those "forwards compatible" pages... :)
Well, my fresh IE 5.5 install asks to download the page instead of displaying it, but it's been giving me other ****, so maybe it's just me. Lynx definitely asks me to download it. Looks great in Opera and Mozilla, though. That does it. I'm converting all my pages to XHTML 2.0. Accessibility be damned. Backward compatibility be damned. IE 5 be damned. (IE 5: the Netscape 4 of the new generation.)
Visitors be damned?
Tom
frames replaced by xframes;
forms replaced by xforms;
<img> dropped in favour of <object> (more code bloat).
Also, href can be applied to any element, not just <a> tags. I guess that will make graphical buttons easier. Instead of:
<a href="index.html" onmouseover="rollOn('home');" onmouseout="rollOff('home');">
<img src="/buttons/home-off.gif" alt="Home" id="home" /></a>
(using my rollover code), we could have:
<object data="/buttons/home-off.gif" type="image/gif" href="index.html" onmouseover="rollOn(this);" onmouseout="rollOff(this);">Home</object>
Hmm. Not much of a saving in terms of bytes, but probably easier to manage.
mbauser2 wrote "XHTML isn't supposed to be backwards-compatible with HTML browsers like Navigator 4 because XHTML isn't HTML, and shouldn't be served as text/html. The ability to serve XHTML 1.0 as text/html was a transitional strategy: if you're serving XHTML 2.0 (or even XHTML 1.1) to an HTML browser, you're breaking spec. (I've ranted about this distinction before in this forum.)"
Er, sorry, but the spec clearly states:
"The root element of the document must be html."
<line> Sounds like a lot of code bloat.
Yeah, so? People really have to lose the idea that good markup is about thin markup. It's not. Good markup is structured. After a certain point, good structure increases the amount of HTML in a file. That's a feature, not a bug, because the extra markup increases the ability of user agents to use the information in the file.
rewboss:
We now have two entirely different standards: HTML/XHTML 1 for older browsers, and XHTML 2 for newer browsers, and they won't be compatible. That's an awful lot of extra work for an awful lot of people.
Half the point of XML is that that XML is strictly structured to make it easily convertible to other formats. Webmasters who grok XML will make systems that can down-convert XHTML to HTML on the fly for text/html user agents. Webmasters who can't/don't do that are just using XHTML to be trendy. (I've ranted about that before, I think.)
ergophobe (quoting Mark Pilgrim [diveintomark.org]):
Well, my fresh IE 5.5 install asks to download the page instead of displaying it, but it's been giving me other ****, so maybe it's just me. Lynx definitely asks me to download it. Looks great in Opera and Mozilla, though. That does it. I'm converting all my pages to XHTML 2.0. Accessibility be damned. Backward compatibility be damned. IE 5 be damned. (IE 5: the Netscape 4 of the new generation.)
Of course that page [w3future.com] didn't work in those browsers! Those are text/html browsers, and that page is served as text/xml (which is also a legal MIME type for XHTML, but not the preferred type).
As for Pilgrim deciding not to backwards compatible, he's either being facetious, or he's one of the trendy ones who doesn't really get it.
rewboss:
Well, he's trying to implement a standard that hasn't even been finalized yet, let alone released, so he's really just cutting off his nose to spite his face.
Are you talking about Pilgrim or Visscher? Visscher only converted one page. That's not "cutting off his nose", that's a test. The W3C releases working drafts so people can play with them and provide feedback. Visscher is doing what a good geek is supposed to do: testing stuff.
Crecendo:
Er, sorry, but the spec clearly states:"The root element of the document must be html."
ARRGGGHHHH! Not the same thing! The whole point of Internet Media Types is that you don't get the media type from "leading bytes" of a file. Go read the XHTML media type note [w3.org].
mbauser2: Now I'm even more confused after reading your link. However, it does state that "text/html" "MAY" be used for XHTML 1.0 documents.
This sure is a complex issue. If you don't use "text/html", then will the browser be able to parse the document directly? Or, as mbauser2 indicates (in his paragraph "Half the point of XML..." "...using XHTML to be trendy"), perhaps we should be all be writing XML and using a program to parse this into whatever flavour we require (eg: HTML 4). Which would lead me to ask: then what is the point of XHTML?
