Slashdot Mirror
XHTML 2.0 Working Draft
Rytsarsky writes: "W3C has released the first public working draft of XHTML 2.0. 'XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions.' Some notable changes are the introduction of navigational lists (<nl>), sectional hierarchy with <section>, and the long-awaited deprecation of <br> in favor of <line>."
i claim this for uiuc.test
So will anyone ever implement this? The browser wars have pretty much died down, and no one follows the standards anyway. New browsers are all about bloatware anymore.
By whom??? I don't think there's a single web designer in the world who'd consider LINE to be a better replacement for BR.
So, when is Slashdot going to start offering XHTML 2.0 as a page rendering option? Actually, when is Slashdot going to start offering any sort of valid HTML as a page rendering option?
I currently use a 'section' tag to divide up my XML, then use XSL to mark up those sections into XHTML, using the name and depth of each section to generate a table of contents.
An example: this XML is rendered to this XHTML.
The new tags make a lot of sense IMO. It seems the W3C have some understanding of how HTML is used in the real world.
"Reportedly, this draft was designed with Linux in mind."
Most sites aren't even HTML 4 compliant, let alone XHTML 1.x compliant. That's ok, becuase most (as in, probably 75 percent or more) of all browsers out there have broken HTML 4 compliance (I include CSS support with that), so even if the sites did use Completely Correct XHTML, the fucking clients wouldn't render it as the new standard dictated. For all practical purposes, the only thing sure to work right now is HTML 3.2. It was only relatively recenly that we could sort of begin to forget about the 216-web-safe colors resulting from widespread 8bpp video adaptors and the layout restrictions of 640x480 mainstream moniter sizings. I wish I was wrong, I really do. New, logical standards are good, and I'm glad somebody's doing the work. But honestly, does anyone really expect for this to be available as a real-world development option any time in the next four-plus years? I'm sorry to be harshly realistic, but somebody please wake me up when the web's layout code is logical, clean, and supported by all the clients we have to worry about...
This is not to say that XML is not useful as a web development tool, quite the contrary. Nothing else comes close to giving you the multiple-generated-format flexibility (parse it to WML, parse it to HTML, parse it to PDF, parse it to VoxML, parse it to ...) needed to support all the crazy things people are using to access http resources these days. (The irony here is that as mainstream browsers have stabilized/stagnated, a combinatorial explosion of types of clients has taken place. The idyllic world of infinite permiability of information promised, in essence, by XML is a long way off... but it's close enough to be tantalizing. I can't wait for the day when I can really do just about anything from a web terminal that is my cellphone that I can do now sitting here in front of my workstation.)
News for Geeks in Austin, TX
Is there no tag or equivalent in this standard?
I didnt have a DTD to grep through since they havent released it yet, but I hope there's still a convenient way to place images on a page.
Anyone care to point out the glaringly obvious (yet overlooked on my part) location of this in the WD?
Much Appreciated,
/~mikeg
I think that this new specification in not necesarally design for HTML "programer" but more for ppl who create wysiwyg editor. When their "save as html" option saves as XHTML2.0 then you will see more pages on the web. Let's face it, 90% of the pages on the web are created by wysiwyg editor(dreamweaver, front page , word, star/open office). _Most_ ppl don't use notepad, let alone emacs or vi. Even if I use emacs, and most of us use emacs or vi, doesn't mean that most ppl who publish on the web use a text editor.
What I am trying to say is that, the first step to acceptance is the browser, then the wysiwyg editor, then the "html coders".
--=.=-- www.cyber2000.qc.ca
Significantly more noticable than is that they've finally done away with in favour of (not deprecated it - removed it!).
This makes so much more sense.
- Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and
:hover as seen on CSS/Edge - <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
- New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
- <a> is still here; no XLink in this draft, despite it being a recommendation.
- Forms are now replaced by XForms, also a Working Draft.
- No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.
- Frames replaced by XFrames (nothing public yet).
- A few more global attributes, and the use of XML Events for scripting events.
Also, for those interested in such things, the CSS 2.1 Working Draft has been released too.of course people will complain XML is bloated or slow or 100 other things, but having worked with a couple different content management systems, it would make frequent edits easier. It gives more power to non-technical people who want to change their site and free up HTML coders from doing retarded text edits. Plus it might help the adoption of semantic web and slowly move the industry towards a format that describes the content is greater detail. Generating conformant XHTML from XML is straight forward from personal experience. If getting millions of website to change was as easy as writing a new XHTML spec, the web would become a slightly more organized space.
When a web based application is displaying content aquired from other sources a great deal of effort is required to render the content harmless. In this article on kuro5hin it details the efforts by Yahoo to ensure that malicious javascript is not rendered in web mail.
I think the markup language should allow the page designer to disable potentially dangerous features such as javascript within particular frames (or other elements), but still allow it to work within the page as a whole.
<IFRAME SECURITY="scripting=no,images=yes" SRC="...">
</IFRAME>
Seems like if they're going to make it backwards incompatible, they should change a lot more. For example, are nested tables really the best way to lay out a page? Can't we come up with something better than that? (Without hard-coding coordinates -- I'd like something like the GTK or Swing layout methods.) How about the script and noscript tags? Any chance we can stop having to put comments around the script code? How about separating the 2 distinct uses of anchor tags?
Software sucks. Open Source sucks less.
Hell I don't like reading anything on the w3c site. Especially RFC's!!!
You'd have thought they'd have come up with a 'decent' standard for writing human readable standards. (as apposed to executive readable)
It's bwoken, I tried to scale it to fit my favorate browser size but it just stayed the same fatness.
And the black ground is white? I like green on black just like my system options say.
But seriously, I use tables because they support scaling &co. Can you do that with CSS?
thank God the internet isn't a human right.
"Fweeky" writes:
I do not get a secure fuzzy feeling about this element, when I read the relevant w3 spec, and see:
So, instead of the relatively safe and well-defined <img> tag, user agents must now support a strange new <object> tag, which (at some unknown author's whim) may decide to run external applications and feed them arbitrary untrusted data.
The w3 example shows the user agent happily downloading and running some unknown chunk of Python code, in the blind hope that it does nothing more "display a clock"!
At a minimum, this means the user agent will need a lot of security configuration, to specify which MIME types it's allowed to handle at all, and exactly which external applications should be allowed to process them. Even then, I predict an amazing new ecosystem of exotic exploits.
>;K
>;k
Um, is nothing new; it was in HTML 4 and looks much the same.
It's effectively an img/embed tag which can be nested to allow the UA to fall back if it doesn't support something.
The draft's example includes showing the use of embedding an applet - so what? If the UA wants to execute it outside a sandbox, that's no the W3C's problem, just like Java or ActiveX security or Flash's security isn't their problem. If Python applets were ever to appear I'm sure they'd be secured similarly.
However, rather that asking "how many are using old browsers" it should be "what does the new standard give us aside from being 'new'?"
1. Device independence through screen or printable style sheets is the main thing. This can also be achieved server-side ("click here for the printable version of this page"). Although there's another page view when you want a printable version I believe a usable interface is more important (after all, newer techniques for layout such as CSS-P affect the usability in older browsers).
2. Abstraction is often said about newer standards CSS and HTML. CSS offers more abstraction but the header/footer/template is still part of each HTML page. So the menu can't be changed for different devices (cellphones might want less navigation options for a smaller screen - for example). In practice this header/footer/template requires server-side includes or a templating engine. The abstraction CSS gives is nice, but we all still have to use non-standardised templating mechanisms. This isn't available to the client in a standardised way. So newer standards offer abstraction, but not much.
3. Even HTML 4.0 wasn't implemented by IE4 and Netscape 4 - so add on another 5-10% to that market. Netscape 4 can't set margins in CSS. IE4 has poor support for HTML 4.0 accessibility. Most browsers support _enough_ of HTML 4.0, but still over 50% of browsers don't support HTML 4.01/XHTML. They support enough of the standard to be usable, but not enough to be compliant.
I guess my point is that browsers are behind the standards, and browsers are the real world and able to enforce defacto standards. I don't encourage this, but when a browser has turned good (Netscape) there's no harm done is supporting the temporary disobidience of 4 proprietary margin attributes so that the people (who in all don't care about standards) get a better page.
So push for standards as a political thing but don't get picky on helping browsers built in an era that didn't care about standards. They were all growing up at the time ;)
That's true - the current browsers won't render it. And they can barely render various other simple features, blah blah blah. However, this sets the stage for several years from now - when browsers will render it. I'd figure four years.
For example, just now, it's becoming possible to design web pages with CSS and relatively plain HTML markup. CSS having been established in late 1996, according to this. So, figure four or five years from now we may start designing web pages in XHTML 2.0, and Dreamweaver version 53 or whatever might actually spit out pages in XHTML 1.0.
I know it's annoying that progress is so slow, but that's how it goes.