I was wondering if anybody knew a way where you can have an image that also serves as a link and then be able to put text over this image using only HTML?
Essentially what I am using this for is to create "pretty" looking buttons for my client. Unfortunately, the program that I am REQUIRED to use will not allow me to insert any CSS code so this will have to be purely HTML.
And I know I could create the image in Photo Shop with the text over it already. However, I would like this to be a dynamic button as I have hundreds that I want to format to this style and if new ones appear I don't want to create a new image every time they want a new button.
Are there any solutions to an issue like this?
Even though I still can't for the life of me understand why you would want to do something like this. Or why someone would care about restricting css markup since it's not even really code. However you could take it back to the old school HTML4 days and do something like this if I understand your restrictions correctly. Which should still render fine in html5. Hope it helps.
CODEPEN TO PLAY
...PS, tell whoever decided to restrict CSS use that it's pretty counter intuitive to a contemporary...well, anything. Just my two cents. :D
Oh also, by the way, elements like <center> aren't supported in html5 even though it should render, so you'd be breaking some rules. If they mean for it to be an actual HTML5 solution, then you require CSS.
<table>
<tr>
<td></td>
<td rowspan=2><img src="http://res.freestockphotos.biz/pictures/15/15789-illustration-of-a-blank-glossy-rectangular-button-pv.png"
height="50" width="200">
</td>
</tr>
<tr>
<td colspan=2><center>overlay text</center></td>
</tr>
</table>
You could also just use like background= on a td or something if your images are all fixed size etc.
Bootstrap's page about responsive design says this:
Responsive utilities should not be used with tables, and as such are
not supported.
Being new to web development, I am not familiar with what this is talking about. It seems that there is a general aversion to using <table>. Is this true?
Also, the quote as phrased doesn't make sense to me. Shouldn't it read like this?
Tables should not be used in responsive utilities, and as such are
not supported.
Tables are very structured elements. A <td> can only ever be a column. You couldn't change it to suddenly appear like a row or float it somewhere, etc., etc.
HTML, in responsive design, shouldn't define what something should look like (or where it should appear to a degree) that's CSSs job. the HTML should simply group text and other elements. So a HTML <table> and all it's associated tags breaks this paradigm.
CSS display now contains table like elements: How is a CSS “display: table-column” supposed to work? so this removes the need to embed <table> tags and allows you to use the more generic <div> tags and their like, thus now it's a <div> that looks like a <table>, there is nothing to stop you making this appear as something completely different simply by updating the CSS. You could even make it look different for different audiences, etc.
hope this helps a little.
It's not really true in the latest browsers, but traditionally it's been hard to unstyle a table in CSS to not have a table layout.
So while a table might be the correct semantic element for your tabular data, pragmatics meant that if, in some responsive design profiles, you want the data to be displayed in a linear format, it just couldn't be done, except by using JavaScript to rip the table markup out and replace it.
Try table, tbody, tr, td {display:block; } - (JsFiddle http://jsfiddle.net/Z26GF/) in various browser (e.g. compare IE10 with IE9 behaviour) to see what I mean.
(The more I learn about Bootstrap, the less I like it. It seems to encourage a number of bad HTML practices. This is one of them)
This question already has answers here:
Why not use tables for layout in HTML? [closed]
(66 answers)
Closed 9 years ago.
This is something that makes me crazy every time I see it. Why is using div elements almost an obsession?
I understand why having mostly divs in the markup, each one with an id or (even better) a className can help develop a clean markup and keep control of visual changes.
But, for example, I keep seeing questions about how to make divs behave like a table, and even when they are told somethings will not be compatible with x or y browser version, they still want to do things like this:
<div style="display: table">
<div style="display: table-row">
<div style="display: table-cell">Content</div>
<div style="display: table-cell">Content</div>
</div>
<div style="display: table-row">
<div style="display: table-cell">Content</div>
<div style="display: table-cell">Content</div>
</div>
</div>
Why? ...really: Why??
Why is that better than using a table? Or, why is using tables something that abominable?
Tables are part of HTML elements. They exist for a reason and have a good purpose. They are not deprecated and they are not going to dissapear anytime soon (or sooner than divs for that matter). And most importantly: they behave correctly in all browsers & versions!
So... why the obession with making divs behave like tables? Why do so much people write HTML/CSS that way and then feel proud of something so dirty?
This is not exclusive to tables. I keep seeing divs replacing all html elements, like h1..h6, spans, etc.
Why??
No, using divs that behave like table cells, just for the sake of avoiding table tags is not much better.
It is completely fine to use tables, where tables are appropriate. If you want to display tabular data, use tables. If you just use tables to layout your page in a grid-like environment, then no, don’t use tables.
The reason why people use divs with table behavior is usually because they don’t want to use tables, as they would have a semantical meaning, but they still want to stick to a tabular layout.
In the end, you should never use tables to layout pages though. Many good reasons are given here.
Possibly divs might be better if you wanted a table like this:
<table>
<tr>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
</tr>
</table>
I've been using bootstrap for a while now but I can't do this thing (I don't even know how to do it without Bootstrap).
What I want to is is indent either a table or divs. I've seen something like this done in Bootstrap with <li> but nothing with tables. Basically I want a table with the <th> which is the title and below the names of the projects. The reason I need to indent is because the projects depend on other projects; so the project below anoher project has to be possitioned slightly to the right of its parent (which is basically indenting, right?)
Here are a couple options if what you need is a small indentation to suggest a hierarchy. They're not specific to Bootstrap tables.
The first is to add a couple nonbreaking spaces per level of indent that you want. This has the advantage that the spaces can be added by whatever code is producing the table content without disturbing the html of the table. It has the disadvantage that if the text wraps within the cell the wrapped lines will not be indented. Also, all those invisible nonbreaking spaces can lead to copy/paste surprises.
<td> Indented Text</td>
<td> Indented More</td>
If your code is emitting the html of the table, a better solution is to change the padding of the table cell by increasing amounts. It has the advantage of finer control than increments of nonbreaking space, and wrapped text is also indented. The disadvantage here is you're emitting html from code and that may make it more difficult to adjust the layout.
<td style="padding-left:20px">Indented Text</td>
<td style="padding-left:40px">Indented More</td>
Could this be solved using offsets? It's somewhat difficult to help when we dont know the situation or how the markup is looking.
The offset* class will add a margin-left to your element. Maybe that will help you?
[Note: for those who may be confusing this question with "why not use tables for HTML layout", I am not asking that question. The question I'm asking is why is a grid layout fundamentally different from a table layout.]
I'm researching CSS libraries (in particular Bootstrap) for a project. I am a programmer rather than a web designer and I feel I could benefit from a library that encapsulates good design.
We all know that it's bad practice to use HTML tables to accomplish basic site layout because it mixes presentation with content. One of the benefits provided by CSS libraries like Bootstrap is that they offer the ability to create "grid" layouts without using tables. I'm having a little trouble, however, understanding how their grid layouts differ in any meaningful way from the equivalent table layout.
In other words, what is the fundamental difference between these two examples of HTML? Am I wrong in thinking that the grid layout is simply a table with another name?
<div class="row">
<div class="span16"></div>
</div>
<div class="row">
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
</div>
and
<table>
<tr>
<td colspan=4></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
The difference is that the first example is semantically marked up, assuming the data being marked up is not actually tabular. <table> should only be used for tabular data, not for any data which happens to be displayed in a layout similar to a table.
It is correct though that using CSS packages like Bootstrap, which require you to assign classes to HTML elements which are not semantic but presentational, reduces the separation of content and presentation, making the difference somewhat moot. You should be assigning semantically meaningful classes to your elements and use lesscss mixins (or similar technology) to assign presentational behavior defined in the CSS framework to these classes, instead of assigning the presentational classes to the elements directly.
Say:
<div class="products">
<div class="product"></div>
</div>
.products {
.row;
}
.products > .product {
.span16;
}
Note that I say should. In practice this is not necessarily always the more workable option, but it should be the theoretical goal.
I believe that CBroe comment is the best option, so I chose to clarify it.
Avoid div's. A div should be your last resort, not your first option. Instead, try to use Bootstrap classes on the actual elements. For instance:
<form class="container">
<fieldset class="row">
<label class="span4" for"search">Type your search</label>
<input class="span6" type="text" id="search" />
</fieldset>
</form>
It is a shame to use fieldset to contain a single field, but it is semantically best than using a div for the same thing. The HTML5 standard defines many new container elements, such as article, section, header, footer and many more. In some cases you will have to use div's, but if you minimize it's use then your code will be way more semantic.
The fundamental difference is that you can "reflow" the layout with Bootstrap for different display sizes simply using media queries without needing to change your markup. For example, I can decide that on desktops, I want your 4 divs to be on same row because user has high resolution wide display but on phones I want 2 dives on one row and next divs on next rows. So this way I can adapt my column count in each row using media queries. If you use hard coded HTML tables then it is very difficult to do this.
Having said that, I don't really like bootstrap implementation for the following reasons:
It has breakpoints hard coded in pixels. This means, as phones and tables advance in display resolution, your website may start showing unexpected layouts on those devices. Pixel count is poor proxy for display size.
It limits maximum used display area to 1170px which is again a bummer for users with nice wide displays they can actually use to see more content in your app.
Bootstrap's layout is not source independent, i.e., you can't change column order that is set in HTML. This is however more of a pedantic point.
The default layout is for very small resolution and higher resolution layouts trigger only when media queries fire, which IMO, is a poor choice considering phones will continue to have better resolution and sooner than later your website would have default layout set for outdated mobile devices.
Bootstrap layouts are not truly "worry free" in the sense that you have to read their fine print to see all the bugs and browsers they didn't see worthy of supporting but which you may care about. If you are targeting users in South Korea or China, you would be in for surprise, for example.
So, not everything is gold in bootstrap and their approach is not necessarily always the best possible (as an aside, one other thing I despise in bootstrap is their obsession with so called "jumbotrones" - those real estate wasting inconvenient in-your-face headers - which I hope community doesn't start taking as "new standard"). Personally I use CSS table layout (display:table) these days which has similar benefits as bootstrap without hardcoding <table> in my markup. I can still use media queries to rearrange rows depending on portrait or landscape orientation, for example. However the most important benefit is that my layouts are truly pixel or even percentage independent. For example, in 3 column layout, I let content to decide how much space first and last columns should take. There is no pixel or even percentage width. The center column grabs up all the remaining space (which is good thing for my app, but it may not be for others). In addition, I use ems in media query break points which bootstrap surprisingly doesn't.
I use the Bootstrap grid for page layout, tables for tabular data.
I think of the grid in Bootstrap, not as a grid in the developer sense, like a gridview control, but more in the design page-layout sense - as a grid to contain the page contents. And even though the Bootstrap grid could be also used to create a conventional grid containing tabular data, as deceze pointed out, this kind of grid is better suited for HTML tables - which are still acceptable to use in this scenario.
if you just use tables i think you will miss out on alot of flexibility in re-sizing your document for mobile/tablets without having to make a separate page for each device. once your table structure is defined all you can really do is zoom in and out.
While there's not necessarily much semantic difference between the two sets of markup (since the classes used by Bootstrap's grid system are indeed purely presentational), one very important distinction is that the grid system is much more flexible.
It would be very difficult, for example, to make your table-based layout respond to different screen sizes. There's no way to tell the browser to display one td element below another td in the same row. Whereas with the div example, that's easy to do, and the same markup can be presented in different ways even when the classes are "presentational" in the sense that they define the relative proportions and positioning of the elements on the page.
If I may, I'd like to summarize what I gathered from the other comments and the link explosion I experienced from this page:
The problem with using tables isn't the grid layout, it is the attempt to express it with HTML instead of CSS.
Bootstrap allows grid layouts through (mostly) pure CSS, which is why it is OK. The 'mostly' part comes because your HTML will still be contaminated by your layout data, but more subtly:
<nav class="span4"> ... </nav>
<article class="span8"> ... </article>
This is surely significantly more semantic and maintainable than the old tabular designs, but the 'span4' and 'span8' are still display-data embedded into our HTML. However, since design can never be truly be decoupled from our data (e.g., nested divs), this is a reasonable price to pay.
That being said, even this coupling can be broken, if you use some more modern CSS features provided by a pre-processed language such as LESS. The same example:
<nav id="secondary-nav"> ... </nav>
<article id="main-content"> ... </article>
Coupled with the following LESS:
#secondary-nav{
.span4;
// More styling (padding, etc) if needed
}
#main-content{
.span8;
}
This creates fully decoupled HTML and Stylesheet, which is ideal, because the HTML is cleaner and more readable, and redesigns can be made with less HTML modification. However this only works if you use LESS or some other CSS pre-processor, because CSS currently does not support mixins (AFAIK).
We already use LESS in my workplace, so I know I'll be pushing towards using this type of solution. I'm a very strong believer in semantic HTML and data-design decoupling. :)
Basically DIVs are DIVs & Table elements are simply table elements. The problem with tables is often just keeping track of all of the columns & the rows because it is ultimately a strict data construct. DIVs are far more flexible & forgiving.
For example, if you wanted to to take the four DIVs with the class that equals "span4" and just change them to a 2 column width, all you would need to do is adjust a wee bit of CSS for the outer class "row" and maybe the class "span4". In fact when doing DIVs like this I would avoid calling individual DIVs "span4" or some other number.
My approach would be to create a parent wrapper DIV that is called "rowspan" and the inner DIVs would have some generic ID like maybe "cell".
<div class="rowspan">
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
</div>
Each "cell" class could have a width of 100 pixels for example, and then the parent "rowspan" could be 400 pixels. That would equate to 4 columns in a row. Want to make it 2 columns? No problem! Just change "rowspan" to be 200 pixels wide. At this point it is all in CSS so it's easy to do without rejiggering page structure in the DOM.
But with tables? Not easy. You would have to basically re-render the table with </tr><tr> tags to create new rows.
Version with table, tr, td depends on browser algorithms - wrapping, dynamic width, margins, centering etc.
Version with div can be more easily tuned by css and scripts.