Now:
Before
The trick is really easy. CSS border radius can be applied in ellipsis shapes. Each corner has a vertical and a horizontal radius. So you really just have to change the vertical radius of each corner like this:
And voila, the 60% and 40% vertical radius will do the trick.
I can highly recommend this really interesting presentation from Lea Verou on border-radius. It’s 14 minutes and highly worth the time.
Also, CSS Tricks has a collection of pre-cooked css shapes for inspiration: CSS-Tricks.com:ShapesOfCSS
]]>Studying the code, it turns out this is just clever use of Google’s font api. What you essentially do is to add this to your <HEAD> element:
<!-- Google Fonts --> <link href='http://fonts.googleapis.com/css?family=Cabin Sketch:bold' rel='stylesheet' type='text/css' /> <style type="text/css" media="screen"> h1 { font-family: 'Cabin Sketch', arial, serif; } .entry-title { font-family:'Cabin Sketch'; } </style>
Now the stylesheet referenced takes care of the rest. It’s as simple as that!
The best part of this, is that it works for all modern browsers, and also for old IE versions (down to IE6).
From googles FAQ:
What browsers are supported?
The Google Web Fonts API is compatible with the following browsers:
- Google Chrome: version 4.249.4+
- Mozilla Firefox: version: 3.5+
- Apple Safari: version 3.1+
- Opera: version 10.5+
- Microsoft Internet Explorer: version 6+
Does the Google Web Fonts API work on mobile devices?
The Google Web Fonts API works reliably on the vast majority of modern mobile operating systems, including Android 2.2+ and iOS 4.2+ (iPhone, iPad, iPod). Support for earlier iOS versions is limited.
One word of caution: Think twice before adding a lot of extra bytes to your web application. You should only add assets to it if it really makes a difference for your end users!
]]>
I did a small change to express my opinion better. Changed “JavaScript should generally be avoided” to “Don’t use JavaScript for general page layout rendering”.
Here is the modified advice from the article:
Long-term findings
- Don’t use JavaScript for general page layout rendering. Think really really hard if it can be done without JavaScript. One example: Print should be done with CSS
- If there is no way around it, use standard JavaScript libraries were browser bugs, etc are hidden for the programmer
- Tables used for layout are evil. Use tables for table-based content ONLY
- HTML code is really messy and hard to maintain. Should be cleaned up to avoid similar situations in the future. Clean up nested tables, table cells with transparent gifs. Use CSS where appropriate could shave up to 50-70% of HTML footprint
- Many HTML validation errors. Code improperly nested, forgotten end-tags: Ideally, the pages should have no validation errors. It’s an achievable work worth the effort and very educational way of working with the code
Long-term benefits
In general, several benefits could be gained by raising the knowledge of HTML, CSS, Javascript, web standards, and browser issues.
- Include easier maintenance
- Lower risk of change
- Lower risk of browser incompatibilities
- Lower risk of browser crashes
Read article: Why Web Standards Matter (Case Study)
]]>(saves bandwith, but can also make it easier to identify similar colors)
grep -nE '#([0-9a-f])\1([0-9a-f])\2([0-9a-f])\3' **/*.css
output from a random project:
css/actions.css:19: color: #000000;
css/actions.css:38: color: #000000 !important;
css/actions.css:53: color: #ffffff !important;
css/admin.css:90: color: #cccccc;
css/admin.css:94: color: #aaaaaa !important;
]]>The hack makes use of converting the background-image to a list item with an image.
/* Hack, to trick the browser to print another logo
Unfortunetaly, Firefox on Windows doesn't show logo on print
— see Mozilla bug 133490 for further details */
#header {
display: list-item;
list-style-image: url(../images/logo_print.gif);
list-style-position: inside;
margin: 0 !important;
padding: 0 !important;
height: 50pt;
}
This way, you don’t have to fall back to inserting an image tag in your HTML for the logo. Instead, just have an a element that contains the corporate logo text, and nothing all.
]]>Unfortunately, the <button> element does not react to text-decoration: underline;
But according to a discussion at the CSS Creator forum, there is a way out:
I was just messing around with it and for some reason this doesn’t work:
input {text-decoration:underline;}
but this does:
input {text-decoration:underline;float:left;}
and
input{text-decoration:underline;display:block;}
and
input{text-decoration:underline;position:absolute;}
Don’t ask me… I can’t explain this one.
Interesting!
I ended up implementing it as display:inline-block;
which also works fine. Here is my final rules for styling buttons as links
]]>.clickable, button.tertiary, input.tertiary{ color: #339; text-decoration: underline; display: inline-block; /* else underline won't work */ cursor: pointer; border: none; background-color: transparent; font-size: 1em; padding: 0; } .clickable:hover, button.tertiary:hover, input.tertiary:hover{ text-decoration: underline; color: #669; }
Take a look at HTML's proportional widths and amount alignment features.
]]>Take a look at HTML’s proportional widths and amount alignment features.
Look at this from HTML specification of <COL> elements:
Authors may specify column widths in three ways:
- Fixed
- A fixed width specification is given in pixels (e.g., width=”30″). A fixed-width specification enables incremental rendering.
- Percentage
- A percentage specification (e.g., width=”20%”) is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.
- Proportional
- Proportional specifications (e.g., width=”3*”) refer to portions of the horizontal space required by a table. If the table width is given a fixed value via the width attribute of the TABLE element, user agents may render the table incrementally even with proportional columns.However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns.
Proportional widths! Nice. This means that you can create tables like this example (i have swapped the original HTML4 style to lowercase XHTML):
Once the (visual) user agent has received the table’s data: the available horizontal space will be alloted by the user agent as follows: First the user agent will allot 30 pixels to columns one and two. Then, the minimal space required for the third column will be reserved. The remaining horizontal space will be divided into six equal portions (since 2* + 1* + 3* = 6 portions). Column four (2*) will receive two of these portions, column five (1*) will receive one, and column six (3*) will receive three.
<table> <colgroup> <col width="30"/> <colgroup> <col width="30"/> <col width="0*"/> <col width="2*"/> <colgroup align="center"> <col width="1*"/> <col width="3*" align="char" char=":"/> <thead> <tr><td> ... ...rows... </table>
This leaves me with one big question: How is browser support for <col width=”2*”> ????
BONUS: Did you notice the little align feature ‘align=”char” char=”:” ‘ so that you can correctly align your decimal amounts? I was not aware of that either!
More info in W3C’s HTML4 specification “Calculating the widths of columns“
]]>The HTML guide is a really useful tool for every public authority that must deliver applications for the portal.
As a help for my own work back then, I created virk_dk_htmlsnippets:
Snippets available
skel
(tab) — creates HTML skeleton in blank file. Adds correct doctype, head, body and container divs required for the virk.dk html to show correctly.
fieldset
(tab) Groups of form elements. Use where you would have used ordinary fieldsets. See HTML guide » Form grupper (fieldsets)
button
(tab) — submit button and other buttons. See HTML guide » Knapper
inputcheck
(tab) — standard checkbox with label and group
inputtext
(tab) — text field
select
(tab) — select element
Usage examples see HTML guide Simple form elementer, Særlige form elementer
table
(tab) — table element. See HTML guide » Tabeller
td
(tab) — table cell inside table row.
th
(tab) — table header cell inside table row.
I’m releasing the snippets as open source under the LGPL license so you can freely change, and distribute. However, I encourage you to send me the changes and I’ll work the relevant changes into the snippets.
Any editor that understands Textmate snippets can be used. E-texteditor for Windows or GEdit for Unix/Linux will read the snippets as well.
Go to the project page on GitHub to download virk_dk_htmlsnippets
In general, different portals have different HTML markup. Historically, this is because of many constraints: Limitations in the chosen web framework, limitations in chosen graphical design, random naming of css classes, developer laziness, etc.
What if portals could actually use the same HTML markup for most elements? This way, subcontractors and content providers could deliver content/portlets/webparts for multiple portals.
In Denmark there are only a few major public portals: Virk.dk for businesses, and Borger.dk for citizens. But some content would actually be relevant on both portals. Sadly, the HTML markup is very different.
Imagine how the public authorities would benefit from shared HTML markup:
Next time I get to do work for that project, I would probably also create a Ruby on Rails form builder that automagically would generate the right HTML.
]]>
/* Watch out for invalid/deprecated HTML in CMS */
b{font-size: x-large; background-color: fuchsia; color: yellow; font-weight: normal;}
i{font-size: x-large; background-color: lime; color: blue; font-style: normal}
font{background-color: aqua; color: red}
b,i,font{text-decoration: blink;}
This was really useful for identifying dirty HTML that was generated from a Microsoft-based CMS.
Coloring and blinking text makes the editors aware that something is wrong. Two major advantages for this approach:
These lines may also be useful to you — unless you are able to guard your HTML before it’s inserted in your application (something that was not possible at this project).
]]>10000 to 10,000 etc.
Just add css class=”numberformat currency” to a text field, and it will be formatted automatically.
It is based on the Prototype JavaScript library. You can get it from it’s GitHub repository page. Feel free to add or alter the functionality. Releasing under Creative Commons license.
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Some quick notes:
I’m using this on a rather big HTML page, so the selection of DOM nodes must be as simple and quick as possible. So if you are considering moderations, please make sure that the DOM manipulations are as lightweight as possible.
The script is as simple as possible. It does not parse the string as a number. Instead it just strips any thousand delimiters in the string. Afterwards it sets its own. There may be some important logic here to add to make the code more robust.
I have also added a test page to the project… not a real test page, but a HTML page that shows examples that are modified. Please back up any added functionality with changes to that page as well.
Contact me for commit access if you would like to contribute. I do not expect to add any functionality to the code unless the work project requires it.
More info:
GitHub repository
Technorati Tags: javascript, opensource, project, library
]]>