Posts Tagged ‘browsers’

To-Learn (As Opposed to To-Do)

Monday, March 22nd, 2010

I caught up with my reading again.

With nothing on my mental To-Do list (except such vague ideas as ‘work on something’), I’ve had the opportunity to do random stuff. I picked through my To-Read bookmarks, where I put everything when I was swamped with reading. It turns out a lot of that becomes completely useless to me, after reading a thousand other things over the last few months, so most of it can be deleted. Other things required me to have time in abundance, so that I can research some topics and possibly apply a few ideas.

While I was doing that, I decided that the only way I was ever going to learn the stuff I didn’t feel comfortable with was if I spent some time using it.
I want to know absolutely everything about HTML, but I don’t even know about half of the elements and attributes. So, I’m going to use it all; I’m going to memorize the big list of things (199 elements, at the moment).

I’m currently going through a whole smack of W3C specs, and a few Wikipedia articles. I’m going to find every proprietary tag I can, and try to find out which browsers use which.

You see, I constantly feel as if I have nothing to contribute. I don’t have any opinions of my own, and when I’m reading about all sorts of HTML things and the authors of those pages ask questions, I’m never able to add anything they don’t already know.

Things I need to know:

  • How browsers work, on the code-snippet level
  • All the differences between at least the main five browsers
  • All the differences between versions (Firefox 2, for example, doesn’t support display: inline-block)
  • What the heck all these RFCs are
  • The ability to quote an RFC’s requirements
  • The current issues in the HTML5 and WHATWG working groups
  • All the different types of ‘accessibility’ (blind, paraplegic, cognitive)
  • User psychology, UX, and other human-brain things
  • All the different ways to do things (javascript, server-side, different languages)
  • Different ways of coding (lisp-style, queries, procedural)

I need to learn the internals of:

  • JavaScript
  • HTML
  • PHP
  • Perl
  • Java
  • C
  • Ruby
  • Erlang
  • Clojure

Where I’m at right now:

  • I know roughly how browsers do what they do
  • I know some obscure browser trivia
  • I’m part of the W3C HTML5 lists, and am trying to keep up-to-date
  • I’ve got a base in A11y and UX
  • I know a lot about HTML
  • I’ve got some Java, PHP, and JavaScript under my belt
  • I can name a good deal of the more obscure browsers

I’ve still got a long way to go.
I want to teach this stuff, at some point. That means I need to know everything. All the tiny, obscure details. I need to know that the SVG 1.0 spec says that negative attributes are an error, while the 1.1 spec says that negative attributes are ignored.

It’s kind of funny how things go. My whole life, I loved computers. I wanted to design games, when I was young. I went into programming in high-school. I took a computer-based diploma program in college, and graduated in 2007.

I remember my online journal, which I created in 2005. I had no idea how to make links, or emphases, or any other stylization. But I learned how to make links, and then how to embed images. I took a class on HTML, and then one that included CSS, and then I made a couple half-hearted websites.

In 2009, I abandoned almost all that programming stuff and flew headlong into HTML and JavaScript and CSS and websites. I spent a great deal of that time designing, rather than programming.

When you find something you want to do, you’ll notice. But you won’t know what you want to do until you find it.
So try everything. Find what you want to do. Then learn everything you can possibly learn about it.

Internet Explorer Drama… 9.0!

Saturday, March 20th, 2010

With the latest IE9 announcements, designers and developers have been going mad with what one might call Internet Explosion.

Stuff like the following: (not real quotes; just paraphrasings)
“No!!11 Just stop developing IE!”
“Only Acid3 score of 55/100? Other browsers did that YEARS ago!”
“It’ll be five years behind!”
“We’ll have to support FOUR browsers!”
“I REALLY HATE MS”
“Why don’t you use webkit; Trident is dead.”

People are proving to be extremely closed-minded about IE. What I find very ironic is that a lot of them say things like, “MS, stop developing IE!”
That happened. They stopped after IE6, right at the end of the Dark Ages. And you see what life became?

About five years later, they picked up the pieces and race to bring IE into the future. IE7 is still annoying, but IE8 (released in early 2009) is a perfectly good browser for its time. IE9 should be competitive, with basically everything being clamoured for today.

A few misconceptions

