Page 1 of 2 12 LastLast
Results 1 to 25 of 28
  1. #1
    Join Date
    Nov 2001
    Location
    California
    Posts
    1,991

    W3 - http://validator.w3.org/

    Is there a w3 validated code that I can set the margins with? With leftmargin="0" topmargin="0" marginwidth="0" marginheight="0", it will not validate as w3 compliant. Anyone have any suggestions to acheive the same thing, but be w3 compliant?

  2. #2
    Join Date
    Oct 2002
    Posts
    353
    Set the margins through the style sheet on the body tag.

  3. #3
    Join Date
    Nov 2001
    Location
    California
    Posts
    1,991
    Explain?

  4. #4
    Join Date
    Jul 2002
    Location
    UK
    Posts
    524
    But this in the <head> of your page.

    <style type="text/css">
    body {
    margin-height: 0px;
    margin-width: 0px; (etc.)
    }
    </style>

    Actually, I've never had any problems with using that method, maybe the validator is being a little tempremental again.

  5. #5
    Originally posted by ubergeek22
    maybe the validator is being a little tempremental again.
    The validator is, of course, doing its job perfectly; leftmargin/topmargin/marginwidth/marginheight have never been part of any HTML specification (and hopefully never will be). CSS is the only standards-compliant way to do what iamdave wants to do.

  6. #6
    Spock's right ...
    Inserting the code directly into the <body> tag will work but if you're looking to be W3 compliant the only way is through CSS.

  7. #7
    Join Date
    May 2002
    Location
    UK
    Posts
    2,997
    Any particular reason you are trying for force validation... is it just to get the XHTML graphic?

    Whilst striving for standards is a laudable goal... every modern web browser currently supports those attributes. (note I say web browser as they often have the non standard extensions built in... things like PDA browsers, etc often don't)

  8. #8
    I've got to agree with Rich, it's virtually impossible and in some cases ridiculous to get a page to comply entirely to W3 standards.

  9. #9
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    Originally posted by Rich2k
    Any particular reason you are trying for force validation... is it just to get the XHTML graphic?
    Accessibility.

    I've said this before (I believe this is the 4th time I am posting this), but Ill go over it again.

    The future of the web is accessibility.

    Your content must be accessible to disabled readers. More importantly, your content must be accessible to other computers. Computers will be pumping your site into more intelligent search engines, which will need to glean meaning from your document structure, not just the raw text. Computers will be automatically downscaling your page for smaller screens . Computers will be picking out the content in a page and automatically hiding the index and table of contents.

    Computers can understand XML. Computers can't understand complex HTML that uses what are supposed to be structural elements (like TABLE) to layout your content.

    Furthermore, as we have more and more versions of browsers out there in the wild, it becomes harder and harder to support them and test in all of them. The only viable solution is "graceful degredation". Code for the standards. Hope the browsers implement the standards.


    As well as:

    The whole point of XHTML is to make the semantic structure of a web page more obvious. You're not laying out a magazine page here; you're structuring information, and adding some optional tips (I can override any formatting in your page at the touch of a button) on how it might be formatted. The information and its semantic structure is the important thing, not the presentation. If the presentation is the important thing, send me a paper magazine.

    Also:

    W3C is looking to the future. It sees the very real possibility of the Web becoming more than a bunch of largely static pages that you surf with browsers whilst sitting in front of a PC. On one front, the separation of content and presentation is allowing users to stream news straight to their desktop, to build new interfaces without changing any underlying data (have you seen the Google-like Amazon.com interface?). On another front, the Web is moving to cellphones, set-top boxes, refrigerators, you name it. And if there isn't some standard language in which all these devices can communicate, some easy way for MyDesktop to get what it needs from UberNews.alt without hiccups, then this future is not going to happen.

    My favorite quote:

    The zen of web design is understanding that HTML means that all clients will (should) be able to view your page, not that they will all be able to view your page as you view it or as you intended for them to view it.

    And lets take some advice intended for pros who do this for a living how it can save companies money:

    http://hotwired.lycos.com/webmonkey/02/33/index1a.html

    And going back to the browsers issue:

    http://www.alistapart.com/stories/tohell/

    As well as:

    http://www.gerbilbox.com/newzilla/general/general03.php

    Which lets you know Mozilla is a browser design to adhere to the webstandards.

    And about lynx, it works fine with a CSS heavy site. I use lynx all the time. But people who have poor code that doesnt even validtate as html 4.01 focres me to use a gui browser. Its the wanna be webmasters who dont know what a div tag is that kill accessibility.
    Originally posted by Bulldog
    I've got to agree with Rich, it's virtually impossible and in some cases ridiculous to get a page to comply entirely to W3 standards.
    Not if you know what you are doing.

    Though very often people who do not know how to code will complain that they can no longer write web pages. That is becuase html used to be very forgiving, but now is a lot more structured and requires that you to know a lot more.

    Others will say that it is impossible to design a website that is complaint:

    And you can make websites that look nice and validate. You just need to know what you are doing. These are perfect examples:

    http://www.alistapart.com/
    http://www.bluerobot.com/

    Right now many people use desktop PCs, but they are being replaced, and XHTML 1 is supposed to be a stepping stone to the new web, where cell phones, toasters, fridges, palm pilots, watches and TVs all surf the web. That is why XHTML 1.0 is 100% backwards complaint (CSS is another story for NS 4 users, they will just see unformatted test in a linear fashion).

    But in the end, the web should not look the same everywhere you view it. It needs to migrate fully to XML, which computers, search engines, pal pilots, etc can and do understand. They can not understand HTML. HTML is just that, a "mark up language", which is fine if everyone is using PCs, but is horrible when people use palm piloots, watches, etc. You need XML, which is something computers can break down and restructure accordinly adn that is the purpose of XHTML 1.0 to form a bridge between mark up language to the new web of seperating content versus layout.

    Does it make it harder at first? Yes. XHTML is very strict compared to HTML. Is it the future of the web? Yup. Im just gettting ready early. HTML 4.01 is still a valid spec, but even in that, they dont want you using tables for layout. XHTML is just the bridge to the future. The longer you wait, the more work you will have to do.
    Check out the latest wired article here:

    http://wired.com/news/culture/0,1284,55675,00.html

    Some other sites that I have posted in the past:

    http://www.sgtaylor.com/
    http://www.alistapart.com/
    http://www.alistapart.com/stories/betterliving/
    http://www.thenoodleincident.com/tut...son/boxes.html
    http://glish.com/css/
    http://www.bluerobot.com/
    http://www.bluerobot.com/web/layouts/
    http://www.meyerweb.com/eric/css/
    http://www.meyerweb.com/eric/css/edge/

    Hell, even the New York Public Library:
    http://www.nypl.org/styleguide/

    XML is also the format in which OpenOffice Docs are saved as well as the next version of MS Office. XML is the future. It is not as forgiving as HTML, but hopefully it will get rid of the psuedo programmers and finally clean up the net.

  10. #10
    I didn't say it's not possible, in fact it's quite easy.

    For instance I recently did some subcontracting work for the city of Los Angeles and you better believe everything was W3 compliant.

    However when I'm dinking around or working on my personal site I don't care either way, I have no reason to spend my time adding <alt> tags to every image.

  11. #11
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    I agree, being strict complaint (something I do for all comercial work) is not necsessary in many cases, personal sites especially, but without ALT tags there will be a bunch of blind people knocking at your door! :p

  12. #12
    Ah but if they can't see my personal site then they can't find my address now can they! haha

  13. #13
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    They can see it, but they wont have a clue what all the images you post are, especially if its a blog with smiles and stuff. Or if you use images as buttons (which link to other parts) they will not know where the links will go. And than they will whois you and hunt you down!

    I've noticed your new here, but I like your posts. Welcome to WHT

  14. #14
    Join Date
    Nov 2000
    Location
    Vancouver, BC
    Posts
    283
    (applauds acronym boy) just because browser support it definitely does not mean we should be using it... zeldman has a level goal, strive for accessbility but don't go overboard... good stuff!

  15. #15
    Join Date
    Oct 2002
    Location
    UK
    Posts
    563
    But am i right in thinking the CSS method doesnt work for older NS.. (eg 4.7)

    I know this is an older browser now, but i do know people that still use it over later versions.
    · Shared Hosting - Servers in the US and the UK
    · Reseller Plans - For ultimate reliability
    · WebAttention.net - Hosting made easy

  16. #16
    Join Date
    May 2002
    Location
    UK
    Posts
    2,997
    Acronym BOY I think we've had this argument before

    Sorry quite simply don't agree. HTML became a common and usable thing without the W3C and before they even existed.

    Whilst it's important for things to be accessable as you describe it. You must think of the media for which a site is produced. Not everyone produces a website to interact with your toaster! In fact not everyone designs a site for your PDA. It's all about the purpose of your site, if it's designed for a computer screen then all you need worry about is what your site works like in current and legacy browsers. Of course it's still important to have coding standards but do you think we would have C++ if they hadn't have extended and played with C?

    And you talk about accessability. What about the W3Cs recommendation of XHTML 2.0 which is TOTALLY incompatible with previous versions of HTML even XHTML1.

    Some of the CSS and HTML we have today probably wouldn't be here if Microsoft hadn't extended it themselves.

    Don't get me wrong, I stick to the standards whenever possible but I do think there are times when it's useful, quicker, easier, etc to use a work around. Especially if you want to downgrade gracefully it isn't always best to use CSS in place of table layout. But then it can also be of a huge advantage... especially for templating.
    Last edited by Rich2k; 11-12-2002 at 07:38 AM.

  17. #17
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    Originally posted by DangerMouse
    But am i right in thinking the CSS method doesnt work for older NS.. (eg 4.7)

    I know this is an older browser now, but i do know people that still use it over later versions.
    All they will see is a plain site wihth no formatting. After all, CSS (and xHTML) is desinged to seperate content from layout.

    Not to mention that 96% of the web surfing population at large have CSS1 capable browsers. Less people than that have Flash installed, not to mention Flash will not help your google rank, will not be read on a palm pilot, and will not allow a person to book mark a spefici section of your site.

    Get rid of Flash desingers first, please (and with it the ads that take over the entire screen, as well as banners that make noises).

    Rich2k

    We did indeed go through this already.

    And true, not everyone programs for accessibility. But keep in mind, blind people will not visit your site, neither will those with cell phones, PDAs, text browsers, etc. Not to mention this part:

    More importantly, your content must be accessible to other computers. Computers will be pumping your site into more intelligent search engines, which will need to glean meaning from your document structure, not just the raw text. Computers will be automatically downscaling your page for smaller screens . Computers will be picking out the content in a page and automatically hiding the index and table of contents.

    Computers can understand XML. Computers can't understand complex HTML that uses what are supposed to be structural elements (like TABLE) to layout your content.


    So not only are you keeping a certain few minorities from your site, but also other computers.

    XML is the future. Ofice suite doc's are being saved in XML, web sites designed in XML, etc etc. XML is the future. No one will tell you that it isnt. And xHTML is the implementation of XML with the common HTML.

    It does not cost you anything to code compliantly. You do not lose anything, your site can be 100% the same. You just need to code it properly. From than on, things like layout changes site wide can be done in a few minutes. Accessibility will increase. Who here wouldn't like a 5% or more free increase in traffic to their site? Isn't that a possible 5% more customers as well? These are customers that previously skipped you as your page was not 100% accessible.

    And HTML has always been a mess, the were the browsers wars of the late 90's with people coding for browsers instead of meeting in the middle. There is the fact that

    Here's a rant why HTML sucks:

    HTML is supposed to be superior? A way to do nice formatting and "mark up" of text and images for browsers right? What exactly is a "mark up" language? Well, HTML tag designers gave us 'pre' tags for a reason. Because they are ignorant.

    Proof in the form of a challenge:

    Without using tables, or 'pre' tags: give me a single line that will align three words; "one" left justified, "two" center justified, and "three" right justified. The line must be under 80 characters or I could do it with spaces. It needs to work for my Netscape 3.04 on Win95. Before you bitch, I could load Netscape .96 beta (installed because it is much faster than 3.04) and make that a qualification. Fact is, many people still use 3.x. If you are really good, this will work fine in LYNX too. I refuse to run MSIE or I would make a standard version of that a challenge as well. [Addendum: Since so many people told me this was trivial in NS 4.x, I told them it had to work for us 3.x types. That means it needs to work in BOTH 3.x and 4.x. I say this because one person claimed to have come up with a solution but said it didn't work in 4.x .. funny, he and half a dozen others have CLAIMED to solve this, yet no one has mailed me the code.]

    It is sad that two channels full of hackers, HTML designers, and hobbyists couldn't figure this out. More sad is that flat ascii and any text editor can do this while HTML can't with its native tags. There is no reason in the world why a table should be needed for such a simple formatting, one that the tag designers TRIED to implement.


    Hell, people have written programs to clean up sloppy coind simply beucase the markup languge was sloppy by nature (and thus coders didnt really care):

    http://www.monesi.com/sergio/hsc.html

    Remember stuffing the header with a whole bunch of meta tags on a whole bunch of various keywords? Simply to get a higher ranking at an engine? All because computers can not (and have never been able) to figure out what the content of an HTML page is. It can guess ylooking at meta tags or by seeing how many times a word comes up in the body, but it really doesn't know.

    XML changes that.

    HTML has always sucked. xHTML is trying to put sctrucutre back into things.

  18. #18
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    For another nice rant about the shortcomings of the language, see:

    Code:
    === Inadequate layout and style control.
    Html describes only a set of 'logical' text attributes. An html viewer
    utility is free to assign whatever physical style it likes to any of
    the attributes. Thus the creator of an html document does not _really_
    have much control over how the document will appear to others.
    There does not seem to be an ability in html to _precisely_ specify
    anything at all about the output pages. You cannot literally specify fonts,
    type sizes, absolute positions on the page, colours of the text or
    background, exact relative placements of graphics and text, or any other
    of the myriad needs for decent artistic control of the result.
    All a document creator can do is make 'logical' definitions, which really
    means that they are only layout recommendations.
    It seems to me that html was designed with a complete lack aesthetic 
    sensibilities, and absolutely no comprehension that others might consider
    such things important.
    In fact, the html standard was written by a narrow minded computer geek,
    who though that 'logicalising' everything was the ants pants, and never
    considered that _some_ people might want to have tight control over the
    visual appearance of their pages. Little things like layout, fonts, etc.
    You have to try reading the original 'Hypertext Markup Language 2.0' spec
    by bloody Tim Berners-Lee to really appreciate what a puffed up, pompous,
    longwinded turkey he really is.
    
    Sadly, Adobe's Acrobat (which does acknowledge the importance of precise
    layout control) is a proprietry format, that uses human-unreadable binary
    files, and needs expensive software tools to generate it. Its really a
    kind of scam: 'take this free viewer, get used to it, then when you need
    to create your _own_ documents, we have this nice package for you - just
    a few hundred dollars!'
    
    
    What html _should_ have been, at the very least, is something like an
    extended Postscript, with colour, object linking, and a more compact syntax
    able to maintain an isolation between the text itself, and the formatting
    descriptions for the text.
    
    See Wired, Aug 95, pg62  for a discussion of html faults/purpose.
    Also, Desktop, Oct 95 pg 20, interview with John Warnock (Adobe founder)
       re acrobat (html replacement), etc.
    
    
    === No plain format.
    When viewed by a plain ascii text editor or viewer, html generally comes
    out totally stuffed up. The html stream itself generally contains _no_
    formatting information of the usual basic ascii sort.
    Result: It is a waste of time archiving an interesting html file with
    other ascii text files. The information in it is too seriously trashed
    for reading as plain text.
    An essential feature of an html replacement is that it should be as close
    to plain ascii as possible, and _must_ display as plain text with a
    reasonable degree of correspondence to it's fully formatted appearance.
    It should be easy to strip out the 'extra' hypertext formatting information,
    leaving just the basic ascii text in usefull format.
    Put another way, the 'text' should contain two levels of formatting 
    information:-
      - Content. As well as the text itself, this should include the basic
        formatting information to keep the plain ascii text in a viewable
        form even if the complex formatting is stripped away.
      - Control. Whatever 'complex' formatting overlay information is required
        to achieve the final page appearance desired.
    There should be a plain distinction in the data stream between the two
    classes of information.
    Current html completely omits the first (simple) formatting data. It does
    make a 'control' vs 'data' distinction, but it is assumed that the 'data'
    contains _no_ formatting information. This is not good enough.
    Long live plain ASCII text! It should not be necessary to reformat major
    texts (such as a Gutenberg e-text) into html to make them available on the
    Web or whatever replaces it.
    
    
    === The 'unknown context extent' problem.
    Furthermore (and more importantly), there is no provision for a 'bond type'
    attribute on html links. So there is no way to define 'clusters' of pages
    that should be always kept together. And so there can be no way to easily
    and reliably fetch _every_ component of an associated set of pages, and
    none other. This is truly pathetic.
    The syntax for links should allow optional inclusion of a variety of types
    of information about the thing being pointed to. This is directly related
    to inter-object link typing in GOSH objects.
    
    This one lack is why the Web is just a big amorphous tangle, with no macro
    structure. You find more organised structure in a milk shake.
    
    My downloading of the unabomb files was a fine example of html errors.
    What must once have been perfectly suited to plain ascii had gotten severely
    mangled by the html zealots. No one had a plain ascii copy up on an ftp
    server.
    
    ===  The 'Lost Graphics' syndrome.    31/7/96
    Links between pages and their graphics are fragile- saving a web page
    generally _loses_ the graphics. This is one of the more severe consequences
    of html's 'non object based' structure - its inability to create clusters
    of associated items.
    Ref other notes on bundling of data against data loss, relative links,
    and the need for an OS with inter-file linkages.
    
    
    === Links are mute.
    There is no way to include information _about_ a link's target in the
    link itself. Things like how big the object pointed to by the URL is,
    or whether it is an essential part of the current context.
    As a result, when you click on a link, you may get a 500 byte file, or
    a 5 megabyte file (and a _very_ long wait).
    This is another consequence of the inability to add attribute information
    to links.
    
    
    === The eternal 'end of line' screwup. (Deja vu)
    Its unbelievable that html uses tokens even for ends of lines.
    Just _what_ was wrong with CRLF? So now there is a _4th_ variety of EOL
    code to add to the CR/CRLF/LF - MAC/DOS/Unix confusion. Brilliant!
    Result: html usually contains very long lines when viewed as text. This
    is just another aspect of the 'no plain format', below.
    It is true there's a need to have two different forms of EOL: one to
    format the raw html source, and the other to control the layout of the 
    displayed (formatted) text. But this is not the way to do it.
    
    
    
    === No self identification.
    A downloaded html file does not contain it's own web source address,
    and has no recommended file name. So you don't know what to call a file
    you save it to, and later you don't know where the file came from.
    This is a weakness of the header syntax.
    Its all very well to say that 'files should only exist as the originals,
    managed by their creators', but this denies the right of people to have
    complete control over copies of information they wish to retain.
    People _will_ want to make their own copies of things, regardless of
    whether this means the information may become 'out of date'. So a good
    network data format should _aid_ this copying and retention of information
    like where the original source was.
    Html seems designed to make copying _harder_.

  19. #19
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    Code:
    ===  The 'showcase mentality'.
    Html has a politically unpleasant taste. It reeks of a 'we put it up,
    you just look it it' attitude. It has no provision for blending into
    public discussion and interaction channels such as Usenet, IRC, etc.
    What the public net really needs is simple ways for anyone to set up
    Compuserve style forums, public R/W file space archives and so on.
    That the only interactivity allowed by the Web is through 'forms' just
    shows how basicly fascist and commercial the whole thing is.
    The Web is the foot of big business stuck in the door of personal data
    freedom. It's tragic that many people's first, even only, contact with
    the Internet is via the Web.  (World Wide Wait)
    
    ===  It's Our data, not yours.
    Browsers, in making it hard to save groups of web pages as linked files,
    deny the need (and right) of users to impose their own order on their data.
    
    ------------------
    2 Sept 1997
    More reasons why HTML sucks
    * The BACKGROUND attribute of document BODY specifies a URL for an image-
      that will be _tiled_ to fit the window. There is no option to _not_ tile
      it. This sucks badly.
      For eg: I want to use a scanned cover of an old book as background to a doc 
      'title page'. Want to center the image and put the title text over it.
      Sorry, no way. And a tiled book looks really stupid.
    
    * In general, its _crazy_ to not allow elements of a page to overlay each 
      other under any circumstances.
      If overlays, and a method of specifying relative positions of elements,
      were allowed, html would be a vastly more versatile medium.
      Text over images, and images over images, using transparent 'backgrounds'
      and animated GIFs, would allow many fascinating & useful effects.
      It would also, incidentally, make the BACKGROUND attibute to BODY 
      superfluous. (See point above)
      Overlays should be laid down in the order encountered in the source.
      So an image intended to be used as background would need to be mentioned 
      first in the html file.
      [need to say more on order of painting, and how to handle out of sequence
      net receipt of overlaid graphics/text elements. - Basicly, whenever an
      element rx is completed, need to display it and refresh everything that
      overlays (is after) it in the html - but only within an 'overlay context'.
      So, allowing overlays implies that html needs a syntax for specifying
      'overlay context extent' (or overlay area). This could be something like:
      <OV> ....list of overlaid elements... </OV>
      The first <OV> could contain attributes like WIDTH, HEIGHT, colour specs,
      etc. Each element could specify its position within the block area using
      any of the usual menas: exact XY pixels, percent of H,V, center, left,
      right, top, bottom, scaled, tiled, transparent colour, opacity, etc.
    
    * Linked font description files.
      Need a way to include exact descriptions of special fonts, or even just
      a few letters. (eg illuminated letters at the start of chapters.)
      Doing this sort of thing as .GIF files is silly.
      Must have this capability for accurately capturing old documents, without
      resorting to full page images. To keep the original appearance, while still
      having the logical text in ascii (searchable) form, there _must_ be a
      custom fonts capability.
      
    * Provision for fixed aspect ratio pages/blocks, and a system of fixed 
      positioning of elements within them (allow block nesting).
      Positioning as %x, %y of block dimensions.
      Definition of text/pic 'fill' areas with 'include/exclude' block lists.
      Any content descriptor should allow a 'tiled' attribute.
    
    * The <IMG ALT="string"... tag. It would be good if could specify a html or 
      text file to display if the browser had image loading disabled, or file not 
      found.
      And Netscape has a bug with display of image ALT strings - they get
      truncated if no WIDTH is specified for the image.
    
    ---------------
    19 Oct 1997
    Links in Plain ASCII text.
    Regarding the ability of html browsers to deal with plain ascii files in
    a sensible way.
    Early browsers could not display text files in the fixed format implied
    by the nature of plain text. If you pointed a browser at a ".TXT" file,
    what you got was a line-wrapped, unformatted mess.
    At least now browsers can display .TXT and .JAVA files in their correct,
    fixed spacing, ordinary end-of-line coded, form. You can even use a .html
    file as an index to several .txt files, which makes publishing large
    numbers of plain text documents much easier.
    Also, thank goodness, it is possible to use the <PRE> .... </PRE> tags
    around a block of plain text, to retain its natural formatting, and still
    use html formatting tags such as <FONT> and <Hn> on elements of the plain
    text within the <PRE> block. So you can have proportional fonts, bold
    headings, etc, while keeping the original fixed line breaks. Hooray!
    
    However, there is one great lack remaining. It is still not possible to
    embed html elements (such as links) within the body of a plain text file.
    You cannot put something like
    
    plain ascii text. <HTML><A href="file6.TXT">Refer to file6.TXT</A></HTML>
    plain ascii...
    
    in a text document (like this one) and have a browser recognise the link
    as valid html, and display it appropriately.
    This is a great pity. If this was possible, the publishing of inter-related
    sets of plain text files would be so much easier. It would allow the best
    asset of hypertext markup (ie links) to be included in plain text files.
    In many cases 'logical reformatability' is irrelevant, and plain, fixed
    format ASCII text is entirely adequate. Yet this added ability to link text
    documents would be wonderful.
    
    This relates back to the ideal of ZenText - that all higher forms of text
    formatting syntax should be considered optional extensions of the basic
    raw, hard-formatted text content.
    
    ---------------
    26 Feb 1998
    HTML has no 'new page' element! This is astonishing. So it considers all
    documents to be single linear spews of text, that must be either scrolled
    through, or jumped around in using links. The concept of 'one screen,
    one page', with a 'show next/previous page' control seems to be foreign
    to HTML. There is no facility at all for printer control in documents.
    No FF, no 'unbreakable block', no 'suggested page break', no nothing.
    
    Why did it take me so long to realise this? More pointedly, why did the
    designers of html (Tim B-Lee, M Andreeson, etc) leave this out?
    What _were_ they thinking of? Its so amazing that this is missing.
    Even from the very early days of plain text files on computers, this need
    was catered for, with utils like troff and nroff. These allowed key tokens
    embedded in a text to control the text's printed appearance. You'd think
    the html designers could have taken a hint. But no.

  20. #20
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    Code:
    ------more
    
    * Assumed EOLs on all <pre>....</pre> strings.
      Results: PRE text always has extra (blank) line after it. Can't append
      ordinary text after <pre>, so can't use <pre> as a spacer.
    
    * Buttons are pathetic. Can't
      - Set face colours
      - Make fixed width (aligned L/C/R) & height?
      - Position text in button face?
      - Use an img for a button face.
      Do style sheets address this?
      Forget buttons.
      This wouldn't be so bad if table cells could be made into hotlinks,
          (ie <td onclick="...">    or <td href="..."> )
      since table cells can be made to look like buttons. But they can't -
      you can only put a link item or img _inside_ the cell. Which means have
      to use an <img> anyway, if want whole area of cell to be 'live' (and
      not show link text underlined without style sheet jiggery pokery.)
    
    * Another major stupid omitted implentation with tables: if this syntax
      was recognised-
        <table usemap="#map_name">
          < stable contents>
        </table>
      then tables would be able to have active cells, rather than just _contain_
      anchors. Why not! So you'd have to make the table hard-sized, so what?
      This would also be great for hotlinking in graphic images broken up into
      multiple abutting table elements (as used when complex outlines are needed.)
    
    * More table problems: You can't specify a <font> for the text in all the
      cells of a table, with a single tag, you have to do it cell by cell. This
      is stupid.
    
    * Inability of basic HTML to allow overlays of different elements - such
      as placing text over an image. Even the most rudimentary of absolute
      positioning facilities would have allowed this. Instead we had to wait
      for the massive complexity of Cascading Style Sheets (which I still
      have not learned how to use) to do even something this simple.
      And all because of the pompous insistence that html should be a 'hardware
      independent' meta-layout description - and hence couldn't allow any
      sort of absolute position specs. (This principle was violated by allowing
      absolute pixel size specs, thus making the whole 'abstraction' edifice
      futile anyway.) Jeeez... what a bunch of idiots.
    
    * Unbelievably stupid comment delimiters. <!-- .... -->   Good grief!
      And there's some kind of bug with the '-->' terminator if its the first
      characters on a line, in some cases.
      This is the same sort of syntax design idiocy that you'd expect from
      people who specified that tag keywords should be in all-capitals. Sheesh!
    
    * File suffixes: Whats wrong with .htm? Why choose 'html'? Like, insisting
      on the 'l' for Hyper Text Markup _L_anguage seems really redundant to me.
      If its not a language, what is it?
      Plus it makes for incompatibility with all the older DOS/Win 3.1 utils.
      For what? I can't help feeling this was another deliberate 'screw those
      DOS diehards, and make them pay (for upgrades)' decision.
    
    * No way to make something align (H) with something already drawn higher up
      the page. Should be able to set 'tab stops' on current position, then
      later refer to these as the position to align to.
      Now can be done with an encompassing table, but this is a pain over
      complex pages, and impossible over multiple pages.
    
    * MAJOR FLAW! No right justified text. Always ragged right. What is the
      excuse for omitting perhaps the most essential feature of decent type-
      setting, from the supposed future universal electronic text medium?
    
    * No ability to typeset, in any real sense. Worst consequence is that
      mathematical equations cannot be described, except as graphics. But
      graphics can't be searched and indexed.
      Only now, in 1998, is a standard for equation formatting being discussed!
      See MathML, NS 4 April 1998, pg 6
    
    * Major shortcomings in the methods for associating active areas with
      event handlers.
      - Not possible to make the whole area of a <td> (or <tr> or <table>)
        element into an <a ...> link, or declare event handlers for it: onclick,
        onMouseover/out. If it was, could use tables as decent button layouts,
        and tables as maps, etc.
        I can't imagine why tables or their cells can't be made into links.
        This is one _particularly_ stupid lack in html.
      - Arrrgh! Even worse is that the <area ... > element of MAP has no
        OnClick="...." element , only onMouseOver, OnMouseOut and href!
        Why!!? Result is: Can't do _actions_ on map areas. Can load another
        href, but not _stay_ with the current one and do something.
        I _refuse_ to believe that ommissions like this were due to oversight
        or time/code-size restrictions. It _had_ to be a 'Lets leave that out,
        so that <insert commercial motivation here>' scenario.
        
    
    -----5/3/1998
    Re the stupid <meta ... > tag in the <head> block. What we have tends
    to look like:
    
    <HEAD>
       <TITLE>Something or Other</TITLE>
       <META NAME="author" CONTENT="Guy Dunphy">
       <META NAME="generator" CONTENT="Mind-Fingers-Keyboard-TextEditor.">
    </HEAD>
    
    What it should look like:
    
    <head>
      <info key=title val="Something or Other">
      <info key="author is" val=me>
      <info key=anything val="also anything">
      <info key=filename val=demo.htm>
    </head>
    
    Note: use of quotes is only required where string contains spaces or '>'.
          Unquoted string terminated by space or '>' chars.
          Also- capitals not reqd for keywords. Thats another silly thing about
          html. Fortunately browsers don't _insist_ on keyword capitalisation.
    
    'Meta' is entirely too abstract a term, for what is really very simple.
    All this stuff does is build a list of label-string pairs, that provide
    info about the document. Why pretend there is anything 'meta' (of a higher
    or second-order kind) about it? That is so ambiguous (_what_ higher-order
    kind?) Whereas 'info' is perfectly specific, and obvious in meaning.
    
    Also, why have a seperate 'title' tag? This is just another piece of
    'about the doc' info that should be in the label-string list.
    
    This whole thing is another example of how pompous and up themselves the
    designers of html (ie Tim Berners-Lee & co) were/are.
    -------------------
    
    * Tables attempt to be too clever for their own good. The browser 'wisely'
      adjusts the cell sizes for 'best appearance' - but in complex tables with
      cells that span multiple rows & columns, it often won't let you specify
      _exactly_ how you want the table. Particularly regarding the vertical
      size of cells.
      There should be an attrib: <table EXACT > ....</table> which stops the
      browser from trying to be clever, and just sizes cells to fit exactly
      whats in them, or accept the user height, width params without question.
    
    * The <img ...> element should have 'hflip' and 'vflip' attributes - so can
      do things like use one image for the four corners of box borders, and
      other symetrical patterns.
    
    --------------------------------------------------------------------
    
    Flaws with specific Web utilities
    ---------------------------------
    
    Netscape
    --------
    
    4/4/95
    ====Re Logging.
    Logging of a complete session. Want to save _all_ files received, but each 
    one only once. So can zap through stuff on line, then read carefully offline.
    I guess Netscape was written by a bunch of people who take free network 
    connections for granted. To them, being connected while browsing is no 
    problem. Some of us though, have to _pay_ for our connect time, or have 
    limited 'free' time, and this puts a severe crimp in our ability to enjoy
    leisurely strolls around the net, or fully absorb what we read.
    
    At the moment, Netscape has the ability to 'save the current page' - ie the 
    single current file, on command. Unfortunately, this does not even include
    the data for any images on this page, which makes the feature much less 
    usefull.
    
    ====Bookmaks files
    If browsers allowed the user to specify a path and filename for the
    bookmark file, and the file was a plain text or simple html format,
    then you could use the same bookmarks file for each of the browsers
    installed. (Yes, while doing web development, its necessary to keep at
    least 3 or 4 different versions and brands of browser installed. Having
    each keep its own bookmark file is a pest.)
    
    Internet Explorer
    -----------------
    If I bothered to note all the flaws with this, I'd be writing forever.

  21. #21
    Join Date
    May 2002
    Location
    UK
    Posts
    2,997
    You don't need to tell me about the advantages of XML, I use XML and XSLT all the time.

    It's a nice rant but HTML isn't going to be phased out any time soon. Even XHTML standard has many of the 'flaws' you point out there.

    That is why it is great to seperate the data and display layer out.

    Have the XML for the data for 'anyone' to read... then design your display layer using the HTML for the web browser. This is why XSLT is so powerful because just by detecting the user agent you can reformat the XML for PDAs, phones, databases or even a standard web browser.... or simply to let another site read your data. It happens all the time already with the big news sites and much more than most people probably realise.

  22. #22
    Wayyyyyy too lazy to read through all of that.
    Based on reading the last reply, I agree -- HTML will be around for a LONG, LONG time -- even the newest of new .NET still has HTML playing a vital role in it.

  23. #23
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    Which is why the current WC3 recomendation is xHTML1, a bridge between old HTML and the future.

    xHTML1 is HTML with an XML implementation. It will be phased out in a few years in favor of xHTML2. Of course HTML will not be going anywhere for a while as it is part of the current recomndation of xHTML itself.

    Any many of the flaws that HTML has are fixed with xHTML & CSS:

    -meta tags (XML acts as the data that computers will srot through essentially getting rid of them)
    -book marks (by stoppping people from using frames, which totally suck, bookmarking becomes a lot easier)
    -background tiled images
    -linked fonts (was in CSS2)
    -overlaying content
    -links mute was taken care of in http1.1
    -fonts within tables

    Sure there are still flaws, but accessibility is greatly increased, several issues addressed, and the rest (majority) are taken care of (or even made ireelevant) in xHTML2, but xHTML2 is not backwards compatible with HTML, which is why it is far from being recomended and we are using xHTML1 as a stepping stone.

    And yes, XML is used in RSS feeds and such all over the place.

    Any look or feature you had in HTML you can do in xHTML. You just need to know how. And if you want to take shortcuts becuase you don't thats up to you. But there is nothing you will lose by using xHTML1.

  24. #24
    Join Date
    May 2002
    Location
    UK
    Posts
    2,997
    Well to put it a bit simpler than that... if you want to make use of XSLT you MUST use XHTML or it simply won't work (well actually the requirement is for valid XML)!

    I think the w3c will work on a way to make XHTML 2 backwards compliant or I can see it never becoming a standard... you can't suddenly ditch compliance unless every website in the world suddenly recoded to XHTML 2 over night.

  25. #25
    Join Date
    Mar 2002
    Location
    Westbury, LI NY
    Posts
    1,705
    I agree, I do think their xHTML2 specs are out of line, its too large of a change and will cuase a large division in the web, worse than the browser wars of the 90s.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •