by Nik Kalyani
Wednesday, March 09, 2005 3:57:40 PM (Pacific Standard Time, UTC-08:00)
How do you create a page that allows a user to select the font size?
Nik’s answer:
You can do this using CSS or Javascript or a combination of the two. Here is some sample HTML code with embedded CSS that demonstrates how it is done:
<html>
<style>
.xsmall { font-size: 0.5em; }
.medium { font-size: 1.0em; }
.large { font-size: 1.5em; }
.xlarge { font-size: 2.0em; }
.fauxLink { text-decoration: underline; cursor: hand; }
</style>
<body>
<p>This code demonstrates how to make a web page with user selectable font sizes. The trick is to use CSS with relative point sizes.</p>
<p>You can set the "font-size" CSS attribute to an "em" value. This is the value of the character box for a given font (i.e. the "M" character). Using an em value sets the font size to a relative value. For example, 1.3em is the same as 130%.</p> <p>
<span class="fauxLink" onClick="document.body.className='xsmall'">x-small</span> |
<span class="fauxLink" onClick="document.body.className='medium'">medium</span> |
<span class="fauxLink" onClick="document.body.className='large'">large</span> |
<span class="fauxLink" onClick="document.body.className='xlarge'">x-large</span>
</p>
<div>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nullam eu sem. In commodo. Integer id lectus a enim fermentum molestie. Donec fringilla ligula vel justo. Aliquam elementum wisi luctus lacus. Etiam leo. Duis auctor elit quis mauris. Ut elit lectus, luctus quis, rhoncus sed, lacinia in, velit. Pellentesque vulputate congue magna. Proin luctus. Pellentesque rhoncus, metus eget laoreet ornare, lacus risus mollis nibh, non interdum augue sapien nec metus. Donec sem. Vestibulum rutrum, urna non cursus tristique, tellus erat sagittis turpis, at venenatis massa massa egestas pede. Praesent ultrices malesuada nisl. Etiam ac felis eget ligula venenatis suscipit. Suspendisse ultricies lacus eu eros. Aliquam bibendum adipiscing ante.
</div>
</body>
</html>
As you can see, it is very easy to accomplish this. However, this is only half the solution. Presumably the user wants the size selection to persist so it’s a good idea to use a cookie to store their preference. Then, no matter which page they visit on your site, text will be displayed at their preferred size. Furthermore, when they return to your site at a later date, depending on the duration of the cookie, the site will automatically adjust the size.
For DotNetNuke, I created a component that does this for you (by allowing the user to select a stylesheet for the page and remembering it for future visits). This is part of the Speerio SkinWidgets suite. You can see a demo here.
by Nik Kalyani
Tuesday, March 08, 2005 10:36:49 PM (Pacific Standard Time, UTC-08:00)
I am working on a web app that consists of a treeview on the left and content on the right. The basic layout is a table with the height of the content determining the overall height of the table.
This basically means the treeview has to be scrollable, since it's possible that the table height is less than the tree height. Simple enough...put the treeview inside a DIV and change its "height" style attribute to 100%.
Works in IE6 but does not in FireFox. After Googling for hours and not finding a good solution, I devised a function to make this work. In my function, the params are the ID's of the main table and the DIV containing the treeview. The code first sets the height of the scrollable DIV to 0. This allows the main table to adjust to its normal height. Then the DIV's height is set to the same as the table height.
Works in IE6 and FireFox.
function setScrollerHeight(mainTableId, explorerScrollerId)
{
var mainTable = document.getElementById(mainTableId);
var scroller = document.getElementById(explorerScrollerId);
if (!scroller) return;
if (mainTable.clientHeight > 0)
{
scroller.style.height = "0px";
scroller.style.height = mainTable.clientHeight;
}
else
scroller.style.height = "500px"; }
by Nik Kalyani
Thursday, March 03, 2005 1:54:21 PM (Pacific Standard Time, UTC-08:00)
The current DotNetNuke release (3.0.11) is quite stable and I think it will not be very long before we see a Release Candidate.
This is the first release for which I have been a Core Team member from start to release and I have found the experience to be nothing short of amazing. The thing that fascinates me the most is how effective IM/Email/Forums are for team collaboration. If ~40 people, spread out all over the world in different timezones can collaborate to create such a fantastic product, it begs the question, is this a fundamentally better way to work in a global economy?
I know face time is important and that in certain businesses, it is essential. But maybe in the software industry, greater productivity gains are possible through online collaboration. And of course, savings too since you won’t need as many Aeron chairs.
Before I became a Core Team member, I always imagined that there was a lot of behind-the-scenes “bureaucracy” and structure with secrets and such. Now I know that this is far from the truth. The Core Team is really just a group of people with a shared vision, operating under some well-defined, but broad guidelines. Each person contributes to the extent her/his time and talent allows. Then thanks to a devoted few of the senior members, things magically fall into place. There are no mission statements, UML diagrams, team-building exercises and most important, no monetary compensation. Makes you wonder, doesn’t it?
by Nik Kalyani
Thursday, March 03, 2005 1:28:41 PM (Pacific Standard Time, UTC-08:00)
Das Blog has its own skinning solution which consists of “themes” defined in web.config, corresponding to theme sub-folders that contain templates. The templates are basically HTML fragments with tokens that indicate where content will reside. I have been tinkering with the templates quite a bit to make sure I understand all their capabilities as I progress in making Das Blog work with DNN.
One thing that already caught my eye is that the Das Blog skinning solution is not very granular, so skinning flexibility is limited. For instance, you can specify where a blog entry will appear in one template and in another, you can specify the layout for the item. However, there is no mechanism to control what appears between individual items or if you would like a different appearance for alternating items. Having this capability does not have much appeal in general, but there are some specific situations where I think it would be useful — displaying ads in-line, automatically displaying related items using the Technorati API etc. Now the latter is clearly not something that belongs in the skinning department, however, even if implemented in the BL, there is no mechanism to skin it differently from the blog item.
One really neat thing about DasBlog is that most of the user-facing aspx pages are just shells for user controls. This is promising because it makes the process of conversion to DNN modules that much easier. I think I should be done with my skinning analysis in another 3–4 days, at which time I will continue the code conversion.
by Nik Kalyani
Wednesday, March 02, 2005 9:56:49 PM (Pacific Standard Time, UTC-08:00)
I have had it with designing cross-browser web pages without tables.
OK, I get it. An HTML table was never intended to be used for pixel-perfect design layouts. For that matter, HTML was never intended to be used for pixel-perfect design layouts, period.
But, I have tried to go with the flow. The design gurus say, don’t use tables…use CSS. But from a productivity standpoint, that stinks. I have spent countless hours trying to get CSS-based <div> elements to do my bidding. And you know what. I am done. I will try and use CSS-based layouts when possible, but if I have to spend more than a few minutes trying to get things to position properly, I am back to using tables.
Now, I am no designer, but then I am not completely clueless about CSS either. I tell you, with the number of workarounds/hacks that you have to use to get cross-browser layouts to work using CSS only, I am surprised that people still continue to pursue this type of design. Doesn’t productivity matter more than “View source…”?
There is nothing inherently wrong with tables in HTML unless your overall page is one giant table. Then the user is going to wait until the browser can figure out how to lay the table out. For intermediate content, I don’t see how using tables is a big problem if my targeted browsers are IE and Firefox and I use them for layout of elements within the page. (Yes…I am aware that there are other browsers, but just as people have a choice of browser, I have a choice of the browsers I will support.)
I develop web applications. If my app enables the user to complete the task it was intended for quickly and easily, then as far as I am concerned, tables or no tables, my app is a success. So until all the browser developers get their act together, I am going to keep my tables.
|