There have been a host of ill-conceived arguments. I’m just going to list every correction I can think of:

  • Acid3 has little to do with compatibility. It tests edge cases, in a sort of wish-list for developers. It can be important for high-level cross-browser online applications, but you really wouldn’t tell a difference between browsers in a regular web-page.
  • Firefox has historically had a fairly ‘low’ Acid3 score, with 71 in Fx 3.0. The Firefox team has even said something like, “We aren’t going to bend over backwards for it, because it’s not really what we’re aiming for.”
  • IE8 is soaking up both IE6 and IE7; and you don’t have to ‘support’ IE8 in the same ways as IE6 and IE7, any more than you have to ‘support’ Firefox or Safari or Chrome. Things tend to test pretty well in them, by default. IE9 will be similar.
  • There is a non-negligible percentage of users on Firefox 2, Firefox 3, and Firefox 3.5. Nobody is complaining about supporting four different versions of Firefox. Thankfully, Fx2 is almost dead.
  • Even two years ago, CSS3 was nearly unheard of, and nothing had HTML5 features. Now a browser with border-radius and HTML5 video is five years behind?
    The things we’ll be deciding in the next year likely won’t find their way into the final release of IE9; but CSS3, HTML5, SVG, and various other standards we never ever expected to find in IE are already there, with more to be added. It’s coming along.
  • Actually, IE9’s current compatibility score, as counted by the When Can I Use charts, is similar right now to Firefox 3.0’s July 2008 release — less than two years behind, in the context of every toy we’re asking for as developers.
  • Trident is fine. When we speak of the Trident layout engine today, and we’re talking about IE9, then we’re talking about Trident in IE9, and that’s a perfectly fine engine. Overall, it’ll be lacking some features, but will not be holding itself together with duct-tape and paper-clips. There’s a difference.
  • As a company, Microsoft has gone through some huge changes in its history. The Internet Explorer development team isn’t the same team who gave us IE6. Don’t harass them (the development team) for things they couldn’t have possibly helped.

Almost every current browser team has its demons to face. IE is no different, but we should look to the future with optimism. Help where we can, and condemn where we must, but don’t frivolously argue about things that aren’t relevant to today.

And maybe help IE6 along by preaching Progressive Enrichment, hmm?

Browsers: Best of

Monday, August 3rd, 2009

For posterity, I’ve decided to make a list of all the features browsers have that should be mimicked in all those other browsers. Keep in mind that some have duplicates, just so I didn’t have to add additional ‘combination’ entries. Anything missing would be welcome.

  • IE8: Hideable menu bar, Web Slices, Accelerators, Tab Isolation, Compatibility View, Offline Mode
  • Firefox: Extensions, Offline Mode
  • Chrome: ‘Application’ interface, Full-Themed (no native title bar), Start Page, Tab Isolation,
  • Safari: Document Inspector
  • Opera: Mouse Gestures
  • Others:

Buttons: Part 2

Saturday, May 30th, 2009

I guess I was younger, back when I made my first set of buttons. I went back to them today, and found that they didn’t work in other browsers. Also, I wanted to see if I could make them with HTML (seems like my latest craze).

Webkit is stuffed full of strange and amazing tags that let you set background gradients, text shadows, rounded corners, rotations, and pretty much anything else you could want. It’s missing outline-radius, though, which meant I had to use two divs to create the button I had designed in Paint Shop Pro. And a span. But that’s all!
It had two borders, each with a small amount of radius, a linear gradient background, :target tags so it looks like you click it, text shadow to get the 3D appearance, and whole bunch of regular old CSS2 and CSS1.

When I was done, however, I realized that, while it still worked in other browsers, there was no background. Yet again, I had made something that was only viewable in webkit.
I tossed the gradients from my image buttons into another image and used that as a background for everything not-webkit, but there’s a bit of white sticking out of the bottom. Things just aren’t lining up the same in every browser, which is a pain to work with. I’ve never really needed to worry about 0.02em before today. It turns out that’s a fair amount.

Anyway, I’ve got the newer version here for your perusal.
(As if I’m submitting it for your approval, or something.)
As I said before, it looks best in Chrome or Safari. The little font-changing button doesn’t seem to work in Firefox, for little or no reason. It looks stupid in IE7 and lower, because there’s no :focus selector, which means it’s not really a button.

