July 2009 Archives

YUI3 Version of Chroma-Hash

Chroma Hash Logo ImageMattt Thompson recently released this really cool jQuery script called Chroma-Hash, which visualizes a user’s password as they type it as a series of colored bars. The idea is that this will allow a user to see when their password is wrong, rather than simply submitting the form, and hoping for the best.

In light of recent discussions on the internet, which Bruce Schneier covers very well on his blog. Keeping track of passwords is hard, and typing in strong password, and knowing you’ve done it correctly, is difficult when masking in enabled. But, there are good security reasons.

Read Schneier’s posts, and the source material. The basics of the issue is that, if password masking does nothing else, it reminds the user that, “Hey! This is secure information!!!” But, also, typing is passwords is hard, and it’s really frustrating when you get it wrong. Chroma-Hash is an interesting experiment at solving this problem, by keeping the password hidden, while still providing visual feedback about what it is.

Mattt posted an example on his github page, and shared the source, but his blog post above talks the most about the current implementations limitations. That it uses MD5 (known to be weak to certain classes of crypto-attacks), and theoretically, someone watching someone put in their password could try to reverse engineer a password based on the characters that are being entered. These attacks are, in my opinion, extremely unlikely, but it is something to keep in mind.

Thompson mentions some potential improvements to the method, such as using SHA-1 instead of MD5 (given that the MD5 code is about 7k of the 9k of JavaScript, I don’t think it’s worth it, at least not without being able to include the hashing algorithm externally), or salting the input, or a few other things. My plan, as it stands, is to keep pace with Mattt’s repository, so that the YUI3 version will be functionally identical to the jQuery version.

The YUI3 version is up on github now, and I put up a YUI3 example page as well.

As an aside, while my YUI3 implementation is a tiny bit tighter than Mattt’s jQuery one, the difference in library size is really impressive. It looks like YUI3’s loader is able to load about 25k less worth of library script than jQuery. I’ve really got to commend the YUI team on how well they’ve been able to keep file weight down, as well how great the loader does at loading no more than is strictly needed.

IE Hates Fieldsets, Continued

Last week, I posted about how Internet Explorer doesn’t handle fieldsets very well. I focused a lot on the styling issues, which have been covered before, and realized I may not have touched appropriately on the second issue.

As I said before, any content before the legend tag within a fieldset, IE will render outside the fieldset. This isn’t entirely IE’s fault, as it is technically an error condition. Personally, I think HTML 5 should be modified to not require the the legend to be the first (non-text) child of a fieldset, but in the meantime, Internet Explorer’s failure mode leads to some interesting side-effects.

This is because, while the visual representation of that element is outside the fieldset in question, the DOM places the element within the fieldset. This can lead to some strange behaviour in situations like the following:

Viewed in Internet Explorer, each time you click the button, you’ll see the color of the paragraph shown both inside and outside the fieldset change. If you do query selectors, you’ll find two paragraphs within the fieldset, even though only one is rendered inside. This disconnect between the DOM and the visual representation of the page has some interesting implications, and it shows, in my opinion, a particularly poor choice in handling the error condition on the part of the IE team.

Unless the W3C modified the HTML standard to be more flexible about Legend placement (or at least strictly defines failure modes), it’ll be important to always make sure that the legend is the first item in the fieldset, which is mostly only a problem when modifying the legend via JavaScript.

IE Hates Fieldsets

As I work on refreshing our primary suite of web-applications on top of modern web-technology, I’m trying to replace our existing table-based form layouts with a more descriptive layout based on fieldsets. However, I’m having a hell of a time with Internet Explorer (I’ve been testing in 7 and 8, though I’m sure 6 has these issues, but luckily, most of our users are on at least IE7 by now).

First big issue, is that IE doesn’t render the CSS for Legends correctly. This has been documented before, but I have a few extra takes on it. One of the things I’m trying to do with my fieldsets, is have one large banner along the top, but no other borders. The CSS looks like this:

fieldset.ronetForm 
{
    border: none;
    border-top: solid 30px #d9e1e8;
    width: 99%;
}

