The calendar should now re-flow to fit in whatever sized window you have, instead of showing a horizontal scrollbar when the window is too narrow. It also does slightly different things when the window is really narrow, e.g., iPhones.
(See how I got that left column to have a green background that goes all the way to the bottom of the event box even when it's not the tallest column? That was fucking hard.)
(See how the calendar grid at the top resizes to the width of the window, but the boxes remain square? That was also really fucking hard.)
I'm curious to know how it looks in old browsers, and on older and/or less sophisticated phones.
Some CSS questions:
- Is there any way to flow text through two equal-sized columns?
I want to present text it in a two-column format, unless the window is too narrow, in which case, one column. I've somewhat accomplished this on the tickets page, but it doesn't work great. I end up with columns of unequal height, because I have to arbitrarily select N items for the left column and M items for the right, because I don't know how much space they will occupy pre-layout.
Also, when the min-width on those columns is exceeded and they float to be stacked above each other instead of side-by-side, they do not re-flow to respect their max-width; instead they stay at their min-width, which is dumb.
Is there any better way to do this?
I've got a bunch of text, and an image floated right. When the available space is limited, and the first few words in the paragraph happen to be short, I get crap like:
All -------------------More sane wrapping would be:
work | |
and | |
no | |
tentacles makes Jack a
All work and no tentacles
makes Jack a dull boy.
The only way around this I've found is to manually make the first three or four words next to a float be non-wrappable, like: <SPAN STYLE="white-space:nowrap">All work and</SPAN>.
Is there some more sensible way?
I seem to have rounding errors in the scaling of the images on the top-level page (sometimes the images end up not being the same height), and these rounding errors appear to manifest differently in all three browsers. Ideas?
Just for laughs, I also made the calendar pages be formatted as the hCalendar microformat. This is, as far as I can tell, completely useless, but maybe it won't be some day. (The idea is that your web browser can automatically notice that there are calendar entries here. None do. But hey, they cited me as required reading, so, why not.) Questions, though, for people who understand this microformat stuff:
- I'm using empty ABBR tags (<ABBR ...></ABBR>) for dtstart, duration, and tzid instead of picking some arbitrary text to wrap it around because I don't want to see a tooltip there and there's no way to turn that tooltip off. But the validator issues a warning about that. Does it matter?
In iCalendar, I format my dates in local time and include a TZID, e.g., DTSTART;TZID=US/Pacific:20100625T210000. This works in Apple iCal. I saw an hCalendar example using <ABBR CLASS="tzid" TITLE="US-Pacific">, but I'm not sure that's actually legal. Is it?
Thank you. Drive through.
For #2 ... I think you can do something like:
- img tag
- <div style="clear: both"></div>
- rest of text
Memory's pretty hazy but I remember doing some tricks involving "clear: both" to avoid having wrapping where I didn't want it. Maybe you can apply that style directly to the img tag.
No, that will force the text to always be below the image. I only want the text to be forced below the image in the case where it won't all fit. Right now, it fits some of the text, but as soon as it hits a long word, it pushes that one below, leaving a big ugly blank space in the middle of a sentence.
You might want to look at jquery (or its source) and see how it obtains computed heights of elements. Seems like maybe you could get the height of the image, the height of the text block, and if the text turns out to be taller, you could programmatically add some css that would put the text in a fixed block below the image.
You might like to have a look at how they've implemented the columns on this mozillazine page http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html
Oh, nice. Unfortunately it seems to be a css3 thing, so maybe we can start using it in five or ten years.
Robert posts long entries sometimes, and then you can enjoy scrolling down one column, scrolling back up to the top of the second one, scrolling down again, then back up, and finally back down again.
If only computers were somehow able to work out how much text there was, and how big my screen was. But I hear the problem is intractable.
If one bumps up the text size (or, "zoom level") because they have a large highish dpi screen, then the "div class=left" box is smaller than the text, a la the CSS Is Awesome mug.
I changed the units from pxs to ems in firebug (14 or 15 ems seemed to be good), and it fixes the direct issue with the "left" div, but it breaks the overall layout -- obviously there is some other tacit assumption about the width of that column.
Thanks, I think I fixed it. Try again? I was trying to keep that column measured in pixels to keep its size in sync with the small logo image at the top, but I guess that's not going to work, and I have to measure the image in ems too.
It lays out fine now, but the logo image doesn't look great when scaled up.
This may just be something that is unfixable by its nature:
With scaled up text size in Firefox on the calendar, the text in the calendar grid is too large and gets cropped away (the larger the scaling, the less the text is visible). Growing/shrinking the window horizontally autosizes the grid and autosizes the font in the grid, so it's always consistently cropped off no matter how much space you make for it. Only reducing the text scale fixes it.
OK, I'll check back again in a couple of years to see if HTML/CSS text layout has caught up with my copy of Quark XPress from 1995.
Issue #2 hasn't caught up with damn TeX from 1978.
(On the "older browsers" front, I may be able to throw it at IE6 later. Everything seems to collapse very nicely in an unnecesarily narrow Opera 10.54/OSX.)
The CSS questions you're asking these days are css-discuss material. There are only a handful of people who are qualified to answer and who will have thought of things you haven't, and most of them are on that list. You have to join to post, and you probably don't want to stay subscribed for long, because firehose. Nevertheless, that's what I would do if I were really interested in finding out the answer. If, on the other hand, I were mostly interested in saying caustic things about CSS, I'd stay away.
captcha: "its disport"
On my Dream in portrait mode, the nav on the calendar partially obscures the text of the day names, so it renders as
If I were you, I wouldn't care enough to change it, but, you know, FYI.
Aside from that, it looks great. I love watching the logo resize when I go from portrait to landscape, it's like living in the future or some shit.
dammit I knew lj's preview rendering was too good to be true
<<n Mon Tue Wed Thu Fri S>>
The frontpage is one-column below the other.
The calendar layout is likewise quite broken, but still usable.
The tickets page is not.
Well, that's annoying.
I don't suppose you have any insight into what's going wrong there?
Not really, I'm afraid. I do seem to remember that IE6 is completely ignorant of min- and max- versions of width and height, and I see those in use, but I haven't had to deal with this nonsense in a while.
If only it were completely ignorant. In IE6, width does what min-width should do, ie an object with a width is only guaranteed to be no thinner than you ask it to be, not to actually avoid being fatter as well. And yet, IE6 is so much better than everything that came before it, ie everything written in the 20th century. And worse than nearly everything after it that wasn't written for a phone.
I would consult your access logs before worrying about IE6 too much. Depending on your clientele it might be about as useful as supporting webtv.
For the two-columns thing, I think the CSS3 columns approach is your best bet. the "pick N for the first to match M on the second" problem is not really in the HTML rendering model, which is why it requires JS measurements to work around otherwise.
It believe it works in all browsers but IE (you likely have to repeat the CSS attributes a few times but they're brief), and since it gracefully degrades to a single column there it isn't so bad.
http://caniuse.com/#feat=multicolumn ...huh, not Opera either I guess. (That will likely irritate internet people but not anyone who would go to a club.)
Just stumbled across the Opera Mobile emulator/Mini simulators, if you were unaware of them and lack suitable old phones. Former supposedly runs on OS X.
Hey, that's handy, thanks!
With images floated right you might want to use good ol' tag. Just wrap few first words of your text in it: All work and no tentacles makes Jack a dull boy. All tentacles and no work makes Jack a mere toy. In this example, text will float to the left of the image only if the windows is wide enough to put "All work and no tentacles" on one line.