What am I going to do with it, now? I saw some great article about progressive enhancement that laid out about five images beside eachother, and each one showed a more feature-rich page in a different browser. In that light, I think I’ll try my hand at making some sort of tab that turns into a great-looking button when you view it in a more advanced browser.
It appears Firefox lacks support for things Webkit and Opera have, like text shadows. 3.5 is going to be an important release.

Also, I’ve noticed, lately, that I refer to Firefox, Opera, and Webkit, because it seems a bit redundant to mention both Safari AND Chrome when talking about rendering. I’ll talk about one or the other when it’s about browser features (like how I’m jealous of Safari’s document inspector), but otherwise I’ll just refer to the Webkit engine.

So this whole day has been an exercise in jQuery. I’m trying to find out how to get certain elements from the context array (whatever it’s called). It seems .get() doesn’t allow things like the .text() tag or the .html() tag. Maybe if I wrapped that in another jQuery object…

Full-page zoom

Sunday, May 3rd, 2009

I was designing a site in my free time, and I ran into an issue with the first images I put in. I hadn’t set the height anywhere, but they were bigger than they should be. I had to manually give them a smaller size, to make them fit.
As it turned out, I wasn’t using my computer, and so I was using the portable Google Chrome 2.0 from my flash drive. I usually use 1.0 at home, so I can be sure that what is seen by my browser is what will be seen by other users of chrome (2.0 only has a couple tenths of a percent, right now). I got it for my flash drive because I wanted to see the newer features, and because I could keep several different versions.

In 2.0, as well as in most other browsers, a full-page zoom is used. That means everything is resized, including images, even if you don’t use ems in your styles.
What that also does, however, is increase background images and other things that can’t stand the stretching. This laptop has nothing but paint, so I had to hand-draw a horrible dither pattern instead of using an alpha gradient. because the dither is made of individual pixels, any stretching (and thus blurring) is incredibly noticeable.
It’s good to increase pictures and elements (things get squished, otherwise), but one might make an exception when it comes to background images. For an example, I once had a largish image in the background of a sidebar, so that someone with a larger text size would see more of the image. If full-page zoomed, all they would get is a pixelated, smaller image.
Borders, as well, tend to be made for specific widths. Here it’s a bit more acceptable, because a continuous pattern isn’t lost by a bit of scrunching, and most borders use a gradient that suits a smoothing filter just fine.

In certain cases, though, there must be a way to disallow an image from being full-page zoomed. The only reason the full-page zoom is there, of course, is that a great many developers don’t have either the resources or the skill to size everything in ems instead of px, which constitutes a failing on the developer’s part. Browsers add full-page zoom because they found it’s needed and that a lot of people don’t allow it in their code.
And I don’t blame them. What we need, though is some form of opt-out option. If the problem is that people usually don’t do something, fix that, but then let the people who do do something to do something to make things the way they should be.

In that light, I’m going to have a look to see if there’s any way I can disallow full-page zoom on certain elements. At worst, I suppose I could disable it for the page, but I always size with ems, anyway, so that would be fine.

On a final note, I think the best idea is to set your browser’s text size the way you want it, so that things are initially rendered at the size you want. That way, you don’t need zoom.
(The problem with that, of course, is that you get the effect of your default level being like a non-full-page zoomed with the non-em-sized images being far too small. I guess it’s a matter of delicate balance.)

Browser Developer Tools

Wednesday, March 4th, 2009

Oh, wow, the developer tool in IE8 is actually pretty impressive.
Back when I had IE7, I did a quick look into who had the better source viewer, because that can be rather important. I think firefox had some line numbers and syntax highlights, but otherwise wasn’t anything special. I completey forget Safari and Opera, but I think they had either text or something similar to firefox. IE6 and IE7 both had a Notepad window come up with plain text inside, and chrome had a pop-up window full of element attributes that would highlight parts of your webpage as you hovered over the different elements in the code. Needless to say, Chrome took the cake, and ate it, too. The other browsers were mad at it, but I guess they should have gotten pie, instead.

The new IE8 Developer Tool lets you change between IE6, IE7, and IE8 rendering modes in two clicks, sends your code off to the W3C validation tool, resizes the window, creates rulers, view the document with a collapsible tree view and highlighted syntax, and more.
Most importantly: not only can you see every element and attribute in both HTML and CSS, but you can disable CSS or disable individual styles.