fieldset.ronetForm legend 
{
    background-color: #d9e1e8;
    font-weight: bold;
    text-align: left;
    vertical-align: middle;
    line-height: 30px;
    padding: 0px 5px 0px 5px;
    border: solid 0px #d9e1e8;
}

This will result in a 30 pixel medium gray border along the top that the legend (fieldset title) will sit in cleanly. Here is what it renders like:

  • Firefox - Fieldset Posts - Firefox Legend Rendering
  • IE 7 - Fieldset Posts - IE7 Legend Rendering
  • IE 8 - Fieldset Posts - IE8 Legend Rendering

My favorite part is that the code renders better in IE7 mode than IE8 mode. In order to get the fieldset to render the same in IE7 and IE8, I had to modify the CSS for this:

fieldset.ronetForm 
{
    border: none;
    border-top: solid 30px #d9e1e8;
    width: 99%;
}

fieldset.ronetForm legend 
{
    background-color: #d9e1e8;
    font-weight: bold;
    text-align: left;
    vertical-align: middle;
    line-height: 30px;
    margin: -30px 0px 0px 0px;
    *margin-top: 0px;
    padding: 0px 5px 0px 5px;
    border: solid 0px #d9e1e8;
}

html:not([dummy]) fieldset.ronetForm legend
{
    margin-top: 0px;
}

First, I move the top-margin on the legend up 30 pixels, then reset it using the ‘star’ hack for IE7 and below, and then use the html:not hack (which works for all non-IE browsers I’ve tested) to reset the margin for non IE browsers. One-hundred and twenty bytes added because of a rendering bug. Awesome. What’s worse, there is no way to get rid of the white border between the fieldset’s border and the legend. At least, not that I can find. If anyone has a solution to this, I’d really appreciate it. For now, I’m probably going to have to do special styling for IE, because those white margins are really distracting.

There is, however, another issue I’ve run into with IE and how it handles fieldsets. In my JavaScript, I periodically want to put a paragraph at the top of a fieldset. For fieldsets, the W3C standard does require that the legend be the first non-text dom child of the fieldset. This is a little silly, because this is valid HTML 4.01 Strict:

<fieldset>
 Text in Fieldset
 <legend>Title of Fieldset</legend>
 <p>Content of fieldset</p>
</fieldset>

But this is not:

<fieldset>
 <p>Text in Fieldset</p>
 <legend>Title of Fieldset</legend>
 <p>Content of fieldset</p>
</fieldset>

I’m pretty sure this is to allow for the whitespace text elements that the DOM insists on adding between nodes if you have any formatting in your document, which incidentally is one place where I completely agree with IE breaking away from the standard. I don’t need whitespace only DOM nodes all over my DOM.

But! How is this rendered?

  • Firefox - Fieldset Posts - Firefox Content Rendering
  • IE 7/8 - Fieldset Posts - IE Content Rendering

So, since it occurs before the Legend, IE puts it outside the legend, and Firefox (and WebKit and Opera) all put it inside the legend. Now, this is non-compliant HTML. So, the browser is entering a failure mode to render it, so it’s hard to say that what Internet Explorer is doing here is wrong. However, when the browser enters a failure mode, I would generally expect the browser to try to do what I intended, even if I was doing the wrong thing, so I would say that IE does the incorrect thing here. Honestly, I think that HTML 5 should be relaxed to allow the legend tag to occur later in the DOM, but currently the spec calls for the legend before any flow content.

As I said, I ran into this problem while working on JavaScript. I was trying to use YUI3’s Node utility to prepend my newly created paragaph to the fieldset in question. A more complete version of this can be viewed in this gist.

Y.get('#test_element').prepend('<p>This is new content.</p>');

As demonstrated above, in IE, this is going to render outside the fieldset, not what I intended. So, I had to use the insert command. Incidentally, the insert call does not work quite as documented. I’m reporting it as a bug, and will likely hack together the support, but anyway, I can do exactly what I want as the tool stands.

Y.get('#test_element legend').insert('<p>This is new content.</p>', 'after');

Fieldsets are a tricky situation. Their use is more semantic, and they can create some nice form layouts when used and styled correctly, but Internet Explorer’s rendering of them has so many problems, which IE8 either failed to fix or actually made worse. I still recommend using fieldsets, though what you’re capable of doing stylistically is a lot more limited than it should be. With any luck, this issue will be addressed by Microsoft before the next release of Internet Explorer.

