h a l f b a k e r yNot from concentrate.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
<vr>
2 axes of page divison | |
I'm sure any HTML author out there who uses tables to design his/her pages has wanted to add some sort of column divide.. or something.. vertically between 2 sections of page. Until now, however, the only way of doing this has been defining a cell border (with much fuss) or simply adding a column of
pipe ('|') symbols, because the W3C has been kind enough only to give us <hr>.
So, where is <vr>? Why can we have a horizontal rule but not a vertical one? This injustice must stop, and the introduction of this new tag would surely solve layout problems.
As noted...
http://moniplex.com/vertical.html
BAKED
In MS IE and Mozilla, if not Opera.
Can we all go home now, please? [DrCurry, Aug 08 2002, last modified Oct 17 2004]
[link]
|
| |
How about <table frame=void rules=cols><td>First bunch of stuff<td>Second bunch of stuff</table> ? |
|
| |
Works for me. Guess it's Baked. |
|
| |
[Marked-for-deletion - Halfbakery Help Desk] |
|
| |
Or are you experimenting with some sort of subliminal mushrooms, blissy? |
|
| |
It's not in the W3C specification, and I've ~never~ seen it work. So there. |
|
| |
The <vr> isn't in the W3C spec, AFAIK, but the <table frame=void rules=cols> trick is W3C compliant. |
|
| |
This seems like a reasonable invention. Why is it mfd? |
|
| |
It would be interesting to see if it would work...and just adding a column in a WYSIWYG design interface wouldn't be too hard. |
|
| |
Macromedia Dreamweaver, anyone? |
|
| |
Heck, you don't need Dreamweaver to prove out supercat's example. But, just to hammer this one to death, see link. (And no, I know this one still involves tables and cells, but it ain't complicated and it's certainly not such a huge injustice.) |
|
| |
The example shown is certainly not a <vr> tag and so I still wonder why this is an idea bad enough to merit the mfd. Are ideas that propose alternatives to doing something not welcome here? |
|
| |
gen1000: Two problems with the <vr> tag, as proposed: |
|
| |
-1- It's far too late in the game to add such a thing to the spec, especially when tables may be used as indicated to obtain the desired effect. [nb DrCurry: You may wish to replace <hr> with <hr> in your example.] |
|
| |
-2- The normal HTML document paradigm is that documents have a comparatively fixed horizontal width independent of length and have a vertical height which may vary considerably. The <hr> tag poses no formatting ambiguity; everything above it takes as much vertical space as it needs, and everything below it takes as much vertical space as it needs. By contrast, there's no obvious 'right' behavior for a <vr> tag. Should it divide the page in half, or in some other proportion? Should everything before the tag go to the left and everything after to the right? Solving these issues would most likely require something at least as complicated as the <table> trick which already works. |
|
| |
What exactly would you have the <vr> tag do? |
|
| |
Nick, watch and learn:
<hr width="1" size="500" noshade>
There it is, 500 px 'tall' line. What do you need a vr tag for? Swap width and size on an hr and you have it. |
|
| |
Also, doable using a 1 pixel sq. gif img tag, using width="x" height="y" where x - thickness of line. |
|
| |
Doable several different ways in CSS. |
|
| |
waugsqueke: I'd never seen the <hr> tag used like that, though it's not really usable as a <vr> tag unless put inside a table element since nothing will appear to its right or left. The table technique I gave should suffice for most cases where one would want a vertical line to separate areas of a page, with stuff on both sides of it. |
|
| |
I'm not questioning that your <table> example would work, I'm just saying that a <vr> would be a lot less fuss. What's wrong with <table><tr><td width="50%">first column</td><td><vr></td><td width="50%">second column</td></tr></table> ? |
|
| |
And, BinaryCookies, the very reason I learnt HTML was to get away from the horrible WYSIWYG environment, which tries to do what ~it~ feels right to your page. HTML just gives you that nice level of control. |
|
| |
Clyde: Hey, Bubba, over here, man ! |
|
| |
Clyde: Look .... in them bushes .... whe got us a whole flock 'a HTML Nerds ! |
|
| |
Bubba: Wheee .... will you look at them, jus a-settin there an a-cluckin' .... |
|
| |
Clyde: What you think, Number 4 Or Number 6 shot ? |
|
| |
Bubba: Don't matter, there's so danged many .... woods are full of 'em this year ..... |
|
| |
<Click of safety catches..... > |
|
| |
// would be a lot less fuss
Hmm, given how hard it is for the W3C to get each version of HTML accepted I'm not sure if this is true. How would you control window resizing? Would your new tag recentre itself? What happens if you want your line to be slight off-centre? - you would still need to position it with a table. Use waugsqueke example, or in <img> tag in the same way (as most pages that use vertical divisions do).
(Damn, I hate getting drawn into HTML arguments...) |
|
| |
...especially with 'Bubba and Clyde' lurking in the bushes. |
|
| |
supercat said it best. I can't really add much without paraphrasing. |
|
| |
To ask for a <vr> tag is and reasonable request. To say that it's unlikely to happen because of the nature of a web page and the evolution of html is a reasonable response. |
|
| |
Croissant for asking. Fishbone for taking the reply with no grace whatsoever. Neutral vote. |
|
| |
So, ideas which would result in an addition to an established spec or which have some ambiguity are not welcome here and are marked to be deleted? |
|
| |
//So, ideas which would result in an addition to an established spec or which have some ambiguity are not welcome here and are marked to be deleted?// |
|
| |
The key objection to the <vr> idea is that the functionality being sought already exists in the <table> tag. This would not be sufficient to rule out the <vr> idea if it offered some clear advantage which might merit going through the trouble of adding it to the spec. As yet, however, no such clear advantage has been offered. |
|
| |
To clarify, let me offer an idea of my own I'd like to see in HTML: inline image data. Add a field "local" to the image tag which would identify an <imagedata> block. |
|
| |
Typical example:
<img src="http://wherever.org/bpthumnail.jpg" local="bp" width=32 height=24>
<imagedata name="bp" type="jpg" encoding="hex"><!--
0012391929349139915 ..
3528349525235492431 ..
--></imagedata> |
|
| |
This would cause the browser to search in the current HTML file for an imagedata block named "bp". If such a data block exists, the browser would not have to access the external "http://wherever.org/bpthumbnail.jpg" file. If it does not exist, the browser would have to access the file after finishing the current document. If the browser doesn't know about the local flag, it would ignore it, fetch the image from the specified source, and then ignore the <imagedata> tag later on. |
|
| |
This extension would be primarily useful for small images like thumbnails or dingbats. Encoding larger images within the html document, while not forbidden, would likely cause things to load more slowly than if the large image were separate; for small images, though, the speed savings from having them in-line could be significant. Further, it would no longer be necessary to download lots of little files to view the page. |
|
| |
Notes about this proposal: (1) clear advantage over status quo; (2) clear plan for fallback behavior. The <vr> proposal offers neither of these key features. |
|
| |
Actually, [NickTheGreat], I use DreamWeaver for that exact purpose. It *doesn't* screw up your pages. The only editor I would consider for any HTML work.I would boot into linux and use vi as a text editor before I would use FrontPage. |
|
| |
I think I'm seeing your point of view correctly, ¯supercat. Even working in a line break tag after <vr> to create a table effect would make for some additional improvisation within an approved <table> spec that already is subject to innocent misuse by authors. |
|
| |
Thanks for the great lesson in rules, and for making my ‘browseback’ list look really scary! |
|
| |
It's a very simple and good request. |
|
| |
The table doesn't put the vr in the right place according to the typing. <vr>
And you have to remember to put the </table> at the end. |
|
| |
And you have to have macromedia dreamweaver to remember how to do this simple thing. |
|
| |
So what's wrong with a simple <VR>? |
|
| |
I agree with [pashute] on this. I think the mfd is not right. |
|
| |
The disadvantage of the table-rules solution is that it applies to all columns. A <vr> inside a table might solve that. |
|
| |
The syntax would be something like:
<table><tr><td>content1</td><vr><td>content2</td><td>content3</td></tr></table> |
|
| |
You could use a <hr> on a similar way in a table. |
|
| |