Can HTML Stand Up to Modern Layout Demands

[kael.shipman]

It's clear by now that we're pretty well past the web-page-for-informational-purposes-only phase in the web world, but it seems to me that HTML just doesn't have what it takes to meet the modern layout demands. Before I go too far off into a rant, I'll pose my question:

 

Is there an element hidden somewhere deep within the HTML specification that works like an inline div, allowing side-by-side box layout right out of the box? If not, is there a way that I can write my own DTD (actually copy the w3c DTD and add an element to it) to accommodate such an element?

 

Alright, so here are my thoughts:

 

HTML works great for laying out documents in a linear fashion. The CSS spec came along to keep it that way. Now we're supposed to lay our information straight down the page and write a 6000-line CSS page to hack and push and shove all the elements into their respective places, and if you don't want to stick to the very simplest design, then you have to use a fixed-width page. What's that? You want round borders, drop-shadows, gradients, layers, a broader array of border styles, and shapes that go beyond boxes - all standard elements of today's websites? Well, sorry; there's nothing in HTML or CSS that can accomplish that reliably. True, you could up your line count to 12,000 and add a few small images here and there, but that defeats the purpose of pairing CSS with HTML to make a lightweight, easily-changeable layout. The HTML spec tells us (perhaps its the CSS spec that really drives it home) that we're not supposed to use tables for layout - tables are for displaying information - yet neither specification provides any other element/attribute/rule combination that has the convenient and desirable characteristics of a table. We all know that with a table, your parallel column heights are already taken care of, sizing is not an issue because tables are drawn dynamically according to content, and - most importantly - the table element is so established that it responds nearly the same way in all browsers.

 

Now is there any way that I can use HTML and CSS without javascript to skip all that crap and go straight to the layout that I want to make? Are the people in shiny white suits at the top working right now to expand the HTML specification beyond the traditions of the 1970s and into this new visual era? All I want is a <container> element. That's it. Just a sideways-working div that responds to percentage heights would make me happy. I've tried just about everything, but it always ends up in the aforementioned 6000 lines of code to accomplish what a table can do in 4. Any ideas at all?

 

Thanks,

Kael

[AndyB]

Be careful what you wish for.  Netscape thought blink was really cool.

 