Raw Milk Not 100% Safe...Duh.

Ethicurean blogger, Amanda Rose, recently had the opportunity to speak at a raw milk symposium in Seattle, WA last Sunday. This was a huge deal because this was one of the first of these symposiums to include raw milk advocates. Of course, quite a few food safety people, such as Bill Marler, were on the panel speaking against raw milk, but at least it was more even this time.

I’ve written about Bill Marler before, and I’ve had the pleasure of talking to Mr. Marler on the phone about both of our takes on food safety, where we tend to differ most greatly on the issue of raw milk. One thing we can agree on, is that a product like raw milk will never be 100% safe. Where we differ, is on the fact that Mr. Marler argues in favor of heavy restriction, if not outright ban on the sale of raw milk, while I argue that the product should be available, even though I would advocate investigating your dairy before purchasing from them, but then I believe we should be doing the same with the majority of sources of our food.

So, what the problem? Well, some groups, like the Weston A. Price Foundation, a group I generally agree with and who runs the Campaign for Real Milk, seriously downplay the potential risks in unpasteurized milk. To the point of actually misrepresenting research, as is demonstrated in Ms. Rose’s post linked to above. It this sort of misrepresentation of facts that led a California-mother to serve raw milk to her 7-year old son. The boy contracted E. coli O157:H7, and it is believed it was due to the raw milk. The instance resulted in a lawsuit, the outcome of which I’m not clear about.

The mother claims now that had she known about the science that suggests that E. coli O157:H7 and other pathogens could thrive in raw milk, she never would have served it to her son (the boy did survive). And ultimately, as a parent she should have the right to make that decision, but she should also be able to have all the information.

Should the Weston A. Price Foundation be liable for misrepresenting the risk? Maybe.

On the other hand, the other side misrepresents the health benefits, and generally grossly overstates the risk of infection. Are they not any more blameful for that?

Personally, I’m wary about buying raw milk from a dairy I’ve never seen. Further, I’d need to know it was close, and that the milk was fresh. RigEthicurean blogger, Amanda Rose, recently had the opportunity to speak at a raw milk symposium in Seattle, WA last Sunday. This was a huge deal because this was one of the first of these symposiums to include raw milk advocates. Of course, quite a few food safety people, such as Bill Marler, were on the panel speaking against raw milk, but at least it was more even this time.

I’ve written about Bill Marler before, and I’ve had the pleasure of talking to Mr. Marler on the phone about both of our takes on food safety, where we tend to differ most greatly on the issue of raw milk. One thing we can agree on, is that a product like raw milk will never be 100% safe. Where we differ, is on the fact that Mr. Marler argues in favor of heavy restriction, if not outright ban on the sale of raw milk, while I argue that the product should be available, even though I would advocate investigating your dairy before purchasing from them, but then I believe we should be doing the same with the majority of sources of our food.

So, what the problem? Well, some groups, like the Weston A. Price Foundation, a group I generally agree with and who runs the Campaign for Real Milk, seriously downplay the potential risks in unpasteruized milk. To the point of actually misrepresenting research, as is demonstrated in Ms. Rose’s post linked to above. It this sort of misrepresentation of facts that led a California-mother to serve raw milk to her 7-year old son. The boy contracted E. coli O157:H7, and it is believed it was due to the raw milk. The instance resulted in a lawsuit, the outcome of which I’m not clear about.

The mother claims now that had she known about the science that suggests that E. coli O157:H7 and other pathogens could thrive in raw milk, she never would have served it to her son (the boy did survive). And ultimately, as a parent she should have the right to make that decision, but she should also be able to have all the information.

Should the Weston A. Price Foundation be liable for misrepresenting the risk? Maybe.

On the other hand, the other side misrepresents the health benefits, and generally grossly overstates the risk of infection. Are they not any more blameful for that?

Personally, I’m wary about buying raw milk from a dairy I’ve never seen. Further, I’d need to know it was close, and that the milk was fresh. Right now we go through a gallon of milk roughly weekly. If it was raw milk (which I’d love to be able to get), I’d want a fresh half gallon every three or four days. But I do believe that raw milk is healthier, despite the risks.

