Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

XHTML 2.0 Working Draft 45

Posted by timothy from the navigational-lists-oooh dept.
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>."
This discussion has been archived. No new comments can be posted.

XHTML 2.0 Working Draft More

XHTML 2.0 Working Draft

Comments Filter:
  • i claim this for uiuc.test
  • 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.

    • Yeah, exactly, everybody was clamoring for two extra bytes? Really, the poeple who look at the code at this level probably don't care, and everybody else uses a WYSIWYGOIE editor and hense doesn't care.

      Besides BR makes sense, and LINE doesn't. Why not NL, or NEWLINE, or CR? LINE seems like a better replacement for HR then BR to me.

  • Hmm... (Score:3, Funny)

    by Karma Farmer ( 595141 ) on Tuesday August 06, 2002 @07:50PM (#4022272)
    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?
    • Somehow I think we'll be seeing those HTML 3.2 DTD's for quite some time to come, if the past is any indication of how fast real world stuff tracks the standards...

    • You kids!

      Back in my day, we had to parse ugly, non-conforming HTML by hand for every site and we liked it! None of this fancy-shmancy "valid" or "conformant" SML for us, no-siree.

      I've said it before and I'll say it again, give a kid a parser and he'll never learn how to parse himself.

  • 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 [rikkus.info] is rendered to this XHTML [rikkus.info].

    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.

    • But what would the second [rikkus.info] one look like in XHTML2.0?
      • It would look exactly the same, but those people using screen readers or braille terminals would find it easier to navigate, as the table of contents and the sections would be marked as such in a generic way, rather than simply being labelled as such or delimited with headers.

        Rik

  • You forgot a line (Score:1, Funny)

    by Anonymous Coward
    "Reportedly, this draft was designed with Linux in mind."

  • a resounding "eh?" (Score:3, Interesting)

    by StandardDeviant ( 122674 ) on Tuesday August 06, 2002 @08:51PM (#4022502) Homepage Journal

    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.)

    • <rant>
      Some of us (the obsessive-compulsives like me) try to make our sites compliant, or as compliant as possible while still rendering acceptably in most browsers (my targets: IE 5+, NS4+ (incl. Mozilla/NS6)).

      Unfortunately, most browsers are horribly broken (IE renders incomplete s, Netscape 4's CSS support is dodgy at best, both browsers can flake out with complex tables used to do positioning), so sometimes we need to leave in the "old-school" hints (like tags) to get things to work. That is NOT an excuse to not try to code to the standards. I have a number of sites which are XHTML-1.0 and 1.1 compliant (100% according to the W3C validator) that are in development now, and an equal number that are close to compliance with the exception of tags needed to support legacy browsers.

      Short version of this comment: Code to the standards and bitch out the browser makers to adhere to them AS WRITTEN. It's not the designer's fault(although it is our problem) that companies cant read a standards document and make appropriate changes (and yes, I realize that keeping up with the standards is time consuming and expensive - do it anyway. You want to be in this market, keep up.)

      </rant>
      • tables werent designed to do positioning. Check out my employer's web site [blue.net]. It sucessfully positions elements using CSS and is valid XHTML 1.0 transitional (note will be first thing tomorrow when I set the character encoding and remove that one stray border attribute, the boss wanted the mapquest block on the double.). Renders the same in NS 4.79, IE6, Moz1.0, and NS 7.0pr1 on windows 98. It would have strict complaince but how do I replace the "name" attribute for form elements?
        • 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?
          • That would be a NS4 hack, anything but fixed positioning with div tags gets you in trouble when a browser resizes. However, the background should have followed your stylesheet, I havent done anything special to force my colors. There is a way to set the priority of your stylesheet, dig around on w3c.org to get it.
          • Yes, with CSS-P you can have a percentage based layout which will scale with browser window size.

    • Re:a resounding "eh?" (Score:3, Insightful)

      by Fweeky ( 41046 )
      CSS 1 is about 6 years old, it's only seriously been usable for the last couple of years. Just because a standard isn't used much or handled properly doesn't mean it won't be eventually, or that the standard is worthless and hence shouldn't have been created.

      XHTML is already quite popular, because it provides a path to XML without breaking legacy clients. The top three clients already support parsing XML and rendering closely to the standards when it's served with the right Content-Type.

      XHTML 2 is another step towards this, loosing the legacy crap of HTML 4 and fixing problems without worrying about backwards compatibility. Hell, stick to the basics and you can provide for most of the tags for *current* clients with a bit of CSS.

      This is only a working draft, anyway. I wouldn't expect it to reach recommendation stage this year. Don't forget, they need two interoperable implimentations of each feature to even be concidered :)
  • 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,
  • 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".

  • Main changes (Score:4, Informative)

    by Fweeky ( 41046 ) on Wednesday August 07, 2002 @07:32AM (#4024100) Homepage
    For those who don't like reading WD's:
    • Navigation Lists [w3.org] (<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 [meyerweb.com]
    • <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 [w3.org]).
    • New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> [w3.org] element to go with each (nestable) <section>.
    • <a> [w3.org] is still here; no XLink [w3.org] in this draft, despite it being a recommendation.
    • Forms are now replaced by XForms [w3.org], also a Working Draft.
    • No more <img> or <embed>. They're replaced by the technically superior <object> [w3.org]. 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 [w3.org], and the use of XML Events [w3.org] for scripting events.
    Also, for those interested in such things, the CSS 2.1 Working Draft [w3.org] has been released too.

    • Re:Main changes (Score:2, Informative)

      by Rytsarsky ( 319094 )
      Frames replaced by XFrames (nothing public yet).

      An XFrames Working Draft has been released. See http://www.w3.org/TR/xframes/ [w3.org]. XML Events look really fun, too.
    • no XLink in this draft, despite it being a recommendation.


      People wanting to know why might find "What is the scope of using XLink?" [w3.org] interesting.
    • 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?
      • Seems like if they're going to make it backwards incompatible,
        Not entirely, clients shouldn't need particularly huge modifications to support it. Certainly with Mozilla it's mostly some CSS work.
        For example, are nested tables really the best way to lay out a page?
        This is what CSS is for.

        Go poke around the CSS3 [w3.org] working drafts, and maybe join www-style [w3.org] if you want to discuss it with clueful people.
        How about the script and noscript tags?
        What about them? <noscript> may be removed in favour or JS/DOM/CSS, but it's unlikely. <script> may be replaced by <link>, but again probably unlikely given that it makes it harder and less reliable to use client side scripting (a good thing? Maybe, but I'd be wary of pushing yet more ways of things going wrong).
        Any chance we can stop having to put comments around the script code?
        Um, from XHTML 1.0 it's been explicitly stated that you should not do this, since UA's are allowed/expected to strip the comments.

        CDATA is the proper way to do this if you must; comment hacks are available if you want to hide from broken clients, but typically you should be using <link> for your stylesheets and <script> for your scripts if they're complex enough to require such hacks. Think of it as a handy code smell ;)
        How about separating the 2 distinct uses of anchor tags?
        What distinct uses? As links and named anchors in a page? We already have that; just apply an id attribute to any element on the page and it should work as if it was an <a name="foo">.

    • "Fweeky" writes:

      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.

      I do not get a secure fuzzy feeling about this element, when I read the relevant w3 spec, and see:

      Most user agents have built-in mechanisms for processing common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To process data types they don't support natively, user agents generally run external applications.
      The object element allows authors to control whether data should be processed externally or by some program, specified by the author, that processes the data within the user agent.

      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

      • Um, <object> is nothing new; it was in HTML 4 [w3.org] 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.

  • my biased take on this (Score:2, Interesting)

    by f00zbll ( 526151 )
    It's good to see XHTML move forward spec wise. In previous jobs where scraping other sites was a significant part of the job, HTML made life hell. Lately I've been thinking that moving to a combination of XML + realtime translation + XHTML conformant output. When I first started designing and writing web pages, a lot of the work was mundane text edits. I can see the value of using XML as the content storage format and having a lightweight web-based application for editing the content. This gets rid of several challenges from my biased perspective:
    1. don't need a complicated RDBMS driven content management system
    2. people can read XML fairly easy
    3. there are free xml editors available
    4. header/footer includes can be described in the XML as Metadata and maybe reduce maintenance. now a programmer doesn't have to get involved in changing an image map and image if that is in the xml
    5. easier for search engines
    6. easier for scraping applications
    7. more conformant to standards

    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.

  • Security (Score:2, Interesting)

    by Sir Runcible Spoon ( 143210 )
    I would like to see any new standard for markup languages include security features. On a quick scan through I see no mention of it.

    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 [kuro5hin.org] 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>

  • I've noticed a lot of comments stating "this is useless, because the browsers won't render it."

    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 [w3.org]. 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.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close