Notice: This is a discussion thread for comments about the SitePoint article, Drop Cap: The Next Generation.
Do you think CSS adequately provides all the typographical sophistication you require? Would you go to these lengths?
I figure you would have to create/measure slices for each character (A-Z, 1-0) - (at the letter ‘T’ you will get the hang of it :-)), naming them p>.s1a, p>.s2a etc. Depending on the surrounding font-size, you would need to create 720 (20 * 36) slices (although in examples it seems max. 10 slices would do).
However, there should be a simpler way to apply it within HTML: <span class=“slice” id=“s1a”></span> - times 10 lines (or 20) seems unpractical - one should be able to call the letter only once - with some wildcard perhaps: <span class=“slice” id=“s*a”></span> (this would call all slices for the letter ‘a’, regardless of how many are defined).
It definitely looks much better than straight letter-block, but it comes with some extra work (what’s new?), but worth it for those sites/clients that really want to stand out.
IE DID get it right. From my point of view, IE is the only browser that treats px values correctly.
As in how do you change the size of one px metric element without changing all of them?
I think that’s what I like about the new zoom approach everyone else is adopting… you know the one Opera STARTED and still does better than anyone else? If you are going to resize one px metric element like the size of a font, resize EVERYTHING so you don’t break the bloody thing - it’s why we declared stuff in PX in the first place. If we wanted to allow it to be independently resized we’d have used pt or %/em.
But because developers were too lazy to learn the difference, nyetscape and it’s followers went and ignored what each metric is for…
Opera’s implementation had less bugs than IE7 and FF had when they both first came out with zoom. I suppose Opera’s had more practice.
Another of the handful of reasons I don’t default to Opera as my browser; I like true text enlarge as well.
You aren’t one of those “fluoridated water ate my baby!” guys are you? : D I owe my 30 years of no cavities to that poison!
Why do they do it better than anyone else?
They don’t even give the OPTION to “zoom text only” like FF and Safari does. I don’t always want to zoom the entire site or the images in the html. Some times I just want to bump the text up a notch without getting horizontal scrollbars on the site.
No problem, I can understand that any work is important, even if only to the one doing it (which is not the case here). Everything has a starting point, and you have been advancing us further by sparing us to start from zip.
Your approach is gravitating around drop cap. Empty spans are definitely a smart choice. One can even throw in JS with geometrical rules to make it more sound.
Mine, on the other hand, revolves around text lines. Is a bit of an overdressed one. But I’ll see where it goes. How efficient will it be, it’s still early to tell.
About the other stuff. I didn’t say you need to use a px value for the body. There is a formula for making the transition from the default font size of UAs expressed in px, to em: like 10px is 0.625em or 62.5%. And I’m saying you need to establish this base on an even value, like 10px, 12px, etc for my correlated drop cap to work.
Also, I was pushing for a class for that paragraph, not for a complicated selector. Just a thought. When it all fails, make it simple again.
Okay I see what you’re doing - do you think that’s a better approach than using empty spans?
See, the thing with using empty elements is that they can slide and scale across each other - text resizing and window resizing are all built-in for free. With your approach, aren’t you having to forcibly restrict the size of each line, which you then have to re-compute to implement window scaling?
Beautiful quality art is worth something.
Art of a poor quality is poor.
Yeah maybe I over-reacted there a bit - the bulk of the comments in this thread have put me on the defensive, and I kinda forgot that you’re one person who’s actually being constructive in all of this!
Anyway - I actually fixed the drop-cap on SitePoint Blogs. The problem was that I wrote it for a content specification that went “container > ad + first-para”, but the syntax highlighting plugin has kicked in since then, and it puts its scripts between the ad and the paragraph - so any post with code blocks would break the selector.
That’s what I mean when I say the content is unknown - the node relationship that you assume simply can’t be assumed. And removing the script is beyond the control of the CSS author. (And setting the body font-size in pixels is not an option either - remember IE6?)
To fix it I’ve had to use :first-of-type, which means it doens’t work in IE8 anymore:
#post-content > p:first-of-type:first-letter
{
letter-spacing:0;
text-transform:uppercase;
color:#628fbe;
font-family:times,serif;
font-size:3.5em;
float:left;
margin:0.13em 0.2em 0 0;
line-height:0.7;
}
But it’s totally better than using a wrapper element. That’s simply not an option here - we can’t ask every blog author to wrap their first letter in the right element, people would just forget.
Let me take a look at your other stuff now …
Javascript is still on development but you can get an idea of what it’s supposed to look like. It even supports browser window resize for the slicing of <p>. Still, I’m not stoping here.
There is a formula for making the transition from the default font size of UAs expressed in px, to em: like 10px is 0.625em or 62.5%.
Even though you’re not using that formula, forget it anyway. It only works if the user’s browser’s default is 16px… which none of mine really are simply because I use the Gnome desktop (makes text larger). Someone like Ed Seedhouse or Deathshadow would have some equivalent of 20px default.
OK. The next step: text wrapping.
After depending the font size of the drop cap on the line height of the paragraph, next step is the division of our paragraph into text spans equal to the number of lines it extends.
I’ve provided an initial example here, but the work is one in progress.
SP is correct, that whole 62.5% nonsense only works if the end user is set to 96dpi, otherwise it’s bull. My media center is set to 192dpi turning the default windblows UI into a ten foot interface - my workstation is set to large fonts/120dpi so my default size is 20px not 16px, and I’ve got HTC handheld here that defaults to 72dpi due to the small screen size.
Which takes things like that px to em conversion site and flushes the very NOTION of it down the crapper - hell, that’s what %/EM is FOR - to adjust to the system metric while px does not (and why I still say old school nyetscape style text resizing is actually incorrect and IE got it right!)
I have a page that’s still a bit WIP that shows that - scroll down to the side-by-side comparison of the same font sizes sent to four different settings to see what I mean.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html
Just out of curiosity:
Are there any modern (2009 - 2010) web sites that actually use drop caps? Really? So are there any good examples in which drop caps would make us go, “Aaaaahhhh!”?
Just wondering. Thanks.
I’m on a quest just for that. First step outlined by these examples was this scaling factor correlation that needs to be done between drop cap/graphic and the line height of rest of the content. And I’ve improved (says me) the classic drop cap making it scalable in a very easy way to what number of lines one wishes.
first-letter has a few drawbacks which I’ve pointed out in my examples.It’s not only a question of understanding, but there is one of displaying, even when browser supports it. This problem disappears when using instead a wrapping element for the first letter.
Only if you’re starting from the presumption that a pixel is a square dot. It isn’t - it’s just an analogy of a square dot, and there’s nothing to say that its sizing should be immutable, rather than flexible as it is in other implementations.
But I don’t think that’s really the point anyway. Browsers resize pixel fonts because, if they didn’t, a huge junk of all the world’s websites would be less accessible. It’s a bit like flouridating water I suppose 
You may have a point there, so here’s what I come up with so far.
I’m building up from the premise: scale factor between drop cap’s font size and the paragraph’s line height.
I guess you’re not reading SP’s articles?
See there, a drop cap! 
Anyway, the drop cap it’s just the beginning, as the final goal set by James Edwards it’s a more ambitious one.
The next thing I’m going to try is to build a look-up table of proportions for each of the caps from A-Z in a given serif font (probably times, since it’s the most common default), and then see if that can leverage a workable scripted implementation.
All of the other stuff - the wrapper span and the slices - can be script generated - it’s just a case of working out a set of numbers that’s portable and size-agnostic, which doesn’t break down in situ!