Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
The Internet

Return of the WaSP 173

Posted by michael from the nesting-under-your-eaves dept.
No_Weak_Heart writes "After a brief hiatus, the Web Standards Project (WaSP) has returned. Here's the story at Wired about this grassroots coalition which works to promote the adoption of web standards by authors, tool makers and in browsers. In a related vein, the Boston Globe has a comfy chat with Tim Berners-Lee, the guiding force behind many of those standards."
This discussion has been archived. No new comments can be posted.

Return of the WaSP More

Return of the WaSP

Comments Filter:
  • It's just sad, that something like this is needed in the first place

  • I laud what they're doing and approve of the content of the text.

    On the other hand, they belie what they say with their front page. Oh, yeah, it may abide by all the standards. But, they don't abide by the spirit of the standards on their front page. The spirit of the standards is to keep the web accessible to everybody regardless of their choice of browser, so long as those browsers are also standards compliant.

    It seems to me that a basic precept of web design should be that people choose their default font sizes because that's the size in which they bloody well want to read most of the "main" text on the web!! Resizing of fonts should be relative to that. Most of the text should be in the default size, and larger and smaller sizes should be reserved for headlines, "fine print", and other things.

    These "web standards" people, however, seem to be using a font size a step down from standard for the main text on their page. Why? What possible excuse is there for doing that, while smiling and saying that they want to support browsers and web coding that is maximally accessible? It would be so bloody easy for them just to make their main text the standard font size that everybody chooses, instead of shrinking it down and requiring us to expand our fonts before reading the page!

    That one fact makes it difficult for me to take this project completely seriously.

    -Rob

    • Re:I am not impressed (Score:2, Interesting)

      by skunkeh ( 410004 )
      Your point is fine in theory, but you have to remember two things. Firstly, the vast majority of internet users don't even know that they can change their default font size (let alone how to do it). Secondly, the default font size on most browsers looks plain ugly. I would imagine that any users who want larger fonts have set their font size so that sites which use "font-size: small" are readable for them, as that will be a very common size for text on the web.

      I imagine the Web Standards site design team had to make a tricky compromise, between the theoretically correct step of sticking to the default browser font size and the more design friendly choice of using "font-size: small". At the end of the day the point of the project is to convince designers that they should be using web standards, and as such it is important that the site looks good. Had they used the default font size I imagine many designers would have been put off the site by the ugly size of the text.

      • Re:I am not impressed (Score:3, Insightful)

        by rknop ( 240417 )

        Your point is fine in theory, but you have to remember two things. Firstly, the vast majority of internet users don't even know that they can change their default font size (let alone how to do it). Secondly, the default font size on most browsers looks plain ugly.

        Uh-huh. I'm not the slightest convinced. These are people who say "follow standards and everybody will be happy". Making tradeoffs to cater to the default font size on IE undercuts their message.

        -Rob

        • That's the sacrifice we as web designers have to make. IE holds the lion's share of the browser market, and we can't expect MS to change the way it behaves in regards to web standards just to please you communist Moz users - it's an integrated part of their OS!!! Now if you'll excuse me, it's time for me to re-insert my head into my own anus.

          p.s. - I do web design, and when I need to see how everything looks, I fire up Galeon. If we could get more web developers on Moz we'd have a much better looking/behaving web.

          • Re:I am not impressed (Score:3, Insightful)

            by rknop ( 240417 )

            That's the sacrifice we as web designers have to make. IE holds the lion's share of the browser market, and we can't expect MS to change the way it behaves in regards to web standards just to please you communist Moz users - it's an integrated part of their OS!!!

            That's fine. I have my differences with this argument, but fine, whatever.

            It is also, irrelevant. The original message is about an outfit promoting web standars. They are not promoting "code to IE". They are promoting standards. Given that, they should be coding to standards, not changing the way it behaves in regard to standards just to please you IE users.

            We're not talking corporations or banks supporting customers here. We're talking a web standards advocacy group.

            -Rob

          • And by Lion's share, we're talking 80%+. However, that doesn't mean web developers can say "it looks good in IE and OK in mozilla," so it's 'mostly-good' and thus sufficient. Pages need to be designed for the greatest possible accessibility and that includes all of the major browsers, earlier versions, and screen reader software (getting back to the 508 comment).

            All too often i've been seeing trade-ins on design/coding_ease for standards compliance (particularly with fixed font sizes in css), better standards (WaSP) with more universal browser adherence to such standards.

            Last comment (then i'll shaddap), the different browser interpretations of a particular piece of HTML has always been a problem and, though better, it is still an issue. Though this probably exists already, a good website identifying the differences on a case by case would be useful to the developer community. In addition, such a site could recommend lowest-common-denominator solutions and WaSP standards at the same time.
            • the different browser interpretations of a particular piece of HTML has always been a problem and, though better, it is still an issue.

              That's not a problem, that's the benefit a truely accessible world wide web offers. Its only seen as a "problem" by designers that insist that it is they that control the presentation to users.

              When markup is authored to leverage the content rather than its layout, then the difference between interpretations is to the benefit of the end-users.
              • Not necessarily - while I agree that there are too many cases of webpage developers stressing design over content, there are other cases where the design augments the content. Take, for example, a simple table. In html, the table has long since ceased to be merely a mechanism to contain spreadsheet data and instead morphed into design control code. However, it extends beyond the "here's a page with a masthead, nav, footer, and we've built it all into a table" but rather "this content needs to appear alongside that other content with thin vertical lines of different, meaningful, colors." Netscape (/Mozilla) and IE handle tables very differently, this was more evident in early versions where Netscape would chew on big tables for several minutes while IE rendered them in several seconds (but it was integrated with the OS! I know, I know...), a more recent fluke is that NS can have trouble with 1 pixel high table cells. As a result, it can be difficult to effect more complicated design-content combos without using images (which have their own accessibility problems) because of the differences between browsers. IMHO, the key isn't to get hung up on the details of how one browser will behave versus another but simply to pick a solution that gets my content to the user in the most meaningful way. Good web design requires adjusting content to a layout that will adapt easily to browser limitations (especially when using the lowest-common-denominator approach), which is why it is important for browsers to move toward standards that require consistent display behavior.
        • Most standards-advocates (myself included) would love to use 'font-size: small', or percentages, or ems to size text relative to users font preferences.

          The problem is, support for these relative values are still too broken in IE6 and Opera (Opera is better though) for us to use them. Much as we'd like to, we can't be truly accessibility and standards-driven when the most popular browser on the web gets is wrong.

          Theres only really 2 options open just now - use px as the font unit, or don't size at all. Most developers/designers aren't quite Zen enough to not size the text at all, as the default text size in most browsers is fucking ugly.
          • A List Apart have published a workaround [alistapart.com] for setting a font-size one-smaller than the default size that works in all browsers, using the 'box model fix' technique. Just a pity they don't use it in their own pages. But yes, it does work.
      • I imagine the Web Standards site design team had to make a tricky compromise, between the theoretically correct step of sticking to the default browser font size and the more design friendly choice of using "font-size: small".


        Am I really the only one to find 1em verdana to be just the right size?

        I hate sites that force 11/12px fonts on me - my usual response is to turn off style entirely for these sites if my font-size: 1em !important user.css rule is overridden.

        Some design bod on MSDN said people need small text to read comfortably, and that 1/6th of an inch was about optimal; it was ironic that in forcing 12px fonts, the text was actually more like 1/14th of an inch tall, and very tiring to read.
      • > Your point is fine in theory, but you have to
        > remember two things. Firstly, the vast majority
        > of internet users don't even know that they can
        > change their default font size (let alone how to
        > do it).

        I don't see how this leads to the conclusion that they want the site font to be smaller. Or larger for that matter.

        > Had they used the default font size I imagine
        > many designers would have been put off the site
        > by the ugly size of the text.

        This implies that many designers (cough) don't know how to change the default font size of their own damn browser. If that's the case - if professionals authoring for the Web don't know how to use the most basic tools of their trade - then I'm afraid the Web Standards folks have a real uphill fight on their hands.

        Frankly, I think the whole font-size issue is a red herring. The only people who care are "designers" and perhaps their clients. One or the other looks at the page, thinks "Gee, that font is too big" and starts slapping in font tags left and right without considering adjusting their own browser so pages look they way they prefer. To satisfy themselves, they muck with a parameter affecting nearly every visitor to their site. Brilliant.

        Factoid: I run privately a small but reasonably well-visited mostly-text site: 50K page views a week. I make a factual error, visitors _love_ to let me know. A link breaks or some stupid browser bug renders part of a page illegible, and maybe someone will contact me about it, but probably not.

        Not once have I received a comment about the font size used on the site: the browser's default.

        The entire issue is an overblown non-issue.

    • Re:I am not impressed (Score:2, Informative)

      by stankyho ( 172180 )
      Here's a good explaination [thenoodleincident.com] of the font issue and why IE is the worst for individual font sizing.

    • Re:I am not impressed (Score:1, Informative)

      by Anonymous Coward

      These "web standards" people, however, seem to be using a font size a step down from standard for the main text on their page. Why?

      Probably because (according to their stylesheet) they intend the main text to be displayed using the ubiquitous Georgia font and Georgia has a high aspect value, making it look "too big" when the default font-size is used.

      See the W3C CSS spec [w3.org] (scroll down a bit):

      For example, the popular font Verdana has an aspect value of 0.58; when Verdana's font size 100 units, its x-height is 58 units. For comparison, Times New Roman has an aspect value of 0.46. Verdana will therefore tend to remain legible at smaller sizes than Times New Roman. Conversely, Verdana will often look 'too big' if substituted for Times New Roman at a chosen size.

      Arien

    • ...Oh, yeah, it may abide by all the standards. But, they don't abide by the spirit of the standards on their front page. The spirit of the standards is to keep the web accessible to everybody regardless of their choice of browser, so long as those browsers are also standards compliant.

      I've got that page open in the second tab of Moz as I write this. It is liquid from any browser width down to 410 px. Below that, it degrades acceptably (remains readable) until the columns are just a single word wide, well below the limit of reason. All text responds to user-agent changes in the font size, and the layout reflows without problems. I've looked at their stylesheet and it looks good (wsp/css [webstandards.org]).

      There is no may about it; this page does "abide by all the standards."

      Does it also abide by the spirit of the standards?

      Yes. The standards are not intended to lock you into any design style. There is no "best" design style. The standards were developed to assure that material written to the standard will be presented to the reader no matter what his user-agent (so long as the user-agent also recognizes the standards).

      The standards have nothing to do about good design. All they address is across the board functional design. IMO, I think that on this page WaSP has sacrificed some quality of design to showcase what can be done within the standards. That is a reasonable design trade-off, and it has nothing to do with standards compliance.

      In this instance, you need to realize that WaSP's core audience, the group they are hoping to influence, is not the average guy using his browser in the usual way. Their audience consists of web designers and others who are pretty sophisticated in their use of the browser, and are likely to have their browser window set at around 700px width, in a corner of their 1600x1200 screen.

  • Well yes .. but ... (Score:5, Interesting)

    by Mr_Silver ( 213637 ) on Tuesday June 11, 2002 @08:30AM (#3678429)
    The most popular browser in the world [microsoft.com] is pretty good at following the rules, the permutations of the Gecko engine (here are some: N M C) are all praiseworthy, and on top of that virtuous standards oatmeal is some pretty tasty rendering brown sugar; anti-aliased fonts are here to stay!

    Well, yes, I don't think many people but the most hardcore of standards purists could claim that IE isn't pretty good at following the rules. Thats not the issue.

    The issue is that it's not very good when the code doesn't follow the rules. The problem here is that IE "guesses" what you're trying to do.

    This in itself isn't a bad thing and from an end user perspective is a damn good idea. If I go visit a site that someone has made a basic error then at least I can still view the content, their mistake doesn't prevent me from getting what i want.

    The problem comes when people start getting used to writing sloppy HTML because it works on IE (yes, I made that mistake before I found the w3 validator and Opera) and when Microsoft products start producing sloppy HTML (Words and Powerpoint being two apparant examples, although I've not looked personally).

    So yes, web-standards great idea. But there should be a standard on what to do with badly formed HTML too.

    • "Amaya cannot be used to check validity of HTML pages. It accepts valid and invalid HTML documents and tries to dynamically correct errors. For example it's able to add missing end-tags and to move misplaced elements.
      "

      So let's all stop whining and poking at IE for trying to correct errors, hmmmmmm?
      • On the contrary, this knowledge will merely make me whine and poke at Amaya too.

        I work in a web agency, and have had real problems in the past with certain designers writing/editing pages that look fine in IE, but don't actually work in either browser (or, on occasion, display at all in Netscape). They then proclaim the page to be finished, never having checked it in Netscape (despite a contractual obligation to support it), leaving it for the rest of us to fix.

        I would like to see a "debug mode" in all browsers, whereby any badly-formed HTML is clearly flagged as such. Then you could tell at a glance if there was a problem, and what it was.

        Cheers,

        Tim
        • You are right in your thoughts...

          > I would like to see a "debug mode" in all browsers, whereby

          You can use the w3.org validator for that.

          What i thought of now is whether the validator's results page is HTML valid...hm...practice what you preach, hehehehe

    • Well, yes, I don't think many people but the most hardcore of standards purists could claim that IE isn't pretty good at following the rules.


      Call me a standards purist if you like but IE has improved form poor to merely passable in its standards support. They fixed several annoying bugs in IE5 but they still have a hell of a long way to go. It took them until version 6 to get difficult concepts like 'width' and 'height' correct.

    • But there should be a standard on what to do with badly formed HTML too.

      I'd like the browser to halt with a 'Error: Page invalid' myself. If IE (and all browsers) would do this for nonvalidating HTML and CSS I'd say we'd see things improving pretty fast.

      This is on my Opera wishlist, actually. Can we please have finer granularity on disabling popups and plugins too, and add right-click image/plugin-output to blacklist source server? Thanks.

      • I'd like the browser to halt with a 'Error: Page invalid' myself. If IE (and all browsers) would do this for nonvalidating HTML and CSS I'd say we'd see things improving pretty fast.

        Unfortunately the end user might see this as broken and therefore decide not to update. Personally, I'd avoid updating if it meant that i was going to be denied access to some content because of someone elses cockup.

        Maybe what would be better is a javascript error style pop up window informing the user that the page contains invalid HTML, telling them it can guess what the content is, but it might be illegiable and would they like to do this?

        At least then, the annoyance of a pop up on your site would force you to do something about it but at the same time not prevent people from not viewing what you've put.

        Of course there should be an option to disable this but it definately shouldn't be the default and there shouldn't be a "don't show this again" option on the menu.

        If people want it off, they have to hunt for it.

      • Why not get google to 'correct' all the html in its Google cache?

        Why would they?
        It might annoy microsoft

        Why would they not?
        It might annoy microsoft

        No seriously:
        They may have 'better' [google.com] things to do with their development and marketing time. Also it would not work for dynamic pages. Foiled again.
      • I'd like the browser to halt with a 'Error: Page invalid' myself. If IE (and all browsers) would do this for nonvalidating HTML and CSS I'd say we'd see things improving pretty fast.

        It doesn't halt on invalid HTML, but iCab has an indicator [www.icab.de] on the address bar that tells you if a page uses valid or invalid HTML and/or CSS. Something similar in Mozilla would be nice.

        (BTW, iCab doesn't think much of /.'s HTML, but that comes as no surprise.)

    • > But there should be a standard on what to do with badly formed HTML too.

      I could not agree less. This would simply reinforce, encourage, and -- even institutionalise -- bad markup.

    • Just about all browsers have some "error correction", and will try to guess what the author really meant. However, IE takes this to the extreme, and actually seems to pretend to know better than the author at times (which is entirely possible, as there are many clueless "web designers" out there, but that's besides the point).

      For example, IE tries to guess what to do with a remote resource based on the contents of the file, rather than following the Content-Type header. Not only is this insane, as the server should be telling the browser what kind of file it is serving, not vice versa, but it has caused serious problems when trying to actually make IE treat a file with a particular content type differently. Want IE to download the file rather than display it? Well, unless you want to create stupid workarounds which break other browsers, you may have a hard time with this.

      What WaSP should be pushing, and what I feel is one of the important parts of a web standard, is that a browser's behavior is as predictable as possible. When the browser tries to guess everything itself, rather than doing what the code actually says, it causes situations such as the one above. Sure, let the browser correct simple errors, but today's browsers are too "sloppy" when it comes to sloppy code. They should be more strict and unforgiving. This would make things a lot easier for web designers, as the browser would show clearly when there are errors in the code.

      I generally find that it is a lot easier to "design for" (bad way to do it, but still) browsers that allow less sloppy code. Opera is excellent to check your code with, as it is even more unforgiving than Mozilla. Although this can lead to more "broken sites" when browsing the web, I find it to be of tremendous help to keep my own pages written properly. Mozilla has strong standards support, and seems to sometimes handle pages better than both Opera and IE (since IE's implementation of various standards has serious flaws), but it allows too much garbage code.

      Then again, we have to live in the real world, and with clueless Frontpage users out there, we should back WaSP and try to make both browsers and authoring tools behave better - for a more open and accessible web. Sadly, because of IE's sloppiness, we are currently trapped in web designer hell. And viewer hell if the browser isn't "MSIE compliant".

    • there should be a standard on what to do with badly formed HTML too.

      There is such a standard for XML [w3.org]:

      Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.

      I suspect it's there because of the reasons you mentioned.

    • Well, yes, I don't think many people but the most hardcore of standards purists could claim that IE isn't pretty good at following the rules. Thats not the issue.

      Call me a standards purist, but last time I tried to make web pages work in IE6, I had a hell of a time. I ask it to draw a dotted border, it draws a dashed border. I scroll down and up again, lo, the border has become partially solid (a rendering bug).

      So I say, okay, screw that, back to solid borders. Then I find it doesn't do transparent PNGs. One evil DirectX-using hack later, that's working too.

      Next up is the fact that it doesn't seem to like XHTML, or I was doing something wrong. It worked just fine in Mozilla though, so I'd guess I'd got it at least mostly right, as Gecko is fairly strict. So I drop the XHTML aspect of it.

      Finally I find the text is too big, IE doesn't understand the "small" text sizing keyword, so I have to specify it in point sizes, which is now too small on Linux.

      No, though 6 is much better than 5, IE is still a long long way off being anything other than a half-arsed attempt to follow the rules.

      Sorry, rant over :) Other than that, yep, agree 100% with your post.

      • Never had a problem with dashed vs. dotted. Sure you have the proper DOCTYPE in there?

        It should look exactly like this:
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

        If it isn't right. IE will go into quirks mode.

        But yes. IE still has some really annoying bugs. IMO it's still behind in standards when compared to any Mozilla based browser.

  • Tim Berners-Lee's favourite web sites (Score:1, Funny)

    by Anonymous Coward

    Courtesy of SatireWire [satirewire.com]

  • Is not actually a bad idea at all. w3c [w3c.org] in it's all brightness does not provide a comprehensive statement on "what to do" and "why" for those new to these things. An organisation responsible for standardizing such a large matter always hides everything behind a jungle of technical details.

    An organisation that sums this up, cannot harm anyone - atleast as it does not start pushing only the will of a selected vendor.
  • They were the people who said that Mozilla should give up and die, right ?

    • are you on crack?

      i've been following the WaSP closely for years and i don't recall them ever having any problems with mozilla.

      please post a link if you think i'm wrong.

    • They were the people who said that Mozilla should give up and die, right?

      Care to back that up with something? If not. I think you must have missinterperated something they said. 'Cause I've followed WaSP closly, and I find it hard to belive they'd say something like that.

  • WASP is gonna have a helluva time when Microsoft decides, yet again, that standards are for wusses. MS has balls.
    • The have shamed MS in the past for browser compatiblity. When MS decided to make MSNBC work only in their browsers while hiding behind the refrain of standards compatibilty WaSP members called "bullshit" and MS backed down.

  • Ridiculing (Score:4, Funny)

    by LordoftheFrings ( 570171 ) <[ac.tsefgarf] [ta] [llun]> on Tuesday June 11, 2002 @08:44AM (#3678472) Homepage
    From article:
    ...if that fails, we plan to guilt-trip them. And if that fails, we will ridicule them mercilessly, as we once ridiculed Netscape and Microsoft.
    Wow, they seem to really have a great strategy worked out.
  • Basically, since microsoft controls a HUGE majority of the market, whatever they do becomes a de-facto standard. For once, I would like to thnak them for their good work. They have voluntarily followed standards, and written a reasonably good browser. (not that the code isn't, memory hogging trash)
  • Maybe Slashdot could get the hint! [w3.org]

  • While you're at it .... (Score:4, Insightful)

    by reaper20 ( 23396 ) on Tuesday June 11, 2002 @08:58AM (#3678509) Homepage
    Government workers and contractors, you have to (or already have) comply with Section 508 Accessability Guidelines (as stated in the article), which means that most of these pages need to be rewritten anyway, now's a good chance to knock out XHTML1.0 compliance while you're at it, and shoot for the Web Content Accessability Guidelines (WCAG) too ... so all those neat Powerpoint presentations that are autogenerated into HTML need to go!

    Getting to level A is not hard at all, anyone hit AAA yet?, I'm finding XHTML1.1 and WCAG-AAA a little bit to unwieldy for everyday web use ...
  • So, does slashdot.org comply with the standards stated in the article? If not, why?

    • Re:Slashdot (Score:5, Interesting)

      by Lysander Luddite ( 64349 ) on Tuesday June 11, 2002 @10:19AM (#3678995)
      well...

      Slashdot relies on tables for layout which is a big sin for WaSP. Not only do table-based layouts violate the structural markup that is the basis of HTML (and XML derivatives) it causes problems in browsers designed for the sight impaired (and therefore violates Section 508).

      Slashdot also uses deprecated tags such as (font) and (b) rather than use CSS to change text presentation. I also don't see any structural flow such as using (H)eader tags to enable things like search bots to more accurately determine page content and weighted analysis.

      So no, I would suspect Slashdot wouldn't stand up to WaSP scrutiny.

      • I'm sorry but you had several mistakes in your post.

        First, tables, provided they are coded correctly, are HTML, and XHTML compliant. They would have to be, as tabular data (what tables were made for) still has to be displayed on some sites.

        WASP is saying that to make a layout like their site does not require tables, and it doesn't. You can use some fancy positioned div's, and spans and you'll have a very nice site.

        Also, the (b) tag is not depricated. However, (strong) should be used in place of it in most places.

        No, the HTML behind /. would fail WASP tests and the regular W3C validator tests.

        -Vic
        • You are right about the tables. It si compliant, however using them for layout is not how they were intended to be used. That is the point I tried to make. It also explains why text-to-speech browsers have difficulties with them. I apologize if I wasn't clear.

          As for (b) correct again, but WaSP would suggest you use a SPAN or DIV rather than a (b), which is a presentation tag rather than a structural one.

          However, I do applaud Slashdot for at least use a DOCTYPE header, which reads as 3.2. WaSP would most likely encourage them to move to HTML 4.01 or and XML/XHTML DOCTYPE. That would allow the separation of content and layout.
      • Slashdot relies on tables for layout which is a big sin for WaSP. Not only do table-based layouts violate the structural markup that is the basis of HTML (and XML derivatives) it causes problems in browsers designed for the sight impaired (and therefore violates Section 508).

        It's true that layout tables are to be avoided (it's actually a form of lying: you're indicating tabular relations between the cells and rows of the table, while in reality there are no such relations - that's the main problem).

        But, Slashdot is in good company: the W3C themselves use tables for layout! That's really the pits... Just check out "www.w3.org".

        Slashdot also uses deprecated tags such as (font) and (b)

        Unfortunately "b" is not deprecated.

  • comments on Semantic Web (Score:3, Interesting)

    by MarkWatson ( 189759 ) on Tuesday June 11, 2002 @09:13AM (#3678589) Homepage
    I thought that the second half of the post (on Semantic Web) was interesting.

    As someone who has spent lots of time in the last 5 years trying to automate extraction of information from the web, I welcome wider use of RDF (I have used it for years on my site) and separation of content and layout.

    While the web as we know it is all about supporting human readers, the Semantic Web is all about supporting software agents.

    -Mark

  • ...but for what they don't.

    Anyone or anything that stands up to prevent the next BLINK tag from running rampant on the net deserves some respect...

  • Standards and Reccomendations (Score:3, Interesting)

    by JamesOfTheDesert ( 188356 ) on Tuesday June 11, 2002 @10:25AM (#3679040) Journal
    The W3C issues recommendations. They are not a standards organization, such as ISO, ECMA, or ANSI. Many companies, particularly those doing government business, are required to follow specs issued from standards bodies. HTML is OK, becasue of ISO/IEC 15445:1998(E). XHTML is not a standard; neither is XML, except as particular applications of SGML.

    I tried creating a web page that used the ISO HTML DOCTYPE declaration:

    <!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1998//DTD HyperText Markup Language//EN">

    The W3C validator page [w3.org] complained about it: Fatal Error: unrecognized {{DOCTYPE}}; unable to check document

    It seems standards are not so standard.

  • I mean, look at the poor "HTML" code generated here... Disgusting.

  • Big stretch to use the acronym 'WaSP' for this one. Perhaps 'WSaP' might be better, then Bud can sponsor the project...
  • but where does the "a" come from in WaSP.... or maybe that's part of the proposed standard...being able to add any required letter to your project acronym to make it sound cooler.

  • Re: Modern Browsers (Score:3, Insightful)

    by SloppyElvis ( 450156 ) on Tuesday June 11, 2002 @11:56AM (#3679715)
    According to WaSP, modern browsers are a necessity. The problem is, WaSP doesn't have the power the impose such a mandate, and my grandma uses whatever browser came bundled with her machine (how did IE win the browser war?)

    IMHO, standards are great, but only if they are, in fact, standards. Thus, everything I write for the web follows the LCD (lowest common denominator) philosophy. Heck, I don't need tricks to put something that looks good on the screen (I'll do the alpha blending during graphics production, not at runtime). I don't like rewriting everything for a new browser (neither do the WaSP gurus), and that is why I'll stick to plain ole' minimal tag set HTML.

    HTML is not the problem for me; the problem in getting a site to work properly on any browser comes in when you try to use JavaScript. An standard object model for *JavaScript* is what I really need, and that is just not a reality yet.

    Some have pointed out IE's tolerance for mistakes is a problem, and I couldn't agree more. As a development browser, IE is a big mistake, unless you don't care about users of other browsers at all. Thank goodness for Mozilla.
  • I guess I'm just stupid, but a lot of what they're saying doesn't make any sense to me.

    Most major websites can also be improved by removing intricate table layouts and superfluous markup
    Uh, how the heck would you set up your layout without tables? For instance, how would you generate a page that looks like Slashdot without using nested tables?

    I also don't understand how they can claim that web designers should design a single page that can be used both on desktops and handhelds. OK, maybe if it's just plain text that would work. But any more complicated layout is going to have to be redesigned completely for a handheld.

    • Uh, how the heck would you set up your layout without tables? For instance, how would you generate a page that looks like Slashdot without using nested tables?
      Uh, it's called CSS. You'd be amazed at the stuff you can do with DIV tags and a decently advanced stylesheet. check out this [darktech.org] for an example. Use mozilla or netscape 6 to view it, because IE doesn't fully support CSS1 (even though MS says it does)

    • Re:duh? (Score:2, Insightful)

      by Isofarro ( 193427 )
      how the heck would you set up your layout without tables?

      Cascading Style Sheets. HTML was meant to represent the structure of the content, not its presentation. Style Sheets are the suggestions of layout and style.

      I also don't understand how they can claim that web designers should design a single page that can be used both on desktops and handhelds. OK, maybe if it's just plain text that would work. But any more complicated layout is going to have to be redesigned completely for a handheld.

      That's because you are stuck in the mindset that layout is done in the HTML. By moving layout suggestions to the stylesheet, there's a clear seperation between the content and the layout/presentation. That means the same content can be displayed on both devices, the browser making full use of the style-sheet, while the PDA uses a minimal or no stylesheet at all. The HTML just encapsulates the structure of the content (in that _this_ is a heading, _that_ is a paragraph), while the style sheet describes how to display it (headings should be bold, red and s_so_ big).

      By a clear separation, accessibility to an HTML page is increased.

    • Use CSS to create 3-columned tableless layouts (Score:5, Informative)

      by starvingartist12 ( 464372 ) on Tuesday June 11, 2002 @01:06PM (#3680235) Homepage
      It's totally possible to create great looking tableless, liquid, three-column layout using CSS.

      These sites have different tutorials for various column combinations and even backwards compatibility with Netscape 4.

      http://www.glish.com/css [glish.com]
      http://www.saila.com/usage/layouts [saila.com]
      http://homepage.mac.com/realworldstyle [mac.com]
      http://www.projectseven.com/whims/cssp_3box/3boxno script.htm [projectseven.com]

      The beauty of not using tables is that you're seperating structure from presentation. Basically, around some content, you specify what it is (structure). In the case of Slashdot's side navigation, in the XHTML/HTML you'd might surround the content with a DIV tag and give it an id/class of "sidenavigation".

      With tables, you're already forced to predetermine that you want to use it on the left column when you mark up the whole table in TD and TR tags.

      So how's CSS better than tables? Well, once you've defined the structure in XHTML/HTML, you can use CSS to define the presentation to say, I want anything tagged as a "sidenavigation" to be a vertical box on the left side that's X pixels wide.

      This presentation can be easily be altered by changing the CSS. You can tell CSS to move things to the right, maybe center it or whatever. And you can define a CSS specifically for handhelds. You can tell it to hide data, change font sizes, redefine colors, or anything you want. For the sight-impared, you could define the CSS to display it all in a simple, column-less layout. And since you have not predetermined the presentation in the HTML, the user could have defined their own stylesheets to override your CSS to present the content in the way they want it.

      With HTML and CSS (and also the XML and XSLT recommendations), websites can be so much more flexible.

    • Good CSS tutorial (Score:2, Informative)

      by mlas ( 165698 )
      Here's an excellent tutorial [glish.com] on how to get some common layouts without using tables for layouts. It's a little tricky at first but entirely possible. I've built my last three sites using no tables.

    • how would you generate a page that looks like Slashdot without using nested tables?

      Put the left side bar into a div and float:left it. Then put a wide left margin on the left side of the main content div, wide enough to skip the left side bar.

      Then use nested divs to indent the various comments with a wide left margin.

    • Re:duh? (Score:2)

      by apg ( 66778 )
      Uh, how the heck would you set up your layout without tables? For instance, how would you generate a page that looks like Slashdot without using nested tables?

      It really wouldn't be all that hard to redesign this layout without using tables for the major page structure. At it's simplest you've basically got a single, fixed-width column running down the left side and a content area that takes up the remaining page width, with a header and footer and little bit of margin around the edges. Even the nested threading of the comments and replies wouldn't be all that hard to replicate.

      I also don't understand how they can claim that web designers should design a single page that can be used both on desktops and handhelds. OK, maybe if it's just plain text that would work. But any more complicated layout is going to have to be redesigned completely for a handheld.

      The idea is that if you mark up the content of your page structurally and use CSS to create the layout, a device can display the content as best as it's able. Not that a handheld will reproduce the exact same layout as the desktop, but that it is able to present the information in a way that is appropriate for a handheld.

    • Uh, how the heck would you set up your layout without tables? For instance, how would you generate a page that looks like Slashdot without using nested tables?

      Like this [soupisgoodfood.net].

      It's not a perfect example, it won't fit in a small screen. But that's totaly fixable. It's just something that I've thrown together and played with. Adding indents for a comments layout (which I plan to do) is easy.

      If you look at the source code. You will notice that it's very lean. Even the CSS file is lean. Much smaller than the /. HTML anyway. Also, if some of the code in there looks different (like the first artical), like I said before, this is only something I've been experimenting with, and there will be lots of bugs. Just want to make sure no one goes away thinking that CSS is crap or anything.
      You'll also notice that I haven't got CLASS="foo" in all the tags, only some because of the way CSS can be used.

      The other great thing is, if you wanted to put the side bar on the other side. It would take you less than 2 mins to do it. And you wouldn't even have to dick around with messy HTML, or in this case, even messier HTML within Pearl scripts.

      Also, save only the HTML page to you disk. And open that file. Now you can see what it looks like without the CSS. Perfect for any browser including a PDA. And you can always have another CSS sheet for them if you want to change it.

      BTW. You will need something like IE 6, Mozilla, or Opera 6 to view it properly. It will just look like plain vanilla HTML to NN 4.7 etc.

  • This group seems to be a lobby for style sheets. They don't like nested tables. They want style sheets and "abstraction".

    Why should there be "abstraction" at the presentation level? It might help the content creator, but it doesn't do much for the reading end.

    Speaking as someone who decodes elaborate HTML material with programs (I wrote an engine which, among other things, reads financial statements expressed in HTML), adding a layer of abstraction doesn't help when extracting the meaning of the content. It might if you were guaranteed that all content of a given type used the same style sheet. But you're not, so it hurts, rather than helping. Decoding programs have to expand out all the style sheet stuff, like macros, then work on the expanded form.

    At least we know what tables mean in a 2D sense. I can machine-parse HTML with tables and determine that one item is above another item. Rows and columns can be extracted. You can tell what's adjacent to what when seen by the end user. Abstraction breaks all that geometric structure, and the geometric structure is what the user sees.

    • CSS is for separating structure from presentation (Score:4, Informative)

      by starvingartist12 ( 464372 ) on Tuesday June 11, 2002 @02:17PM (#3680715) Homepage

      Abstraction breaks all that geometric structure, and the geometric structure is what the user sees.

      With proper HTML and CSS use, the abstraction at the presentation level doesn't actually break the structure. It merely seperates presentation from structure, while keeping structure together with the content/data.

      Scott Andrew [scottandrew.com] said it best here [scottandrew.com]:

      "...this illustrates a common misunderstanding about CSS. CSS is for separating structure, not content, from the presentation. Markup is meant to give meaningful structure to content. The content can come from a database or text files; the structure from page templates, a CMS or XSL transformation. Keeping your content free of meaningless structural elements allows you to pour your content into another structure suitable for different devices. CSS allows you to apply client-appropriate and easily-varied visual style to that structured output, without having to alter your markup."
      • With proper HTML and CSS use, the abstraction at the presentation level doesn't actually break the structure.

        But you don't get proper HTML and CSS use. You get whatever somebody used to get the thing to look the way they wanted it. Correct semantic structure is not near the top of most web designers' priority lists.

    • Why should there be "abstraction" at the presentation level? It might help the content creator, but it doesn't do much for the reading end.

      Tables are meant for tabular data - no-one is saying not to use tables for tabular data. What they are saying is not to use tables for _layout_.

      Given a table - how do you tell whether its for layout or tabular data? I doubt you could always get it right.

      adding a layer of abstraction doesn't help when extracting the meaning of the content

      The meaning of the content is in its document strucutre, not in whether its left or right aligned. Presentation just makes content look presentable, not add meaning to it.

      a h1 element will tell you more about some text than a font-size.

      Decoding programs have to expand out all the style sheet stuff

      No they don't. Presentation doesn't add anything to the content. How a heading is displayed gives no more significant information than knowing a piece of text is a heading.

      The only time your statement could ever be slightly accurate is if people insist on using tag-soup instead of logical HTML markup.

      Yes, you can make something _look_ like a heading by sticking it in a paragraph and alter the attributes of that paragraph to _look_ like a heading. There's no point in doing so, since the structure of the elements doesn't describe the structure of the content adequately -- that's tag soup.

      Abstraction breaks all that geometric structure

      Disagree. Abstracting the presentation (those bits that don't add value to the content structure but only describe style attributes) will clarify the geometry of a document right down to a clean hierachial list of nodes that are easily traversed.

      Parsing an XML file is much easier than a random tag soup. And it can be done with standard freely available tools.

      Speaking as someone who decodes elaborate HTML material with programs

      These programs will be common accessories to the normal web user (transparent to them of course), precisely because of the direction WaSP and others want to go.

      The Semantic Web is just an extension of the WWW.

  • The White Anglo-Saxon Protestant never left!
  • The thing that Zeldman's Disciples still have not figured out is that there are poor people who are or would be well-served by web access. Standards are great, but those of us who build web sites have to consider the fact that there are folks out there driving tired old corporate cast-off equipment, stuff that cannot handle a modern web browser.

    They tell us that browsers are free for the downloading -- because they are not paying telephone charges by the minute.

    They tell us that Browser X is a "light" download, but don't consider that it won't run on a tired old 80386 with four meg of RAM.

    They tell us that supporting old, tired machines and the poor people who use them is "holding back progress" -- only because it holds back THEIR progress. They simply refuse to consider the little girl in South Africa whose progress we're supporting by not adopting the latest standards. Her father is proud to be able to provide her with that unreliable dial-up that tops out at 18kbps.

    Not me, thanks. Until the older technology falls out of use, I'll continue to do the things that Zeldman's Disciples hate.

    It's only accessibility if real people using real equipment can make use of the content.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close