You know, I get really annoyed at standards pay more attention to themselves, rather than to what people *want* to do with them.
CSS is my current example. We all know that Firefox (and Opera, etc) are more "compliant" with the standards than Internet Explorer. But you know, in many cases, Internet Explorer does what you'd WANT the standard to do.
My current gripe is the fact that the HEIGHT style in CSS is ignored for inline entities (SPANs). Internet Explorer allows you to use HEIGHT in a SPAN, but it's not "standard" and Firefox ignores this property.
Why does this matter? Try converting an HTML TABLE into non-table CSS form. In a table, you can have a cell with a background image and you can adjust the height and width of that cell to show the entire background image. A table cell is an INLINE entity. In other words, TD elements are stacked horizontally. But in CSS, an inline element cannot have a width and a height! This makes it nearly impossible to convert tables to non-table CSS!
Here is the specific problem that I was tackling today. I finally GAVE UP trying to do this with pure CSS. After about 4 hours of messing with it, I just gave in and used a TABLE to achieve the desired goal.
Challenge: Create a set of classes to create extendable (sizeable) buttons that can be placed INLINE with other text. Here is what I want it to look like:
then you will find that Firefox shrinks the size of the box down to the height of the text, so you don't see the entire background image. If you attempt to use the HEIGHT property in the style sheet to increase the height of the button, it gets ignored because these are INLINE elements.
If you try to convert everything to DIVs where the HEIGHT property works fine, then you have the problem that the button no longer can be placed in the middle of text. Using the "display: inline" property doesn't work on Firefox, so you can't use that trick either.
Feel free to play with this in your spare time and let me know if you come up with a good solution. Until then, I'll just stick with the TABLE method that seems to work.
But this is just one of the examples where I'd like to use CSS to get rid of a table, but I can't because the idiots defining the standards didn't think it was useful to allow the height of an inline box to be changed. Why not? Changing the text-size will change the box height, and you can freely mix text of different sizes on the same line. So obviously all browsers need a way to handle mixed box sizes of inline elements. So why not let the designer specify their own size instead of auto-computing it from the text itself? It's just stupid.
everything I need can then be done in the style sheet.
If they want people to start using "pure" CSS instead of Tables, then they had better fix the CSS standard to allow the things that are needed to do this. Sure, it's easy to replace most tables that are just used for page layout. But until they allow us to modify the width and height of inline entities, you won't be able to completely get rid of tables.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Sep 07, 2005 2:00 am
The background of an element is still only displayed within the bounds of that element. So, for example, if the label of the button is "Button Label", the background-image for this element is set to the minimum size needed for that text. Sure, you can make the text of the button larger and larger, but that doesn't help much...you end up with a button with ugly enormous text and still no way to ensure that the resulting height is the same as the GIF image created for the button background.
Here is an example of what you get:
text text <SPAN style="background-image: url(/store/skin1/images/butbg.gif)"> Button Label </span> text text
using the HTML code:
Code:
text text <SPAN style="background-image: url(/store/skin1/images/butbg.gif)">Button Label</span> text text
Now if we add a "height: 22;" style property, we get this:
text text <SPAN style="background-image: url(/store/skin1/images/butbg.gif); height: 22;"> Button Label </span> text text
which works in IE but not in Firefox.
In theory, it would also work if we inserted an IMG tag into the SPAN in order to force the box to be sized correctly. But that's a real kludge and no better than using tables instead. You shouldn't need to stick an image into an element just to change it's height.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Sep 07, 2005 2:08 am
Btw, to get some of the HTML in this blog to display correctly, click the main Forums link to display the list of forums, then click on Zugg's Blog at the bottom to view the blog, then click the entry just like any other forum post.
If you try to view this blog directly from the Blog module itself, it just displays the extra HTML inline. I'll try to fix that, but I'm not in the mood to mess with the blog software script right now.
Well, this time it is something that you can blame Firefox for not following the standard (IE might not follow it either, but since it allows the height porperty in inline elements it might be hidden.) According to the CSS2 standard, the height property is only taken into consideration for elements with display type of block or inline-block, and for replaced elements. Replaced elements are those that their dimensions are not known by the browser beforehand, like images.
So, the right way of doing what you want would be to set the display: inline-block style property for the SPAN and then specify the height style property. According to the standard, Firefox should take the height property into consideration in this case, but apparently it doesn't.
_________________ Kjata
Last edited by Kjata on Wed Sep 07, 2005 2:00 pm; edited 1 time in total
Ok, after some experimenting I found something that may help you do this. Try using the padding style property. In the example you provided, a padding-top and padding-bottom of 1px displays the button like you want it in both IE and Firefox.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Sep 07, 2005 4:04 pm
Kjata, I'll give that a try. But does it get messed up if the user changes the font size on their browser? Seems like if you just add 1px of padding, the main height is still determined by the font height, which could vary from system to system.
I don't see any "inline-block" property for the display tag. All I see in my reference is "display: block" or "display: inline" and from what I can see, the DIV tag is set up as a "block" tag and the SPAN tag is set up as an "inline" tag. So setting a SPAN to display:inline doesn't actually change anything. And using DIV with a display:inline is the same as just using SPAN to begin with.
But you are correct that Firefox is doing something really odd. When using the TABLE solution, I use display:inline on the table to convert it to an inline element. And Firefox seems to handle that just fine. So Firefox seems to be parsing the display:inline style.
So I guess I need to learn more about what the difference between a normal "inline" element and the "inline-block" element that you mentioned from the spec.
You're going about it the hard way. I'll post again in a bit with an example of the easy way... but I'm at work right now and can't spend too much time at once on it.
_________________ Darker
New and Improved, for your Safety.
Another limitation on it I just thought of - it only works width-wise with resizing browser text. There's a way to make it work height-wise too, I just didn't bother looking it up. The discussion at ALA (http://www.alistapart.com/articles/slidingdoors) should cover that.
Hope it helps.
_________________ Darker
New and Improved, for your Safety.
If you chane the font size it will get messed up, but this will always happen because the image you use for background is of a fixed size. Or am I missing something?
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Sep 07, 2005 5:26 pm
With the TABLE solution, the cells are a fixed height based upon the size of the background image. So as the text size changes it still displays properly.
Thanks for the link. There are a *lot* more options for the display style than I ever realized!
afaik, "inline-block" is a CSS2.1 option. You won't find much (any?) browser support for it yet.
If you weren't bent on rounded corners (ala phpbb buttons), you could do this mucho easier. Just specify a gradient background image and a border for links. You can get creative with borders (see outset) to make them look more like buttons.
You were upset with CSS standards-makers, but I think that's a bit misplaced. The point to CSS is to eliminate decorative markup, not just replace it, and certainly not to cause more. The important part of the button isn't what it looks like (except that it's recognizable as a clickable object). It's that it does something.
To that end, using a bunch of table cells and an onClick does you a disservice (I've spent hours rewriting my own pages upon this education). It takes longer to download, you have to rely on things like http compression to make the load time more tolerable - and/or - you pay more in bandwidth, and the link won't get spidered anyway.
It's much more practical just to use a plain "a" link, maybe with a "javascript:function()" as it's href, and style that link appropriately. Just the link, with minimal extra tags (if any). The resulting content is shorter than the table's tag-soup, more understandable to a search engine or text browser, faster to download, involves fewer images to create, and ultimately saves time and money.
CSS is here to *help* :)
_________________ Darker
New and Improved, for your Safety.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Sep 07, 2005 11:12 pm
But you see, that's where I disagree. I want my buttons to look exactly the way I designed them. I *want* to use bitmaps. CSS can be a wonderful thing and it's just a matter of recognizing what makes sense. Forcing people to use square buttons with simple colors is going *backwards* in user interface design. It's one of the reasons I hate most online web applications. They should be moving *forward* and providing richer user interface elements.
Why not allow the height of an inline box to be specified? Why is this a bad thing? As I mentioned, there are already plenty of areas where the height gets controlled. Getting rid of this control from a designer point of view is just a *bad* idea.
Also, if you look at the code I'm using for the TABLE version, it isn't much longer than a pure CSS form would be anyway, so I don't buy the argument of "CSS is smaller". In fact, that's another direction the standards group is going away from. Instead of using B I'm supposed to use STRONG. Or, not use STRONG at all and instead use "SPAN Class="MyBoldClass"". How is this reducing page size? I don't buy that. While *some* CSS can reduce page size, that's certainly not the main reason for using CSS.
The main reason to use CSS is to split the formatting from the text content. And I believe in this concept. Even my TABLE example does this (buy putting the colors, images, etc into the style sheet).
My actual working version *does* use an A link instead of the OnClick. That was just an example that doesn't have much bearing on the result.
I agree that CSS is *usually* there to help, but this is a case where I still firmly believe CSS has let us down. If you don't provide a mechanism in CSS to replace existing TABLE functionality, then it's always going to be a problem. I'd *love* to replace the TABLE syntax with simpler and faster CSS syntax, but only if it does what I want.
As I said at the beginning, they need to pay more attention to what designers and users WANT. Just let us specify the HEIGHT of a inline SPAN tag. There's nothing wrong with that. It's not like it goes against some great moral code. You can specify the height of a DIV, so why not a SPAN. That's just a silly restriction that leads to all sorts of kludges to get around it.
Joined: 10 Oct 2000 Posts: 1551 Location: Australia
Posted: Thu Sep 08, 2005 12:28 am
I've always been a fan of tables, they're like the trusty horse you can always bet on. All this new spangly dived spanned javascripted swfed aspxed stuff just doesn't sit right with me.
I don't think I have anything useful to add to the conversation, except that darker's page doesn't work if you go view -> text size -> anything other than medium.
In theory, you should break the button into 9 segments ... top left, top middle, top right, middle left, middle middle, middle right, bottom left, bottom middle, bottom right... that way it grows in both directions with text size.
Mind you, phpbb just ignores that whole view -> text size thing anyway, so if its only for the forums or some other page that you can nerf that function you should be right.
Well, if you really want bitmaps as buttons, then go with... bitmaps as buttons!
I had a long rant prepared about the invalidity of porting html4 layout hacks to xhtml+css simplicity, but I need my soapbox elsewhere today.
Use an image. Or just keep using the table. Honestly, the people coming to this site won't criticize either way, and won't be super-impressed by total use of semantically valid xhtml+css anyway. *I* would, but I'm not even 1%.
_________________ Darker
New and Improved, for your Safety.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Thu Sep 08, 2005 4:47 pm
Sorry Darker, I didn't mean to get you all upset...
I don't want to just use bitmaps as buttons because then I'd need a separate bitmap for each button, and that *would* make the page really slow to load. The beauty of the TABLE-based solution is that I just need three small bitmaps: the left (7x22), the right (7x22) and the middle slice (1x22) and I can then make any button with any text that I want.
I posted this blog entry because I was disappointed that I needed to use TABLEs for this and couldn't use pure CSS. With all of the hype about pure-CSS designs, I was surprised to find a fairly simple application that couldn't be done as far as I could tell after 4 hours of messing with it. When it came down to the simple "Height" property not being allowed for inline elements, I just got annoyed at CSS.
I posted this in hopes that someone with more experience with CSS might be able to suggest something. But I think you took it the wrong way. The way you need to look at this is that a customer has given you a requirement for how they want buttons to look on their site. As the designer you have the job to implement this feature using the technology available to you. Telling the customer they can't have a rounded button because CSS doesn't support it isn't the proper answer.
So how would you implement this kind of button for a customer? Would you create a separate bitmap image for every single button on the whole site? I doubt it. If there is a way to do it using xhtml+css, then I'd love to hear it. Or would you resort to the same table solution that I ended up with?
I don't honestly care how something is implemented as long as it works. I *prefer* the xhtml+css solutions for all of the reasons you have already mentioned...they just make a site better. But I don't care about 100% compliance either if I can't make it do what I want. And this whole rant was about the fact that the people writing these standards need to pay more attention to what customers and designers *want* rather than just playing in their little standards world high in the clouds. If there isn't a way to convert existing problems into xhtml+css solutions, then xhtml+css isn't going to get the wide adoption that is needed to make it succeed, and that would be sad.
Anyway, sorry you missed the point of this blog entry. I wasn't trying to make this personal. I normally *like* CSS, but just couldn't find a way to solve this particular problem with CSS and got annoyed, especially when the solution (allowing HEIGHT for spans) seemed so simple.
If a customer asked me for rounded-corner buttons, they'd get an explanation that it's certainly possible, but they'll be paying for extra time to create images.
I'd explain in my nicest tone of voice, that although the benefits of clean, semantically correct xhtml markup -- especially in search engine optimization that benefits their bottom line -- far outweigh those of "heavier" html4/layout-hack markup, current browsers just don't offer the exact same design possibilities in xhtml/css without resorting to images, where html4 layout hacks could accomplish the same thing without them. It's a trade-off.
In my best professional opinion, it's best to adjust design expectations to fit within the capabilities of xhtml/css. A well-planned design would take that into account from the start. Failing that option, second best is to use xhtml/css and images for buttons. It's nearly as good. Either are better than adding unnecessary markup to the page, confusing spiders that will crawl them, and being detrimental to site maintenance and performance.
:)
_________________ Darker
New and Improved, for your Safety.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Thu Sep 08, 2005 11:49 pm
Actually, with these buttons, they *do* use normal A links, so spiders will like them just fine. And the only overhead added to the page is a single download of those 3 images (left, right, middle) for a total of 371 bytes. The markup needed for the table is about the same size as you'd need for pure css.
The 371 is a negligible overhead for these buttons, and since every button uses the same images, the cached images work *very* effectively.
The only advantage of a pure CSS solution would be to avoid the overhead of how some browsers render tables, but that's about all I can think of.
I don't agree with you that the design should be changed to fit the contraints of xhtml/css. I think the standards should be changed to fit what people want to do with the web. If we stuck to your approach, we would have never evolved the standards past the original HTML 1.0 days and would never have gotten CSS. We would have just told everyone "I'm sorry, you can't do that in HTML...change your design". Instead the standards bodies have mostly recognized that the web needs to advanced beyond simple markup and they added all of the cool stuff like CSS that we now love.
All I'm saying is that the standards people need to *continue* paying attention to what people need and evolve the standards. Often times, standards groups get caught up in their own little world and forget about the real world. That's the fear I'm starting to have with some of the CSS and XHTML stuff. But the answer isn't just to change the design to fit the current standard...if everyone did that we'd loose innovation and never need to have the standards improve.
But we might just have to agree to disagree on this. I don't actually believe that the standards group has as much power as they think anyway. For example, they can claim that the B tag is going away, but nobody writing a browser or any other HTML software is ever going to get rid of the B tag and people will be using it forever I believe, regardless of what the future standard says.
Anyway, while I agree with your statement about the speed and bloat of normal HTML, it doesn't really apply in this case. The TABLE Button trick is very efficient and works extremely well. It's just not pure CSS, but maybe someone will still find a CSS trick that makes it work.
Joined: 10 Oct 2000 Posts: 793 Location: Swindon, England
Posted: Fri Sep 09, 2005 6:08 am
You can in fact do rounded buttons with CSS, or so I've read.. But it looked so horrendously complex that I haven't attempted to make sense of it yet (I'm going to leave all my prettifying to someone else I hope ;)
Are all quite interesting, but I don't know if they help you at all..
Lady C.
As an extra aside on this sort of topic.. The main bar thingy on this site (With the "About Us" "Products" "Purchase" etc dropdowns) works fine on Opera, but the text of the items shows up slightly offset from the background bar. (They're all slightly above it..)
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Fri Sep 09, 2005 12:29 pm
OK, that's just *way* cool! This is the first example I've seen for rounded corners that includes something really simple and isn't using the Mozilla-specific tags. Thanks for the link...it went into my reference favorites.
I'm curious about the Opera problem...did it just start happening last night, or has it always been a problem? Last night I simplified the markup of the top banner and menu and replaced some tables with better CSS.
If it's always been a problem then I'm not sure there is much I can do about it. The menu items are absolutely positioned, so if they don't line up with the menu bar then that means Opera isn't handling the page margins or banner sizes correctly. Since it works on both IE and Firefox, I'm more likely to blame it on Opera and maybe it's something to email them about (assuming you are using their latest version). I don't have Opera here and don't plan to get it, so I can't really test it.
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
Posted: Wed Oct 26, 2005 4:15 pm
Thanks for the suggestion! I added the padding: 0px to the main style sheet. Doesn't seem to have any adverse effect in IE or Firefox. Someone using Opera can check to see if the problem with the site menus are fixed or not.
You cannot post new entries in this Blog You cannot reply to entries in this Blog You cannot edit your posts in this Blog You cannot delete your posts in this Blog
