YUI Fonts CSS Discussion Thread (MOVED) [Sitemap] - Digital Grin Photography Forum

View Full Version : YUI Fonts CSS Discussion Thread (MOVED)

iamback

Jun-10-2007, 11:05 AM

MOD EDIT: This discussion has gotten waaaay off the original topic so I moved the thread. It starts a bit abruptly, but you'll have a lot to read soon if you're following along at home :wink

Really? Don't you think you're being a wee smidge picky?I don't think so: if there's suddenly a line-height definition - especially one that is applied to all body elements - that wasn't there before, it could play havoc with all sorts of user-defined positioning, leading to too-tightly spaced or even overlapping text. Leading to a page with decreased usability for visitors.

That said, I always preach that it's best to be specific, in this case because different browsers use different line heights in their internal style sheets. In that sense, adding a line-height definition that wasn't there before is a good move.

For SmugMug users, if you're doing any kind of positioning, it's best to be specific as well and 'defend' against changes like this.

Or, rather than setting the line height to a specific value, use body * {line-height: normal !important;} to force it back to the original CSS default value - that will cause all browsers to use their own internal values again.

Mike Lane

Jun-10-2007, 12:28 PM

I don't think so: if there's suddenly a line-height definition - especially one that is applied to all body elements - that wasn't there before, it could play havoc with all sorts of user-defined positioning, leading to too-tightly spaced or even overlapping text. Leading to a page with decreased usability for visitors.:nah I do agree that the definition is overly generalized. But a line height of 1.22em won't cause any lines to overlap certainly and will be only slightly more than the standard line height in the vast majority (if not all) cases. Furthermore, since it is so general, it is easily overwritten and any cases where the user has specified something other than 1.22em for line height they will see no change.

And in Brando's case the line height was less than 1/100th em different. That is being waaaaay too picky. I hope brando is out shooting pictures or perfecting his photoshop skills instead of dealing with this.

That said, I always preach that it's best to be specific, in this case because different browsers use different line heights in their internal style sheets. In that sense, adding a line-height definition that wasn't there before is a good move.Start general then go specific after that. You are right, different browsers do different things with line heights and margins and such so a global white space reset is a good idea. Here's the best global white space reset I've come across yet: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/

But having said that, your average visitor is not going to bounce from firefox to safari to internet explorer to flock to sunrise to opera just to see if they can find a place where your line height is less than 1/100th larger in one browser than another. Trying to make it so by adding specific CSS will lead 1) to crazy code and 2) to a crazy designer.

For SmugMug users, if you're doing any kind of positioning, it's best to be specific as well and 'defend' against changes like this.

Or, rather than setting the line height to a specific value, use body * {line-height: normal !important;} to force it back to the original CSS default value - that will cause all browsers to use their own internal values again.The important tag isn't required here. Don't forget that CSS that comes later in the source will have a higher specificity than CSS that comes before it. So just by putting body * {line-height:normal} in the user CSS you can override the CSS in the fonts.css file.

That said, for the vast majority of smuggers out there, adding the normal line-height won't be necessary. If you're keen to use the white space reset, either the one I linked or a different one, then good on ya. Otherwise, don't bother with it. Your paragraphs aren't going to collapse onto one another or be so spread out that you have to scroll your page from line to line. You may, like Brando, see things open up a tiny bit. But in the long run, this is far from that big of a deal.

EDIT:I just now figured out that what was added was the YUI Fonts CSS (among other things). You can read more about it here: http://developer.yahoo.com/yui/fonts/. This is good news as it will allow you to adjust your fonts on your site much more easily.

iamback

Jun-11-2007, 02:30 AM

:nah I do agree that the definition is overly generalized. But a line height of 1.22em won't cause any lines to overlap certainly and will be only slightly more than the standard line height in the vast majority (if not all) cases.Overlaps can cut-offs can still happen, especially if it's "slightly larger than normal". If text is sitting in pixel-sized boxes, the proportions will end up different. A single pixel in line height can add up to a few pixels for a multi-line paragraph. Don't forget that browsers need to interpolate - they cannot display 1/100th of an em - but that difference may result in an extra pixel, one for each line.

But having said that, your average visitor is not going to bounce from firefox to safari to internet explorer to flock to sunrise to opera just to see if they can find a place where your line height is less than 1/100th larger in one browser than another.No one can see 100th of an em, because browsers don't do that. But they can see the pixel differences that browsers come up with in their calculations if they add up and result in cut-off or overlapping text. Even image layouts can suffer because images are inline content and thus subject to line-height.

By "be specific" I mean not a lot of numbers behind the decimal point, but specifying sizes, paddings, and margins, so you're not dependent on the browser's internal stylesheets which you don't know.

The important tag isn't required here. Don't forget that CSS that comes later in the source will have a higher specificity than CSS that comes before it. So just by putting body * {line-height:normal} in the user CSS you can override the CSS in the fonts.css file.That may be the case now, but it's defensive programming; if the next change in SM's stylesheet uses 'body div *' instead of 'body *' your !important rule still has a chance of overriding it, without that, the new SM rule is the most specific. But browsers can be a bit inconsistent in how they interpret !important rules, and * selectors...

Mike Lane

Jun-11-2007, 03:00 AM

Overlaps can cut-offs can still happen, especially if it's "slightly larger than normal". If text is sitting in pixel-sized boxes, the proportions will end up different. A single pixel in line height can add up to a few pixels for a multi-line paragraph. Don't forget that browsers need to interpolate - they cannot display 1/100th of an em - but that difference may result in an extra pixel, one for each line.For standard body copy (which is what brando is asking about), setting the line height to slightly larger than normal will not cause any problems. In fact the only person that is likely to be able to tell a difference will be brando. Thus my point continues to be that he is being picky. Have you even taken the time to check the page that he was having a problem with? Did you note the minute difference with and without that code?

Also the YUI font css code has more to it than just that one line. Take alook for yourself :deal Also check out the yui font css help page.

If anyone has overlapping text because they are in the exceedingly rare case of using 2 or more inline boxes with heights and padding and margins are less than 1.22 em, I'll happily show them how to fix that.

No one can see 100th of an em, because browsers don't do that. But they can see the pixel differences that browsers come up with in their calculations if they add up and result in cut-off or overlapping text. Even image layouts can suffer because images are inline content and thus subject to line-height.

Now that depends on the user's and the viewer's defined text size. Layouts can change; however, I challenge you to find a single example of a smugmug page where they do. :deal

