IE11 Things I Had to Learn

I've dealt with several quirks of the new version of IE in the last couple days. Here's what I've uncovered:

First, in IE11, you can setup a standard anchor tag to open up an app. This will try to load it side-by-side with IE, but typically it will navigate you to a blank window in IE11, which is not ideal experience. To launch an app directly into a side-by-side window without this problem, use a hidden iframe (0x0) and set it as your app link's target. such as "<a href='skype:5555555' target='helper'>Call us</a>"

The reason is that the app loading apparently needs an window to run its launch command in. Since the window will have no content (it's all in the app), you'll get the blank window. But if you use a hidden target in the web page, only this will get the blank window, which is hidden, leaving your webpage uneffected.

The second thing I dealt with was automatic Skpe links. The new feature in IE11 is that phone numbers (plain text) will turn into automatic Skpe links. Not a bad idea, but the browser decides to style these links for you. Without your permission or control.

I had to maintain the links' functionality, but also keep the original styling. Well, you can't just write CSS. It automatically underlines, changes the color, and removes the custom font. 

Working with this, I discovered that IE11 will attempt to match the color of the link based upon its background with a couple standard defaults. EXCEPT if you have an image background, then it will let you control the color. So you'll have to force one - either with transparent background applied or some solid color background. Unless of course, you have a background image already.

The underlining (even using !important inline) won't go away. The hack here is pretty simple - set a height on the element and overflow-y to hidden. Adjust the height until the underline goes away. It's typically 1px away from actually trimming your text. You'll have to adjust a few positioning components to realign things. 

I couldn't figure out a workaround for the font, but it will respect serif/sans-serif. 

That's it so far. The first issue is not necessarily a problem. The ability to quickly open apps especially things like Bing Maps is pretty cool and fast, but I just wish that I could've found documentation or an example someplace to get this behavior. 

The second issue however is crap. There is no point that a browser should be given the right to restyle a page. The standard for phone numbers thus far has been to create "tel" hrefs. Those are in fact ignored by the Skype linker, meaning, if you want to give users the option for your site, you have to have 2 layouts. And one of those will not let you style it. 

I know it's intended for convenience, but some numbers I may not want highlighted. In fact, that was the only information I could find on this subject - to simply eliminate it. Well, if you're in the middle ground, you have this struggle, which isn't empowering. It's now a quirk, alongside all our other fun tidbits with the legacy browsers. 


Revising Stories with Rails

I love rails. I love that I can sit do and just sweep through the model layer, building out all that abstraction for an applicaiton within a couple hours at most. Likewise with the view layer, using the prebuilt urls (new,create,show,edit...). Reusing partials throughout, so I can take a static site and use some of the partials to build a dynamic one. It's fucking beautiful.

That said, when I first got into Scrum and was looking out building stories within the rails framework, it occurred to me that a lot of what made rails fast for development didn't exactly work for how I was writing stories. So I had two choices - change how I developed in rails, or changed how I wrote stories. 

Well, it was obviously not going to be the first, so I changed the second. The main change wasn't so much the stories themselves, but the expectations that followed teh stories.

For example: "User can save a new contact." Off the cuff, this sounds like it would require a build from the model to the view layer, especially if the contact form was actually a lightbox or some pop-out, which would require some JS/CSS magic. Rails exposes that this may be a too big of story, or maybe that I need more backlog items in order to actually cover it.

Here's what I built instead:

- A new contact can be saved.
- A user can save a contact through a webform.
- Webform is integrated into the dashboard and a user can save there dynamically. 

How the last two make sense as added features and they fit with my eulogy to rails above. First I build a form using the standard new template, then I render that as a partial once I get to dashboard integration. In this situation, I can do tests against the form, and leave all the work of the final feature to template/visual work rather than submission/controller work. 

Finally, the first feature, segregates the model work to its own feature. A great way to confirm this functionality is to lean on the Unit test system that comes with rails. Now I could theoretically put all of my model tasks into one sprint and have verification of my feature, with the additional benefit of always having the ability to easily do regression testing. 

Clients may not find this as sexy, but I think most folks get that setting up saving is the first step in building an application and the UI comes next, even if all you have to show (if required) is the console confirming save and data retrieval. 

Why I switched my team to Sass after about 15 minutes

Chris Coyier | TXJS 2013 from SlexAxton on Vimeo.

After one of my team members sent my company's dev crew this link the other day, I decided to spend some time this weekend incoprorating Sass into my workflow for an upcoming web app. 

As my spoilers in the title indicate, I have now decided that my team is going to be required to use these tools. There was initially, not a lot of resistance, but just a plain lack of interest in these tools at my company. All but one of us really didn't feel much push to start using a tool that we felt saved us very little time and could possibly screw up our workflow. 

Well, here I'll say that I was wrong. Sass is excellent and I'll just bullet point this:

- I can continue to use CSS the same way as before, especially with automated compilers. There are other tools like CoffeeScript that yeah sure I type less, but now I can't work in JS.

- It's intuitive as hell. I only spent a little time with the documentation and the code was doing exactly what I expected even when I simply guessed its style.

- Sass allows me to have a base variable to store things like color definitions in one place. Now if only I could get object classes in Sass.

For me, the biggest issue was that Sass meant processing got added to realm that previously didn't have it. Processing adds complexity, which adds the likelihood for bugs. The reason this doesn't matter is that CSS is already pretty screwy in that small typos already completely fuck up entire sheets, and the processing with Sass is so low level that anyone who has programmed for a shortwhile won't be confused by method. 

The biggest point is that Sass is tooling done right - turning a shorthand into actually workable commands within the existing CSS framework. Other modifiers tend to force your hand to only work in shorthand, but as a coder, you want both availble. Sass does exactly that. So if you don't work for me, you may not be required to use Sass, but I would recommend you try it.

Godspeed coders. 



Subscribe to Coding