Wednesday Feb 27, 2008

Border-Radius Roundup

The black and white object you're looking at will look different depending which browser you're using, but it should look like a circular target of some sort. It was created using nothing more than CSS's border-radius property and a couple of span tags. All of that to say this: It looks like Safari/Webkit browsers are rendering border-radius quite nicely these days, and Gecko-based browsers aren't far behind, if Firefox's latest public beta means anything. To illustrate this, I've posted some screenshots of a test page I built. This wasn't an exhaustive test for CSS3 border-radius compliance, just an attempt to see where the browsers were with basic support. Only one background image is used (shown below), the rest is pure CSS. (All tests done on the Mac.)

[Read More]

Wednesday Dec 19, 2007

IE8 Standards Compliance Mode?

Strange things are afoot in IE-land. Remember our old friends quirks mode and (almost) standards-compliance mode? There's reason to believe IE8 will introduce yet another rendering mode, and that developers will need to opt-in to this rendering mode if they want IE to break backwards compatibility with its long-entrenched bugs. The question is, how will the opt-in be triggered? A <meta> tag? A version number in the opening <html> tag? An HTTP response header? A conditional comment? The mind boggles.


[Update]: Chris Wilson of the IE team promises more details soon regarding this very thing.


[Update jan/25/08]: And we have a winner: A <meta> tag and/or an HTTP response header. I have no opinion. Too many people smarter than I have already weighed in, and it remains to be seen just exactly how this will all shake out.

Whoa Nelly: IE8 Passes Acid2!

What has the world come to?

Wednesday Oct 24, 2007

Front-End Quiz Part 8, ALT Attributes


For a propane supplier's website, which use of the alt attribute value is best?

  1. <img src="mountains.jpg" alt="mountains.jpg">

    This provides no useful information in cases where the image can't be seen.

  2. <img src="mountains.jpg" alt="mountains.jpg, 400x300, jpeg image">

    This provides no useful information in cases where the image can't be seen, and adds noise to the page's content.

  3. <img src="mountains.jpg" alt="aren't they pretty?">

    Aren't \*what\* pretty? By definition, the user can't see the image if the alt text is showing.

  4. <img src="mountains.jpg" alt="mountain scene">

    If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "mountain scene We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be weird.

  5. <img src="mountains.jpg" alt="a mountain scene, taken March 2004, near Evergreen CO">

    If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "a mountain scene, taken March 2004, near Evergreen CO We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be weird.

  6. <img src="mountains.jpg" alt="We Are Colorado's Best Propane and Natural Gas Supplier.">

    This is good, possibly, depending on context. Alt text doesn't necessarily need to reflect the content of the image! It's truly ALTernative content. If the image were followed by the text "We can deliver propane to your door seven days a week." then the text "We Are Colorado's Best Propane and Natural Gas Supplier. We can deliver propane to your door seven days a week." would be displayed when the image wasn't present, which would be a great use of alt="". However note that context and intent should be taken into account when deciding alt text, and it's certainly not something that's machine-decidable.

  7. <img src="mountains.jpg" alt="">

    This is iffy. Sometimes it might be best to leave the alt attribute blank.

  8. <img src="mountains.jpg"> (no alt attribute)

    This is bad. There should always be an alt attribute, even if blank. This at least makes it explicit that the image adds no meaning to the page.


Wednesday Aug 29, 2007

Front-End Quiz Part 7, Doctypes


Which HTML doctype is best?

  1. HTML 3 or lower, or just don't use a doctype.

    \*Shudder\* With an ancient or missing doctype, your web page will be rendered in quirks mode, making proper CSS design more buggy and difficult.

  2. HTML 4.01

    My personal choice. As of 2007, HTML is still a perfectly current, valid standard, and is extremely well-supported and well-understood on the web.

  3. XHTML 1.0 or 1.1

    There are actually some problems with XHTML. As of 2007, try to serve true XHTML, and your website will probably fail for lack of visitors, simply because Internet Explorer (IE) currently doesn't support it. Many sites these days claim to be built in XHTML, but most fail the validator, and almost all are served as text/html to support IE, causing them to be understood by all browsers as nothing more than syntactically weird-looking HTML. In other words, it is HTML in all but name. As a best case scenario, let's assume that on September 2008 IE 8 will ship with true XHTML support. That means XHTML won't be a feasible option for websites until the last users of Internet Explorer 7 (released 2006) finally upgrade. In other words, extremely optimistically, it will be, say, 2010 or later before true XHTML is a viable option. Until then, why fake it? All of that said, there are some good reasons to use today's faux brand of XHTML. Most commonly, content might need to be treated as XML on the server-side, even if it's served as text/html to the client. This is where I think XHTML shines today.


Wednesday Aug 22, 2007

Front-End Quiz Part 6, Separating Content, Behavior, Presentation


Where/how is content best separated from behavior and presentation?

  1. On the client-side, using semantic HTML plus external JS and CSS files.

    This is where I set up camp. Server-side methods exist for separating content, presentation and behavior, but they have different ideas of what "presentation" and "behavior" mean. In terms of separating out the visual presentation and client behavior layer, CSS and unobtrusive JavaScript should be the first line of defense.

  2. On the server-side, using features of your rendering framework/MVC architecture.

    If, by "presention" you simply mean HTML code, and by "content" you mean information stored in the application, and by "behavior" you mean controller logic, then yes. On the other hand, if you're coding font tags, layout tables, spacer images, onclick="" and onload="" attributes directly into your JSPs or page renderers, then I think that's a serious red flag. With CSS handling the visual details and unobtrusive JavaScript handling client interactivity, your web renderer is free to focus on saying "now a heading," "now a list," "now a submit element," etc.


About

My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today