By "be specific" I mean not a lot of numbers behind the decimal point, but specifying sizes, paddings, and margins, so you're not dependent on the browser's internal stylesheets which you don't know.

Oh I know what you mean. My point is that is bad css coding practice.

That may be the case now, but it's defensive programming; if the next change in SM's stylesheet uses 'body div *' instead of 'body *' your !important rule still has a chance of overriding it, without that, the new SM rule is the most specific.:lol3 @ defensive programming. :lol3 @ pixel pickiness in general.

iamback

Jun-11-2007, 03:38 AM

Also the YUI font css code has more to it than just that one line. Take alook for yourself :deal Also check out the yui font css help page.I did. Can you tell me just how that makes it easier to customize things in SM?

Oh I know what you mean. My point is that is bad css coding practice.Sorry, we'll have to agree to disagree on that. Being specific to avoid unknown browser's internal stylesheet settings is good CSS coding practice, IMO. (And I'm not alone in that.)

:lol3 @ defensive programming.Laugh all you like, defensive coding has been good practice for tens of years. But maybe the concept is new to you? :wink

:lol3 @ pixel pickiness in general.That can't be directed at me or you're still misunderstanding what I mean by "be specific" - I advocate the very opposite of "pixel pickiness", in fact: I advocate fluid layouts that use ems for sizing wherever possible so they scale with the visitor's font size preferences. But that doesn't exclude being specific by defining sizes, paddings and margins instead of leaving them to browsers' internal stylesheets.

Mike Lane

Jun-11-2007, 04:50 AM

I did. Can you tell me just how that makes it easier to customize things in SM?

From the yui site:

Offers full A-grade browser (http://developer.yahoo.com/yui/articles/gbs/gbs.html) support.
Provides consistent font sizing and line-height.
Provides appropriate cross-OS font-family degradation paths.
Supports user-driven font-size adjustment in the browser, including cross-browser consistency for adjusted sizes.
Works in both "Quirks Mode" and "Standards Mode."No more futzing w/ fonts to get cross-browser support = easier. :thumb

Sorry, we'll have to agree to disagree on that. Being specific to avoid unknown browser's internal stylesheet settings is good CSS coding practice, IMO. (And I'm not alone in that.)I suppose we will have to disagree. Fighting tooth and nail to get a page to look the same in every browser known and unknown is silly IMO.

Laugh all you like, defensive coding has been good practice for tens of years. But maybe the concept is new to you? :winkNot new, just rather pointless. Follow a consistent design style, code from genral to specific, and focus on standards complient browsers first and then tackle the rest once you're done. Maybe my defense is simply a good offense :wink

That can't be directed at me or you're still misunderstanding what I mean by "be specific" - I advocate the very opposite of "pixel pickiness", in fact: I advocate fluid layouts that use ems for sizing wherever possible so they scale with the visitor's font size preferences.Excellent! Then you'll love the YUI fonts file :thumb

But that doesn't exclude being specific by defining sizes, paddings and margins instead of leaving them to browsers' internal stylesheets.Which is exactly what I said to do when I mentioned the white space reset earlier on. That is different than attempting to "defend" against every possible change that SM may or may not make at some point in the future.

{JT}

Jun-11-2007, 07:31 AM

Ok, for those of you following this thread there are a few things you should know. We will be sticking with the current YUI fonts css file, as well as adding a few more.

This makes developing for the site using YUI lots easier, and provides a more consistent look and feel throughout the site.

We will be adding YUI's reset and grids CSS files next, but this will be part of our next beta test, it will not be happening over night and you will get plenty of notice so you can ensure your customizations work.

The reset.css file will create a level playing field for all browsers. Margins, padding, fonts, line height - eveyrthing should look as close to the same in each browser (this is a good thing).

Again - we won't spring this on you overnight, you will have plenty of notice to use the beta server to preview things.

I am sorry for any problems the fonts.css file has given anyone, if any of you need help with adjusting for the new code - please let me know and I can provide assistance.

iamback

Jun-11-2007, 12:32 PM

brandofamily

Jun-11-2007, 12:47 PM

iamback

Jun-11-2007, 01:02 PM

Last one... will the adjustments make IE6/7 look more like the current FF, or IE6/7 look like FF?I would fervently hope the former, since FF is far more standards-compliant than even IE7 (which for designers is just an added headache, not a solution).

I design with FF and/or Mozilla (Seamonkey or recent Netscape would do as well, they use basically the same layout engine); then make whatever small adjustments are needed for IE5-IE7. (I check with other browsers, too, notably Opera, which often needs similar adjustments to those of IE5/6 because it's trying to be mostly bug-compatible with those browsers...) But I don't try to be pixel-perfect - just no obvious problems like overlapping text, list bullets that should be hidden, and the like.

iamback

Jun-11-2007, 01:18 PM

Ok, for those of you following this thread there are a few things you should know. We will be sticking with the current YUI fonts css file, as well as adding a few more.

This makes developing for the site using YUI lots easier, and provides a more consistent look and feel throughout the site.Great. This looks like an excellent move to me! I'm still relatively new here but I'm already getting the distinct impression from this forum and looking at source code that a lot of people's customizations are actually workarounds. More consistency will reduce the need for workarounds - but at the same time the transition can be painful.

We will be adding YUI's reset and grids CSS files next, (...)

The reset.css file will create a level playing field for all browsers. Margins, padding, fonts, line height - eveyrthing should look as close to the same in each browser (this is a good thing).Heh, it sounds like reset.css is doing what I mean by "be specific" (though possibly more as well)! :wink I should have a look at that sometime.

iamback

Jun-12-2007, 05:52 PM

From the yui site:

Offers full A-grade browser (http://developer.yahoo.com/yui/articles/gbs/gbs.html) support.
Provides consistent font sizing and line-height.
Provides appropriate cross-OS font-family degradation paths.
Supports user-driven font-size adjustment in the browser, including cross-browser consistency for adjusted sizes.
Works in both "Quirks Mode" and "Standards Mode."No more futzing w/ fonts to get cross-browser support = easier. :thumbWell, well... I just had a look at the actual font.css code. The above claims are interesting, but it is not true that this stylesheet "Supports user-driven font-size adjustment in the browser". It does the exact opposite in fact: it completely ignores the user's font size preference set in the browser and blandly overrides that by setting the font size on the body element (and indirectly for tables) to 13px. <shudder/>

That is sooo rude! If people want a large font size, because maybe their eyesight isn't perfect, then they'll already have told the browser to display fonts larger, please! This stylesheet completely ignores that by using not a relative size but an absolute size in pixels. And if they happen to be using Internet Explorer, and have already set the font size to "largest", they won't be able to increase it any further to get it back to a legible size.

So.... I override that by setting font size to 100% on the body tag (standard good practice since that is exactly the user's preferred size as set in the browser) - and I immediately see bits of text that were the same size end up being quite different sizes, revealing that quite an amount of "futzing" is already going on in the provided stylesheets, which will need a lot of extra "futzing" with overrides to get things back to normal.

Did someone say I was going to love font.css? <shudder again/> It's rude! Rude is bad. I don't love rude.

So I think I'll have to build my own pages and just embed images from SmugMug. And that means I won't be able to have keyword browsing, since the API does not support keywords at all. Sigh... :pissed

(OT: So why am I still here? Guess what - the alternatives are no better. Zenfolio's API shows promise but the HTML they generate is absolutely horrible. And Flickr's API looks extensive until you look closely; then it looks braindead. Did I miss something?)

Mike Lane

Jun-13-2007, 01:48 AM

Well, well... I just had a look at the actual font.css code. The above claims are interesting, but it is not true that this stylesheet "Supports user-driven font-size adjustment in the browser". It does the exact opposite in fact: it completely ignores the user's font size preference set in the browser and blandly overrides that by setting the font size on the body element (and indirectly for tables) to 13px. <shudder/>Whoa slow down there. Take a deep breath. The 13px is merely a starting point. It's there to unify the browsers. Take a look at http://developer.yahoo.com/yui/examples/fonts/example_default.html in any browser you happen to have. That is the yui example page and they use the exact same code (obviously). Feel free to set your browser's text size to whatever, see how everything changes accordingly.

That is sooo rude! If people want a large font size, because maybe their eyesight isn't perfect, then they'll already have told the browser to display fonts larger, please! This stylesheet completely ignores that by using not a relative size but an absolute size in pixels. And if they happen to be using Internet Explorer, and have already set the font size to "largest", they won't be able to increase it any further to get it back to a legible size.Right well you as the designer can easily override that with the guidelines that the YUI folks have provided:

From the YUI help page: To change the size of a font, use a percentage value from the chart (http://developer.yahoo.com/yui/fonts/#chart) below. Always use percentages as the units because they render more consistently than ems, and because unlike pixels they allow user-initiated resizing. See the example (http://developer.yahoo.com/yui/examples/fonts/example_fontsize.html).
You should probably read all of that page :deal They, in fact, have not forced any font sizes on anyone. The 13px looks to be a reasonable starting point that will give you the chance to easily go a bit smaller and much larger by using percent values for the font sizes for various elements. So your paragraphs could have a font size equivalent to 16px by setting p {font-size:122%;} and then say you want your h1 to be the equivalent of 20 pixels high you'd set h1 {font-size:152%;}. This would of course be in browsers that have their text size set as default (or medium in IE). If the user has something larger set, or in IE if they have larger or largest set, the fonts will adjust accordingly. No futzing to make it work just right, like I said. And you'll see with the grid CSS file that JT was talking about that the layouts will adjust along with the fonts too. For one second, just trust that I kind of know what I'm talking about and that someday soon layouts on SmugMug will be an absolute breeze because of the YUI files.

So.... I override that by setting font size to 100% on the body tag (standard good practice since that is exactly the user's preferred size as set in the browser) - and I immediately see bits of text that were the same size end up being quite different sizes, revealing that quite an amount of "futzing" is already going on in the provided stylesheets, which will need a lot of extra "futzing" with overrides to get things back to normal.This won't be a great solution for you. That will make the fonts not act like they should (which is what you are seeing) because they are relying on the 13px. Instead of doing it this way, set the fonts (in percents according to the chart) for individual elements. It works, I promise.

Did someone say I was going to love font.css? <shudder again/> It's rude! Rude is bad. I don't love rude.You will if you take some time to understand it. You obviously have the know-how, now you just need to take a good long look at it to really understand what it is doing.

So I think I'll have to build my own pages and just embed images from SmugMug. And that means I won't be able to have keyword browsing, since the API does not support keywords at all. Sigh... :pissed
Suit yourself, but if you do you'll find that one of the easiest ways to do it will be to incorporate the YUI files :lol3

Seriously, take some time to understand what's going on with the YUI files before you go on a rage about them. :deal

iamback

Jun-13-2007, 04:34 AM

Whoa slow down there. Take a deep breath. The 13px is merely a starting point. It's there to unify the browsers.But that is the problem! There is no need to "unify" the browsers (that is pixel nitpicking!!!); just accept what the user has already set as her comfortable font size in her browser. Overriding that is rude and I want no part of that. I never, ever define font sizes in pixels for that very reason; besides, they don't scale in older IE browsers at all. Using pixels for font sizes is simply very bad practice: it's not accessible either.

You get plenty of styling unification by setting the font size at 100% for the body element (and table if necessary), and then use only % or ems from then on. That will look legible for everyone in their own browser. And besides, 13px is a lot smaller than browser default font sizes - which gives the IE user much less space to maneuver in to get to a legible size: it makes a lot of difference if you start from the browser default font size and then scale up to "largest" or if you start from the much smaller 13px and then scale up to "largest". IE has only so many steps, so two steps larger than 13px will be smaller than two steps larger than the default font size. For other browsers, it will take extra enlarging steps to get back to normal.

That's why the 13px is rude.
It's not "merely" a starting point, it's a bad starting point, but one that is easily corrected.

Still, if your template were designed with the YUI stylesheets and scalability in mind, it should not occur that simply choosing 100% instead of 13px on the body element would suddenly make text that had the same size different in size.

If I start with with a body font size of 100% instead of 13px, and change nothing else, I should simply end up with a larger font size overall. That isn't happening.

Take a look at http://developer.yahoo.com/yui/examples/fonts/example_default.html in any browser you happen to have. That is the yui example page and they use the exact same code (obviously). Feel free to set your browser's text size to whatever, see how everything changes accordingly.Yeah, it scales - clever. But the problem is as outlined above: it starts way too small and ignores the user's default font size.

Right well you as the designer can easily override that with the guidelines that the YUI folks have provided:
From the YUI help page:
To change the size of a font, use a percentage value from the chart below. Always use percentages as the units because they render more consistently than emsThat depends. And ems are designed for font sizing, though percentages are OK for scaling; in most cases they are exactly equivalent, too.
and because unlike pixels they allow user-initiated resizing. See the example.Exactly. So don't even start with pixels: respect the user.

They, in fact, have not forced any font sizes on anyone. The 13px looks to be a reasonable starting point that will give you the chance to easily go a bit smaller and much larger by using percent values for the font sizes for various elements.No, it's not reasonable at all, because it ignores the user's wishes and limits the maximum font size attainable in IE unnecessarily. They do force an initial font size and - in IE - a maximum font size on the user. But merely setting the initial font size to 100% should remedy that.

So your paragraphs could have a font size equivalent to 16px by setting p {font-size:122%;} and then say you want your h1 to be the equivalent of 20 pixels high you'd set h1 {font-size:152%;}.I don't care what a "pixel equivalent" is because I'm not a pixel nitpicker. I do care what the user's font size preference is and I can scale that exactly the same with those percentages. Pixels don't come into it.

If the user has something larger set, or in IE if they have larger or largest set, the fonts will adjust accordingly.No, they can't get back to their actual largest size because the starting point is much smaller.

No futzing to make it work just right, like I said.No difference for that with 100% - if the styling is done right. Obviously it isn't because things that were equal in size with 13px suddenly have different sizes with 100%. And I only changed the body font size, the starting point, nothing else. Futzing will be needed to get all fonts to scale the same.

For one second, just trust that I kind of know what I'm talking about Meanwhile you could try trusting that I know what I'm talking about, too. I'm a web developer; I develop with web standards, including accessibility standards. And I've been a member of one of the W3C's WAI working groups. Believe me, there's a good reason I start with 100% which respects the user's setting, and not an arbitrary pixel size that overrides the user's setting.

This won't be a great solution for you. That will make the fonts not act like they should (which is what you are seeing) because they are relying on the 13px.Merely changing 13px to 100% for the base font size should be a great solution for me. Which is all I did.

But it's obvious you are relying on the 13px as an absolute size, and not as a "starting point" for scalability. Which causes the need for extra adjustments that should not be necessary. Which is not a great solution at all.

Instead of doing it this way, set the fonts (in percents according to the chart) for individual elements. It works, I promise.I'm not setting font sizes for any individual elements. You are. I merely changed the 13px to 100% on the body element. Try it and see. Look at my site. Look at my stylesheet.

You will if you take some time to understand it. You obviously have the know-how, now you just need to take a good long look at it to really understand what it is doing.I did take plenty of time to understand what's going on. I understand exactly what the difference is between 13px as a starting point and 100% as a starting point. I also understand quite well that if all font sizes were actually using that starting point and scaled with percentages (or ems) there would not suddenly be size differences with a 100% starting point where they didn't occur before with a 13px starting point.

Suit yourself, but if you do you'll find that one of the easiest ways to do it will be to incorporate the YUI files :lol3And then merely override the 13px with 100% to be polite to the user - yes, that should be easy.

But currently I also have to make sure all font sizes are scaled, not set to pixel sizes. But that's not easy, because I will need to go through your stylesheet with a fine-toothed comb to find all the elements where you are setting font sizes and line heights in pixels (and you are). (I can see you're using pixel sizes, because some text doesn't scale in IE.) Just changing the 13px to 100% should be enough. It isn't now.

Once you actually scale all fonts, that single small change would be enough and I would not need any futzing to override the inconsistencies in your stylesheet.

If you want to implement YUI font.css, fine. But then implement it consistently and don't set fonts in pixel sizes. Scale. Follow the YUI guidelines yourself. You're not doing that now. You're using pixel font sizes and pixel line heights all over the place. That's what is making it harder instead of easier.

Mike Lane

Jun-13-2007, 05:56 AM

But that is the problem! There is no need to "unify" the browsers (that is pixel nitpicking!!!); just accept what the user has already set as her comfortable font size in her browser. Overriding that is rude and I want no part of that. I never, ever define font sizes in pixels for that very reason; besides, they don't scale in older IE browsers at all. Using pixels for font sizes is simply very bad practice: it's not accessible either.I think you're misunderstanding here. It is unifying the browsers at the default or medium setting. It is NOT telling the browsers to display 13px font size irrespective of the user's desired font size. Please, please, please try the examples on the YUI pages to see what I mean.

You get plenty of styling unification by setting the font size at 100% for the body element (and table if necessary), and then use only % or ems from then on. That will look legible for everyone in their own browser. And besides, 13px is a lot smaller than browser default font sizes - which gives the IE user much less space to maneuver in to get to a legible size: it makes a lot of difference if you start from the browser default font size and then scale up to "largest" or if you start from the much smaller 13px and then scale up to "largest". IE has only so many steps, so two steps larger than 13px will be smaller than two steps larger than the default font size. For other browsers, it will take extra enlarging steps to get back to normal.Yes, using 100% for the body tag is one way to do things. You can set this percentage and then futz around with some other settings and end up with a few days down the drain trying to get what you want. Or, you can take the work that Yahoo! has done and just plop it right in your browser. Believe me, it works how you want it to work, the 13px size is absolutely unimportant here. It's a starting point, nothing more. The idea is that you will define the font sizes how you want them on an element by element basis using percents. Please read what I'm saying. Your pages wil not have to have anything to do with 13px if you define sizes for your elements based on the chart in the YUI page.

That's why the 13px is rude.
It's not "merely" a starting point, it's a bad starting point, but one that is easily corrected.I'm sorry, you're just not getting the point. The idea is that the YUI fonts css is based on the 13px and it gives you the total flexibility to set the font size for all other elements in your page. And then when you set the font sizes you want (again, using percent values from the YUI chart) your users will be able to see the fonts and they will be perfectly scalable in all browsers. It is NOT saying that every font starts at 13 px and the browsers do what they can.

Still, if your template were designed with the YUI stylesheets and scalability in mind, it should not occur that simply choosing 100% instead of 13px on the body element would suddenly make text that had the same size different in size.Yes, yes it would. The problem is that if you override the font size for the body tag from 13px to anything else it will break the rest of the coding in the YUI fonts css file. In reality it is the YUI fonts CSS file that is the most dependant on this 13px value. It is why the line height is set to 1.22 em globally (which you should also NOT change). Please, please, please, look at the rest of the YUI fonts css file to see what other declarations are in there and why.

If I start with with a body font size of 100% instead of 13px, and change nothing else, I should simply end up with a larger font size overall. That isn't happening.Yes but ONLY if you are not breaking the YUI fonts css file. If you put a font size of 100% in your css you WILL break the rest of the YUI font css and therefore you will see odd things happen. You have verified this.

Yeah, it scales - clever. But the problem is as outlined above: it starts way too small and ignores the user's default font size.The starting point is there for a reason and is designed to be overridden. And I don't know how I can emphasize this for you enough. It absolutely does not, in any way, at all ignore the user's desired font sizes. In fact what it does is to make the browsers scale the fonts uniformly. So when you go from medium in IE6 to large, you see the same thing as when you go from normal in firefox to the next larger size. Is this making sense to you? What it does is make normal in firefox look the same as medium in IE6. If the user in IE6 sets larger or largest, they will see the same as if you hit cmd/ctrl + in firefox 1 or 2 times respectively. Therefore it lets you set the DEFAULT sizes (normal in firefox and medium in IE6).

That depends. And ems are designed for font sizing, though percentages are OK for scaling; in most cases they are exactly equivalent, too.Yes, you can use ems to scale fonts. You can design whole font set ups that are entirely em-based (actually they recommend highly that you start with a percent value in the body tag if you're going to do that). You can futz around with that for a month until you've got it working as perfectly as can be in any browser. You can do that, absolutely. OR you can take the work that Yahoo's team has done and plug it in and go. The results are the same. That's the point, less work for you.

Exactly. So don't even start with pixels: respect the user.Starting with pixels has NOTHING to do with respecting the user in this case. It is perfectly logical, scalable, and resizable in each an every browser. Please, I'm begging you, try out the examples from the YUI page in all your different browsers including IE6. Please, pretty please?

No, it's not reasonable at all, because it ignores the user's wishes and limits the maximum font size attainable in IE unnecessarily. They do force an initial font size and - in IE - a maximum font size on the user. But merely setting the initial font size to 100% should remedy that.*sigh* I'm not sure how I can make this more clear for you. Again, 13px is a starting point, when you define an element's font size to be 122% (for example) it will then be equivalent to 16px in IE6 with the user's text size set to medium. If they set large or largest they will see a corresponding increase in font size. And again, NO setting an initial font size to 100% will NOT remedy anything. It will end up breaking everything which is exactly what you're seeing when you do that.

I don't care what a "pixel equivalent" is because I'm not a pixel nitpicker. I do care what the user's font size preference is and I can scale that exactly the same with those percentages. Pixels don't come into it.Please, please, please check out the WHOLE fonts css file, read the whole YUI fonts css page and look at all the example pages. Please? You'll see why the 13 px doesn't matter one bit. You'll see that you have total and complete control in all browsers with the accessibility of your fonts. You'll see why users will then have a more unified experience in all browsers and that you're not hijacking anyone's user-defined defaults.

No, they can't get back to their actual largest size because the starting point is much smaller.That will be up to you. YOU as the designer will set their starting size to be anything you want. You can set 13px that will resize, 16px, 20px, whatever all by setting the percent values from the chart.

No difference for that with 100% - if the styling is done right. Obviously it isn't because things that were equal in size with 13px suddenly have different sizes with 100%. And I only changed the body font size, the starting point, nothing else. Futzing will be needed to get all fonts to scale the same.You set 100% and broke the yui css file which depends on the 13px. That's why your site broke. If you go back and take out the font size dec from your body tag (along with the line-height dec from earlier) and then set individual elements to be whatever you want, you'll see uniform font sizes and a uniform, predictable user experience when a user increases their text size. Please pretend I have a clue for half an hour and give it a try.

Meanwhile you could try trusting that I know what I'm talking about, too. I'm a web developer; I develop with web standards, including accessibility standards. And I've been a member of one of the W3C's WAI working groups. Believe me, there's a good reason I start with 100% which respects the user's setting, and not an arbitrary pixel size that overrides the user's setting.What I'm seeing is someone who is absolutely refusing to look past one declaration in a css file to disect what is going on. I'm seeing a person that will not investigate why things are set one way and will instead call all approaches other than hers wrong. I'm telling you, you are not fully understanding why the fonts css file is set up the way it is. You could be the inventor of CSS for all I know. That doesn't matter if you're refusing to understand this.

Merely changing 13px to 100% for the base font size should be a great solution for me. Which is all I did.No. It. Shouldn't. It won't be a great solution for you or anyone else given what else is in the YUI fonts css file.

But it's obvious you are relying on the 13px as an absolute size, and not as a "starting point" for scalability. Which causes the need for extra adjustments that should not be necessary. Which is not a great solution at all.*I* am merely working with the tools available. It is Yahoo! that set up the file the way they did. And there are NO extra adjustments necessary. All you need to do is to simply define sizes for various elements (which you should be doing anyhow). All h1's are this size, all p's are that size, all li's are that size, that particular li is this size, those 3 p's are this size. And so on.

I'm not setting font sizes for any individual elements. You are. I merely changed the 13px to 100% on the body element. Try it and see. Look at my site. Look at my stylesheet.I know you're not. You're setting a body font size that breaks the YUI fonts css. Try taking out the body font size and setting font sizes for individual elements (which you are correct, I am doing - or will be now that we have this great tool). Just try it, that's all I'm asking.

I did take plenty of time to understand what's going on. I understand exactly what the difference is between 13px as a starting point and 100% as a starting point. I also understand quite well that if all font sizes were actually using that starting point and scaled with percentages (or ems) there would not suddenly be size differences with a 100% starting point where they didn't occur before with a 13px starting point.*sigh* Just... Just please, please try the examples? Maybe create a test site of your own?

And then merely override the 13px with 100% to be polite to the user - yes, that should be easy.Again, doing so breaks the YUI font css.

But currently I also have to make sure all font sizes are scaled, not set to pixel sizes. But that's not easy, because I will need to go through your stylesheet with a fine-toothed comb to find all the elements where you are setting font sizes and line heights in pixels (and you are). (I can see you're using pixel sizes, because some text doesn't scale in IE.) Just changing the 13px to 100% should be enough. It isn't now.First, to be fair, the fonts css file is new. SmugMug at the moment isn't a site that scales (in terms of layouts). Pixels font sizes make as much sense as anything else when you consider that you have known pixel heights of all the images and when you consider there isn't a whole lot of copy on a SmugMug site generally. But as JT pointed, that is going to change and adding this fonts css file is a first step. Future steps will be to go from pixel fonts and line heights to percent values that work with the YUI fonts css. So yes, you're right there. CURRENTLY, there will be a bunch of extra crapola to do. But soon you'll see that change as we make it how it should be. But don't hold that against the YUI fonts css. It works, it makes sense, and it isn't an affront to any users as long as designers are using their heads when they design. Yes, I agree, any large amounts of copy shouldn't be at 13px. YOU can make it so it is larger than that, and I wholeheartedly suggest that you do.

Once you actually scale all fonts, that single small change would be enough and I would not need any futzing to override the inconsistencies in your stylesheet.Meh. See all of the above.

If you want to implement YUI font.css, fine. But then implement it consistently and don't set fonts in pixel sizes. Scale. Follow the YUI guidelines yourself. You're not doing that now. You're using pixel font sizes and pixel line heights all over the place. That's what is making it harder instead of easier.When it is FULLY implemented (which as you've heard from JT it isn't yet) you'll see that it is not inconsistent and that it DOES scale. You'll see that when users increase their text size that if the designer sets a size for the copy that makes sense for the given element, they will have a most pleasing viewing experience. And you will see that as a user increases his font size, the page will expand right along with it as if they were simply zooming in. That's key in a photo sharing site I think you'd agree.

My recommendation to you is to not use a body font size of 100% and to not reset the global line height. Then, as painful as it is right now, set the font size in % values (as detailed on that chart on the YUI fonts css site) for your various elements. Do this, and then check out various browsers in various configurations. Just give it a try, that's all I ask.

iamback

Jun-13-2007, 01:49 PM

I think you're misunderstanding here. It is unifying the browsers at the default or medium setting. It is NOT telling the browsers to display 13px font size irrespective of the user's desired font size. Please, please, please try the examples on the YUI pages to see what I mean.Sigh... that's what I did. It starts way smaller than the default font size because 13px is smaller.

Yes, using 100% for the body tag is one way to do things. You can set this percentage and then futz around with some other settings and end up with a few days down the drain trying to get what you want.I would not need to "futz around" if your stylesheet actually implemented what YUI advocates: scale everything in percentages. But you don't. I only need to make corrections because you are using font sizes and line heights in pixels.

Or, you can take the work that Yahoo! has done and just plop it right in your browser. Believe me, it works how you want it to work, the 13px size is absolutely unimportant here. It's a starting point, nothing more.Yes it is more: the font size starts out much smaller than the browser's original default font size.

The idea is that you will define the font sizes how you want them on an element by element basis using percents. Please read what I'm saying.Please read it yourself!! Why aren't you doing what you preach? Why are you implementing the YUI fonts.css and at teh same time not using only percentages in your own stylesheet? It's your pixel sizes for fonts and line heights that are causing the problems!

I'm sorry, you're just not getting the point. The idea is that the YUI fonts css is based on the 13px and it gives you the total flexibility to set the font size for all other elements in your page.You're not getting the point. If I start with 100% instead of 13px I would still get the same total flexibility in scaling fonts for page elements. IF, that is, you hadn't overridden the YUI stylesheet in the first place and defined fonts for elements in pixels instead of percentages, all over the place. Why are you plopping the YUI stylesheet in, and then not implementing it?

And then when you set the font sizes you want (again, using percent values from the YUI chart) I don't need an effing chart. What I do need is a little consistency on your end, implementing percentage scaling yourself, instead of defining pixel sizes all over the place.

The problem is that if you override the font size for the body tag from 13px to anything else it will break the rest of the coding in the YUI fonts css file.It does not break font.css. The result only breaks where font sizes are not scaled but defined in pixels. And that's what you are doing!
Starting from 100% instead of 13px does not, by itself, make one iota of difference to scalability.

In reality it is the YUI fonts CSS file that is the most dependant on this 13px value.No it isn't! It's a tiny file in fact, and does a little percentage scaling. That scaling will still scale exactly the same when starting with 100% because it's still using the same percentages for scaling.

The problem is that you are not using the scalability it provides but instead in your stylesheets go on to define pixel sizes instead of percentages. So some things do break - not because I use 100%, but because you use pixels.

It is why the line height is set to 1.22 em globally (which you should also NOT change).I didn't change it and it doesn't matter. 1.22em is still 1.22em (a relative size!) whether you start with 13px, or 23ex or 100% or whatever size. 1.22em is relative.

Yes but ONLY if you are not breaking the YUI fonts css file.I'm not breaking it. But you are breaking scalability in your own stylesheet!

If you put a font size of 100% in your css you WILL break the rest of the YUI font css and therefore you will see odd things happen. You have verified this.NO!!! 100% does not break the YUI stylesheet. I see odd things happen because you are not actually using the YUI stylesheet and using pixel sizes instead of percentages. And that is what I have verified: not that I break the stylesheet, but that you do.

The starting point is there for a reason and is designed to be overridden. And I don't know how I can emphasize this for you enough. Exactly. And I'm overriding it by using 100% instead of 13px. Everything will remain as scalable as it was, as long as you don't use pixel sizes but percentages. But you are not doing that - you are using pixels.

In fact what it does is to make the browsers scale the fonts uniformly. All browsers scale uniformly when using percentages anyway. The starting font size has nothing to do with that. But browsers do have different default font sizes - which is what their users are used to or have adjusted. There is absolutely no reason to have an exact same pixel size across browsers; it's irrelevant.

So when you go from medium in IE6 to large, you see the same thing as when you go from normal in firefox to the next larger size.You wish. That is just not true. Try it, and measure it.

Is this making sense to you? What it does is make normal in firefox look the same as medium in IE6. If the user in IE6 sets larger or largest, they will see the same as if you hit cmd/ctrl + in firefox 1 or 2 times respectively. It doesn't make sense at all because I know it's not true. Browsers do not have the same scaling steps. Percentages are percentages, but the steps browsers implement in their user interfaces lead to quite different font sizes for each step (quite apart from the fact that IE has only a few steps).

Yes, you can use ems to scale fonts. You can design whole font set ups that are entirely em-based (actually they recommend highly that you start with a percent value in the body tag if you're going to do that). You can futz around with that for a month until you've got it working as perfectly as can be in any browser. You can do that, absolutely.I can and I do. Invariably. Not that I need a month for that - I keep things pretty simple.

OR you can take the work that Yahoo's team has done and plug it in and go. The results are the same.The results are not the same until I start from 100% again. More work (a little), because I need to do one extra step. From then on the whole process should be the same.

But instead there's a lot more work first, because I need to override your pixel sizes for fonts as well, before everything is uniformly scalable.

Starting with pixels has NOTHING to do with respecting the user in this case. It is perfectly logical, scalable, and resizable in each an every browser. It's resizable - but it doesn't scale up to the same size because it starts out smaller. And IE has only so many steps.

Please, I'm begging you, try out the examples from the YUI page in all your different browsers including IE6. Please, pretty please?But I did test!!!! And I saw an initial font size much smaller than the browser default font size. Which means that an IE user can never get back to the same maximum font size again.

Again, 13px is a starting point, when you define an element's font size to be 122% (for example) it will then be equivalent to 16px in IE6 with the user's text size set to medium.Again: I don't care about how many pixels it is - only pixel nitpickers do. I only care if it's usable for the user.

If they set large or largest they will see a corresponding increase in font size.Proportionally, yes. But because the starting point is smaller (remember, I did test and it's visibly quite a bit smaller than the default size), the end result is also smaller. And you can't go larger than "largest".

And again, NO setting an initial font size to 100% will NOT remedy anything. It will end up breaking everything which is exactly what you're seeing when you do that.No, what I'm seeing is that you are using pixel sizes instead of percentages and that is what is breaking things. If you would consistently use percentages instead of pixel sizes, nothing would break!

Please, please, please check out the WHOLE fonts css file, read the whole YUI fonts css page and look at all the example pages. Please? You'll see why the 13 px doesn't matter one bit.The "whole" fonts.css file is just a tiny file. I read it. I also did look at an example (the one you pointed me to!) and it starts a whole lot smaller than the browser's default size. And anyway, if you say the 13px doesn't matter, then why would 100% matter? It's just another starting size! From that initial size all you're supposed to do is scale.

Which you don't.

You'll see that you have total and complete control in all browsers with the accessibility of your fonts. You'll see why users will then have a more unified experience in all browsers and that you're not hijacking anyone's user-defined defaults.I see the opposite - until I set the starting size to 100%, which is when I see that it is your stylesheet, not the YUI one, that is breaking things. And I couldn't give a rats about "unified experience" - users don't normally use different browsers anyway.

YOU as the designer will set their starting size to be anything you want. You can set 13px that will resize, 16px, 20px, whatever all by setting the percent values from the chart.I don't need a chart to do my sizing, thank you. And I'm not a pixel nitpicker so I don't care how many pixels it is, as long as it's comfortable for the user.

You set 100% and broke the yui css file which depends on the 13px. That's why your site broke.Nope - I didn't break the YUI font.css file and it doesn't depend on 13px either. What broke is my site: due to the fact that you are not scaling with percentages as you are supposed to do but instead are using fixed pixel sizes. Want a list? I can make a list. But you can see it for yourself - just look at my site and get view the stylesheets with the developer toolbar.

What I'm seeing is someone who is absolutely refusing to look past one declaration in a css file to disect what is going on.Nope - I did not only read, I tested as well. As I already told you in my previous message.

What I am seeing is someone who refuses to believe that their own stylesheet is broken. But it is. I keep telling you this: you are using pixel sizes instead of percentages and that is why some text is suddenly smaller than surrounding text which is scaled (and should be scaled).

Do you want me to mail you your own stylesheet? What can I do to make you believe that you are using pixel sizes instead of percentages?

It is Yahoo! that set up the file the way they did. And there are NO extra adjustments necessary. All you need to do is to simply define sizes for various elements (which you should be doing anyhow). All h1's are this size, all p's are that size, all li's are that size, that particular li is this size, those 3 p's are this size. And so on.It is Marjolein! All h1's are this size, all p's are that size, all li's are that size, that particular li is this size, those 3 p's are this size. And so on. I always design that way, Yahoo! doesn't add anything for me. The only thing added here is aggravation because of your stylesheet which hasn't been adapted to use percentages instead of pixels.

You're setting a body font size that breaks the YUI fonts css.No, it doesn't break that file. What it does do is reveal that it is your stylesheet (not YUIs) that is broken.

First, to be fair, the fonts css file is new. SmugMug at the moment isn't a site that scales (in terms of layouts). Pixels font sizes make as much sense as anything else when you consider that you have known pixel heights of all the images and when you consider there isn't a whole lot of copy on a SmugMug site generally. But as JT pointed, that is going to change and adding this fonts css file is a first step.Pixel sizes for fonts are not needed in combination with pixel sizes for images. My 100% does not break anything. But your pixel sizes do break things - a lot of things.

Why, oh why, do you link in the YUI fonts.css file and not implement scaling? You're clearly not ready to release the YUI fonts.css if you haven't done your homework. Or are you making us into beta testers because no one had thought to check their own stylesheets before releasing this on the masses?

Well, thanks. NOT. I've been official beta tester for a lot of software, but by choice. I don't appreciate being forced to fix someone else's bugs. Especially not when I'm still evaluating the service in the first place.

CURRENTLY, there will be a bunch of extra crapola to do. But soon you'll see that change as we make it how it should be. But don't hold that against the YUI fonts css.That's what I'm saying all the time: I need to do a lot of extra work because you haven't though to adapt your own stylesheet to the YUI font.css you're now linking in. I don't hold that against YUI font.css. I hold it against SM for releasing what is clearly not ready to be released. And I'm only talking about fonts sizing here, not grids or anything else that {JT} referred to that will come later.

And you will see that as a user increases his font size, the page will expand right along with it as if they were simply zooming in. That's key in a photo sharing site I think you'd agree.GOSH. As if such a thing is new! That's key in any site and I always do it like that. I don't need YUI font.css to accomplish that in my own sites. But what I need to accomplish that here is to first override your pixel sizes so they become percentages and scalable along with the rest.

My recommendation to you is to not use a body font size of 100% and to not reset the global line height.I do use a body font size of 100% (the only change I made!) and I haven't touched the line height (but I may). The 100% may ultimately go down to 90% (but no more), but I invariably start with 100%.

Then, as painful as it is right now, set the font size in % values (as detailed on that chart on the YUI fonts css site) for your various elements.That's not painful to me, it's simply my normal approach. Like I said before, I never use pixel font sizes - only % or em.

But apparently it's so painful for you, that you haven't done it yet! Why haven't you? (That means you (SM), not YUI.) Just what is so "painful" about using percentages that you don't change pixel sizes into percentages yourself and release your own broken stylesheets?

Mike Lane

Jun-13-2007, 02:27 PM

Mike Lane

Jun-13-2007, 03:20 PM

To those who may care, I'm out on vacation until the 27th. Don't be offended when I don't reply to your posts (and don't think I've given up either! :lol3)

See you later.

iamback

Jun-15-2007, 10:42 AM

Okay suffice it to say that no, not everything has been implemented yet and yes we do have px sized fonts in most if not all of our themes for lots of different things. I acknowledged that and we're getting to that but Rome wasn't built in a day. We'll get there.You also suggested the YUI font.css was an advantage already. It isn't. So why even mention it's supposed merits when you cannot use it anyway without some major to find how it's broken in how many places with pixel-sized fonts and pixel-sized line heights, and then working out how best to override all that to get a level playing field back?

I do mean major, and I'm no beginner at CSS - but I've spent a large part of yesterday and most of this morning doing just that. FYI, http://css.smugmug.com/include/css/smugmugBlack-20070608001444.css contains a whopping 67 occurrences of font size in pixels, many of which are totally redundant (now who's pixel nitpicking?) and 7 occurrences of line height in pixels to boot. Just a tiny number of those might actually be relevant; meanwhile a great number of them are also marked as !important, so my override also requires !important. Sigh... I had a bad headache last night (eerm... early this morning) after working all that out. (Not forgetting that I've only overridden a single stylesheet, others for other themes may hold other unpleasant surprises.)

Of course, once that was overridden (globally, fixing all those individual cases would be a case of percentage nitpicking :wink) my fonts scale just fine, thank you. But that's after fixing what I didn't break...

I've tried it in several different browsers, the fonts reliably scale in each and every browser. Furthermore, they all get plenty big in IE6. So, despite your claims that this will prevent user-driven font-size adjustment, I'm finding it to work as advertised.

Are you seeing something different? Again, I'm talking about the YUI fonts css examples NOT what is currently implemented in SmugMug pages.The whole world does not use IE6. <shrug/> YUI fonts.css is YUI fonts.css, or isn't it? The point is that it's included but not implemented in SmugMug pages which makes decent styling a major pain.

And like you said, 13px is "just" a starting point. Fine. So 100% is my starting point. And that doesn't break anything at all. 'Nuf said about that.

Fonts are going to be dead simple: p {font-family:"times new roman"; font-size:122%;} h1 {font-family:arial; font-size:152%;} etc. Boom, done. No re-inventing the wheel, just perfectly scalable, accessible fonts in all browsers just by doing that.Which is what I've got now. By overriding all those silly pixel sizes completely. And which is what I always have in my own sites, so I'm not impressed. I'm just very very badly impressed by what SmugMug is doing, including font.css and still making it a major pain to do any scaling. Why was it even included at all? (And did you notice it doesn't validate?)

Anyway, I'm still having issues (many) but at least I've worked out the scaleability. But believe me, I would be really happy if I could just have an option to not include your stylesheet(s) at all so I didn't have to start by resetting everything to get a level playing field before even starting my own styling. At least I'm making progress now, but I was very upset yesterday... I see so much badly designed, invalid or unstructural code. (Like the keywords: why on earth is it just a bunch of links, instead of a list? Which semantically it is? A list would make it easy to style in any number of ways. As it is, I'll have to resort to JavaScript just to beat it into submission - and that's bad: JavaScript is for behavior, not for layout. Why aren't any of the menus marked up as a list? They should be. And that's just two examples.) I've encountered so many bugs and issues I haven't even had time yet to post most of them.

Mike Lane

Jun-16-2007, 06:57 AM

We had a sick baby so we cut part of our trip short. So I'm here for a day or so before we go on our next part.

If anyone cares.

So, I'm assuming that you now agree that the YUI fonts css does in fact work - though it may not be how YOU would have done it. That's good.

Again, you're harping that we haven't implemented it fully which I never said we had. As I said plenty of times, we will. I'll be working my hardest (when I get the chance) to make sure all our built-in themes are using percentages in line with what the YUI fonts css requires. I really don't have anything more to say about that. :dunno

In the meantime, we have something that, as much as it may make you cringe, works. Rest assured that we're going to be making it even better. But there is a lot of work to be done yet so sit tight.

I think we can now call this thread complete. If anyone has any questions, please post away!

iamback

Jun-16-2007, 08:57 AM

So, I'm assuming that you now agree that the YUI fonts css does in fact work - though it may not be how YOU would have done it. That's good.Sort of. ;) As I said plenty of times, I didn't break it either - it's broken by SmugMug's non-implementation.

Again, you're harping that we haven't implemented it fully which I never said we had. As I said plenty of times, we will. (...)
In the meantime, we have something that, as much as it may make you cringe, works.No, it's broken: not in and of itself, and not by my 100% (as you claimed at first), but by all of SmugMug's overriding pixel sizes which have to be overridden in their turn before you get something that can actually be customized. I'm sorry but that doesn't fall within my definition of "something that works". What you're giving us is "something that doesn't work and actually breaks layout on some sites".

It only "works" in the situation where no one does any customization and no one has ever done any customization. Which of course isn't the actual situation here.

Rest assured that we're going to be making it even better.Please, rather than making it "even better" (logically impossible anyway 'cause it's not good now), actually implement it first, so customizing isn't such a major headache (literally). Then wrap that in a release so we aren't unpleasantly surprised by a mixture of fixes and changes, and everyone has a baseline against which to baseline their customizations. And then, when it's good at last, make it better.

Off to do some other painful hacks, including for a fellow member who's layout was broken by this... But thread complete, if you wish. I've said it all.

brandofamily

Jun-22-2007, 10:47 AM

Mike, I now have had time to play with my code a bit and look at my pages... In the original discussion I asked if "we" were trying to make our FF pages resemble IE6/7 or IE6/7 resemble FF... I think you said IE6/7 resemble FF... If so, this code did not do it... I've been comparing my pages, specifically my nav bar in IE6 and FF... with the new code implemented the spacing/ line height I had in FF becomes that of the less desirable IE6...
I realize that the spacing is not much... and noone but me will notice... but I notice... Anyway, just a heads up...
Off to work on my code...