If I can find a nearby dairy to supply me with raw milk (and whom I trust), I may well get sick from it someday, but I acknowledge that risk, and I should be allowed to choose to take that risk. But, it’s also important that we get complete information on the issues out to everyone, so that they can make the most educated decisions possible.ht now we go through a gallon of milk roughly weekly. If it was raw milk (which I’d love to be able to get), I’d want a fresh half gallon every three or four days. But I do believe that raw milk is healthier, despite the risks.

If I can find a nearby dairy to supply me with raw milk (and whom I trust), I may well get sick from it someday, but I acknowledge that risk, and I should be allowed to choose to take that risk. But, it’s also important that we get complete information on the issues out to everyone, so that they can make the most educated decisions possible.

Getting Mulitple Select Values the Computer Science Way

One of HTML’s biggest flaws is it’s forms structure. Namely, that there is a single tag, input, which is used for all methods of taking data in from the user. The problem with this, is that different DOM Attributes mean different things depending on the value of the ‘type’ attribute. They don’t fire events as you might expect (why don’t radio buttons fire Change events?). And what’s available in the DOM is pretty simplistic. Select boxes do provide selectedIndex and value directives via the DOM, but what if you have the ‘multiple’ attribute set? There is no quick and easy way, from JavaScript, to grab every value from the list.

Recently, I’ve been rewriting our Class Lists application, to prompt the users with the list of courses they’re authorized for, and allow them to select one or more course from their list to display. And, since I’m using MVC, I can redirect the user to a nice, bookmarkable URL. The benefit also is that I can send the user to one of those URLs via JavaScript. For my interface, I’m opting to remove a bunch of radio buttons and replacing them with links, where the HREF on the anchor tags is updated as the user’s selection changes. However, that means that I have a multi-select box that I need to repeatedly query for it’s members. Oh, and this list can be over a thousand options long under certain circumstances.

I’m using YUI3 for the implementation of this, so some of what I’m doing is going to be YUI3 specific, and I’m going to assume that arguments to my methods are YUI3 nodes.

Traditionally, you’d simply iterate over the options of the list, and look for selected items, like so:

This has the benefit of being fairly straight-forward, but it’s not the best answer to the problem. For the best solution, and the more computer-sciency solution, we need to look into the realm of map-reduce. Part of the reason MapReduce is such a great solution to this problem is because many newer browsers are implementing map-reduce functionality in native code, allowing them to largely out perform functions like the one above, particularly on large datasets. Further, any good platform library will offer an implementation of the map and reduce functions that will be executed if the native call isn’t available.

Run through this JavaScript implementation of JSMin at the ‘conservative’ level, the base implementation is 264 characters, and the reduce one is 262, a fairly negligible difference. These two function will return precisely the same values on the same selectBox.

A quick explanation of the Map and Reduce functionality:

As stated, Y.Array.map and Y.Array.reduce, a part of the collection module in YUI3, will defer to native implementations, if possible. The argument lists are as follows:

Y.Array.map: * Array - This can’t be a NodeList, hence the call the Y.NodeList.getDOMNodes * function - The function to execute on each element of the argument array, this should return a single value. * context - optional argument for the context to run the function under, defaults to the window object

Y.Array.reduce: * Array - The array, generally output by the map function, that you wish to reduce * Initial Value - The initial value for the reduce function, this will be the seed value for the first parameter of the argument function. * Function - Function to execute to reduce the values.

For the function above, I’m just doing a simple reduce, since I’m not planning to do any manipulation of the values prior to reducing over them (in essence, I’m doing the ‘identity mapping’). I did have a mapping function that would do the selected check, emitting the value if it was selected, and undefined otherwise, but it bought me nothing, while adding a fair amount of length to the function. This is due to the fact that each value must map to something, even if it’s undefined (this is aided by the fact that, in JavaScript, every function implicitly returns undefined if it doesn’t explicitly return something else).

Map-Reduce is a really interesting tool, and while it shines best in a clustering environment, on something like Hadoop, a good understanding of the technique can be helpful even on smaller applications. I will most likely have a more in-depth look at a more involved map-reduce problems up fairly soon.