On a more constructive note, you seem to have decided that the web has to work your way and exclusively with a browser.  That's not how HTML and CSS will develop.  Making the information presentation device-independent is the way forward, not trying to force everything into one person's vision (as if that hasn't happened before) of the perfect way.

[ToonMariner]

Its all about separation of style from content...

 

The content of your page should flow naturally (so when no css is available it reads well).  This aspect of having inline block elements is a design or styling issue so let the right tool do the right job; css.

 

html, xhtml, xml etc. etc. have everything you will ever need to place content into a page - and don't try to do anymore than that.  Once you have your content you can start designing it using css (and hopefully notihng else) then you get the visual layout you want.

 

NOW css could do some more to help - that I will concede; but css3 has implemented some great features which once supported will make web design that much sweeter...

 

[kael.shipman]

Both very right; I do admit that perhaps saying that HTML "can't do it anymore" was too absolute an attitude. All the same, you can't deny that to view an HTML page without style is nearly a catastrophe by most business standards. So yes, we come full circle to CSS, but again, I don't see why HTML hasn't accommodated the new style of layout. After all, a div tag specifies a content area, but why then does HTML automatically assume that it has to go down the page? Block-level vs line-level is in itself an argument of layout in HTML. If you really want to keep HTML layout-free and let CSS do all the work, then you're arguing just as I am for a more interactive canvas-like environment:

 

<block id="1">
Page Header
</block>
<block id="2.1">
Navigation
</block>
<block id="2.2">
<h weight="1">Content Header</h>
<p>Page content</p>
</block>
<block id="3">
Page Footer
</block>

 

Then let the CSS do ALL the work; don't make it compensate for HTML's attempt to cover layout by offering it's own definition of where and how each block should appear by default. If I want a break between my block1 and block2, I should specify that in CSS, not have it assumed in HTML (you may say that CSS has that covered with "display: block/inline;", but try making a div into an inline element - which should be easy, given that a div should be the same as any other HTML element on the page (with a few necessary exceptions, of course) - and you'll see that there's a conflict in definitions). That's separating layout and content. In the ideal world of pure-content HTML, there would be no breaks in that page without CSS; it would be one long line of text, right?

 

As far as defaults, browsers should say, "alright, if there's no style defined anywhere in this document, then default to my own stylesheet," but that stylesheet should indeed be a CSS-based sheet; not a set of HTML layout rules, which seems currently to be the case.

 

At any rate, I feel like there should be something done. It's annoying having to write a CSS rule to tell the HTML that it's essentially doing it wrong. I'm looking forward to the implementation of CSS3, but at the same time I'm dreading it because the one time that microsoft gets it right, mozilla gets it wrong!! I'm at the point where much of my time is spent going so far as using PHP's user agent detector to write different HTML according to browser, which then receives still more different CSS.

 

BUT, browser bugs are well known, well hated, and already over-discussed. So I'll leave this alone and simply concede defeat based on the assumption that, since no hidden element was provided by anyone, none exists to accomplish the side-by-side layout in one fell swoop.

 

Thanks anyway!

 

-kael

[ToonMariner]

well this is a little surreal.  I'm failry sure I can 'get' what you think should happen BUT...

 

Not all browsers are the same.  Some are text only browsers, some browsers are siomply used as conduits to supply content to speak apps that read the page to a visually impaired user. Some have all the graphical support in the world. IE 6 won't work with partially transparent png's unless you use the behaviour hack.

 

So you have to provide content that 'means' something to all these browsers - that means ticking the boxes for the lowest (popular) denominator....

 

Now as to your projected html to server what ou want...

 

these blocks - how wide or high are they? if a block on one line is higher than the others then how should those blocks on the next line behave? - should they fill the gaps in or should their top line be level with the bottom line of the deepest block from the line above? Reading those questions/comments you should note that they are all issues associated with the visual layout or 'style' of the page - and we already have a tool to play with that don't we.

 

 

 

 

 

 

[kael.shipman]

My projected HTML sample document was exactly what you read: A completely CSS based page (I assume CSS is the tool you're talking about in your last sentence). I guess what I'm really arguing is that CSS seems currently to be fighting with HTML. HTML says that every div has a break before and after it. If I don't want it to have these breaks, I have to remove it from the normal layout of the page by either floating it or forcing its position - both of which severely disrupt the flow of the layout and yield less-than-predictable results across browsers. What I'm interested in is a final break between HTML and layout: HTML should make NO assumptions. All defaults should be written in CSS. A stylesheet should be as required in a given document as the < html>< /html> tags (which are admittedly not exactly required in the sense that things still work without them, but you know what I mean). Given that model, a document without a stylesheet will appear as a single long line of text (unless an HTML < br /> tag is inserted, which is kind of a tricky issue when you're arguing content vs layout). Perhaps this is eventually where we're going with it, in which case I'm satisfied, but I think it's just wrong for HTML to remain the decider of default layout.

 

Part of what spurred this is that divs don't act right when displayed as "inline" and spans don't act right when displayed as block-level, and I think that the two tags should have essentially equivalent meaning - that being a container for a given body of content - but for their default display properties, which should simply break down to whether the container has the aforementioned surrounding breaks and should be definable by CSS in a way that allows them to be indistinguishable. You may ask, "Why then do we need so many different tags?" which is a valid question, the answer for which I believe lies in those defaults. Essentially what I think the tags signify is a commonly accepted set of CSS classes. Consider the following two documents:

 

<html>
<head>
  <title>My Page</title>
</head>
<body>
  <table>
   <tr>
    <td>Content1</td>
    <td>More content</td>
   </tr>
   <tr>
    <td>Content in Another Row</td>
    </td>Still <strong>more</strong> content</td>
   </tr>
  </table>
</body>
</html>

 

and

 

<block id="html">
<block id="head">
  <block id="title">My Page</block>
</block>
<block id="body">
  <block class="table">
   <block class="tRow">
    <block class="tCell">Content1</block>
    <block class="tCell">More content</block>
   </block>
   <block class="tRow">
    <block class="tCell">Content in Another Row</block>
    <block class="tCell">Still <block class="strong">more</block> content</block>
   </block>
  </block>
</block>
</block>

 

Both could very easily be the same document - read the same by a screen reader and displayed the same on a text-only browser - the difference lying only in where the browser gets the information it needs. That's what I mean when I say that tags are equivalent to commonly accepted layout classes.

 

SO: Yes, I do find value in the variety of tags in HTML as well as the content organization, but my argument is against the fact that we've chosen a very long and painful transition from solo HTML to full integration of HTML and CSS - one that involves a definition of layout  being inherent in HTML tags and changeable (and only marginally in some cases) in CSS rules.

 

Maybe that's just a long way of saying I HATE BROWSER BUGS!!

[ToonMariner]

OK I was going to unravel the whole shebang but your last line said it all...

 

There is nothing wrong with html as it stands.  Your idea of having a default css file already exists - its called a document type declaration.  With the DTD you can even gt IE to play ball in compliant mode rendering the box model properly.  Browser bugs are NOT the fault of the html specification, they are the fault of coders implementing them poorly.

 

So instead of re-writing the rule book use what you have and hope that future browsers will implement standards properly.

[kael.shipman]

Yeah, I'm still kind of wondering about the DTD. I read up on it a bunch, but I didn't manage to glean what I needed from the W3C's "How to Read the DTD" manual on my first pass. Is that something that I could potentially edit and post on my webspace (sorry to repeat the question in my first post)? I noticed of course that the DOCTYPE "tag" at the top of the document simply points to the location of the DTD, but I wasn't sure if that was for formality or if the browser actually read that every time (or cached it) and used it to render the page accordingly. If the latter is true, could I then edit the DTD, post it on my webspace, then link the page to the local DTD instead of the W3C version and have all the nice little features that I want?

 

Also, does the DTD define aspects such as border and padding rendition? One of the most painful discrepancies that I've found in browsers has been that some add the padding to the width of the box and some don't. Personally, I prefer the latter - I feel like if you say you want a box to be 100px, it should be 100px, even if that means the content gets less space - but that's getting into personal opinions again.

 

Actually upon further consideration, if you could do all that with the DTD then browser bugs wouldn't exist... So scratch that idea.

 

Thanks again,

Kael

[ToonMariner]

You can indeed create your own dtd's and provided they are on a live server you link to them in exactly the same way as those on teh w3c server are.

 

The rendering of any document is not dictated by the dtd.  The rendering is performed by the browser based on what it sees in the dtd and css.  The box model dicatates that teh width of an element is teh width of its content - padding and borders are ADDED to this so unfortunately your preference on that (basically how IE implements teh box model) is NOT what the standards suggest - its not a personal opinion - its how it has been decided it SHOULD be implemented.

 

Browser 'bugs' will always exist when developers CHOOSE to not implement the standards as intended.  If you want somethiing that is standadr across teh board then you must petition evey browser vendor in teh world to ensure that their browser renders exactly as the standards suggest when given a particular dtd.  Good luck and god bless - you will need it as even the most compliant browsers still lack in certain areas!!!!!