Fleeting Epiphanies

Decision made: Moving to my own blog

So yea, I’m being kind of fickle. I had a blog for years that wasn’t on my site. And about 18 months ago, I got super busy and just couldn’t get inspired to post in it. Plus, Twitter makes it so easy to discuss issues in quick sound bites that I suppose I got busy and lazy.

About six months ago, I realized that debating and discussing in 140 characters doesn’t always do it. Tumblr seemed the obvious answer—to be used for things that weren’t really blog posts, but were more than a Tweet. Somehow, writing a blog post always makes me feel pressured to be more profound—or something.

What has happened though is that I’ve basically started using my Tumblr as my blog. But a blog without comments (yes, I realize I can do some magic and add them in), stats (never got them working) and one where I don’t “own” my content (sure, I can grab the RSS, but it’s not in my database).

So I made the decision to put my blog on my site. I know. Novel idea. And I’ve decided that a blog post can simply be my thoughts, above 140 characters, and doesn’t need to be overly profound. Yay me. I think that’s growth. 

I may still post little ditties here on Tumblr, but most of my posting now will be on my own blog (which may eventually have a design)—http://blog.w3conversions.com. Hope to see you there! 

HTML5: Native Video, DRM and Plugins

I was reading a discussion on the W3C Bug tracker about native video and whether it should, or should not, provide DRM to protect video content. In the process, the point was made by John Foliot that Apple is presenting their own answers in their browsers and devices to the DRM issue (emphasis mine):

> The question of DRM within the media formats supported by browsers is a
> separate issue to be addressed in a different forum, but as I said, I'm fairly
> sure there will be strong resistance to it.

Really? I have it on first person confirmation that currently Apple is
promoting "...H.264 with the m3u8 format for HTTP streaming with optional AES
encryption..." to commercial content producers in North America. Either that
gets supported directly in the browser, or gets handed off to a third party
(QT)player... Frankly at this point I could care less if Opera, Mozilla and
Google see this as a problem or not - it's your business models, not mine.
Apple will profit by selling their iDevices that *do* support encryption, as
will Roku, Wii, X-Box and other companies who understand the real business
needs at the intersection of the multi-billion dollar industry that is "the
Internet" (delivering content over the global network) with the multi-billion
dollar industry that is the Entertainment Industry. 

My best guess, without having all the information personally available, is that the statement above (placed in bold type) means that if you’re using a Mac, DRM is supported directly in the browser because QuickTime is built in. If you’re using a PC, just as happens currently with native video, you must install QuickTime to view it.

Isn’t a plugin just a plugin?

QuickTime is a plugin. So the question I keep asking is this one — Apple refuses to allow the Flash plugin on their devices (and until very recently also refused Adobe the hooks they needed into the OS to speed Flash up like it has on a PC). Much of the web that needs video is already standardized on Flash. They seem to be attempting to move people to their plugin (which they can either build into their own products or ask people to download—as they do Flash now).

Was native multimedia added to HTML5 to make plugins extinct?

The W3C says the co-existence of plugins and native multimedia are par for the course and expected. One was never meant to kill the other—the embed element was even made valid and acceptable in HTML5. Thus, Apple’s stance that HTML5 multimedia should be the only solution—and it’s been taken to the extreme by blocking Flash altogether on their devices—then they circle back around with their plugin to provide the features that Flash already provided… Sorry, it seems disingenuous at best and anti-trust/anti-competition at worst.

Why don’t I hear people discussing this? Am I making up the gravity of what’s happening? Am I seeing something others haven’t noticed? Am I making a mountain out of a molehill? I’m starting to wonder…

Inner border (content or padding edge) quirk in webkit?

Today on Twitter, Keith Clark (@keithclarkcouk) mentioned he was struggling with creating an element with rounded corners and rgba borders because the background color of the element was showing through. That sounded silly. I mean, modern browsers have background-clip. We can clip to the content, the padding or the border. That should fix it. But Keith was reporting that it wasn’t working.

In experimenting, I found that in webkit-based browsers, it doesn’t really work at all as I would expect (the Firefox 4beta does what I’m interpreting the spec to say). The background-clip property itself works (in modern browsers). But when the inner border is rounded (on the padding edge), the content with the background-color is not rounded—it remains squared. This causes the rbga border to overlap the square corners making an entirely different color on those points.

Firefox and webkit differences

The image below (from this border-radius demo) shows Firefox 4b on the left and Safari 5.0.1 on the right. Note that with transparent background, it keeps the rounded look. It’s only with the background color that you get the overlapping look.

Corner shaping

The spec reads like this (emphasis mine):

The padding edge (inner border) radius is the outer border radius minus the corresponding border thickness. In the case where this results in a negative value, the inner radius is zero. (In such cases its center might not coincide with that of the outer border curve.) Likewise the content edge radius is the padding edge radius minus the corresponding padding, or if that is negative, zero.

In the case of my code, the padding edge (which you can see as the inner border when there is no background color) should be made from the outer border radius (30px) minus the corresponding border thickness (10px). 30px - 10px = 20px. The content edge should be made from the padding edge radius (20px) minus the corresponding padding (10px). 20px - 10px = 10px. What I’m seeing in webkit however is zero curve on the content edge—at least that’s what I think I’m seeing. Is anyone reading this differently?

Corner clipping

Furthermore, the spec continues to talk about the corner clipping and says (emphasis mine again):

A box’s backgrounds, but not its border-image, are clipped to the appropriate curve (as determined by ‘background-clip’). Other effects that clip to the border or padding edge (such as ‘overflow’ other than ‘visible’) also must clip to the curve.

In my case, background-clip is set to padding-box. This means the background should cover the content and padding, but not the border. Webkit is not clipping to the curve of the padding (which we can see in the transparent example). 

What disturbs me a bit is that, in both Chrome 5 and Safari 5, the -webkit- prefix has been removed. It seems we need some method of ensuring that a vendor actually complies with the spec before removing their vendor prefix since, in this case, I can’t even “turn off” or change the rendering in webkit because the newest versions use the unprefixed border-radius property.

Is this a bug? Or am I reading it all wrong?

Javascript and HTML5

The web is becoming more and more dependent on Javascript. This has been troubling me a bit since I’ve always held the view that all content should be available and usable (though perhaps in a different state) when Javascript is turned off.

Internet Explorer

In Internet Explorer (up to version 9), the only way to use the new structural elements in HTML5 is to use Javascript to insert the elements into the DOM. Then IE will allow you to style them. If you don’t do this, IE will style the elements it understands (the HTML4 elements), but leave the ones it doesn’t unstyled (the new HTML5 elements)—and that can be worse than no style at all.

As I was writing a new talk on HTML5 recently, I struggled to find current information related to how many users view the web without Javascript enabled. The numbers ranged from 5%-8% (and I couldn’t be sure how accurate they were). When giving my talk at Web Directions US, Nicholas Zakas who was also speaking, informed me that Yahoo! has found Javascript turned off in 1% of users on their home page. He’s currently writing a blog post documenting/explaining this information and I’ll link to it when completed.

HTML5 and Accessibilty

I also wanted to be sure that there was no accessibility penalty when Javascript was turned off. To me, this is even more important since many that surf without Javascript (geeks) can enable it if it’s needed. But if the lack of Javascript harms the usability for screenreaders or other disabled users, that’s clearly problematic. Derek Featherstone pointed me to an excellent bit of testing done by Jason Kiss which showed that even though screenreaders may not totally understand the HTML5 elements, they still read the content. There are a few issues—you should read the article for more information—but it’s not related to Javascript, so we’re safe there.

When Javascript is Turned Off

The conclusion I’ve personally arrived at is this. I’m going to use Javascript to enable the new HTML5 elements in Internet Explorer. But I’m going to take it one step further. I’m going to notify those using IE that they need to enable JS to properly view the page. Instead of using the <noscript> element, I’m using Modernizr. I realize that <noscript> may seem more semantically correct, but there are situations where it may not be best served as such (serving your document as XML is one of them). It also doesn’t give you the same styling abilities without special care.

With Modernizr, I place a class called .no-js on my html element:

<html class=”no-js”>

Modernizr not only adds the IE support for the HTML5 elements, but it tests for many other supported and unsupported HTML5/CSS3 features and gives you feedback in the form of classes. That’s not the important thing here—what’s important is that Modernizr changes the no-js class to js. Thus, if my html element has the js class (along with a myriad of other classes), I know that Javascript is enabled. If the html element retains the no-js class, I know that Javascript is disabled and I can then serve the note I’ve written to let the user know to enable Javascript to properly view the page.

I create a paragraph with a class of “noscript” and put the information within:

<p class=”noscript”>Please enable Javascript to properly view this page.</p>
(Or any other pithy comment you’d like to make.)

In my CSS, I then set that paragraph to display:none if Javascript is enabled. This makes sure that only those with Javascript disabled will see my comment:

.js .noscript { display: none; }

In this case, I don’t actually see a reason to set the .no-js .noscript paragraph to display:block. If that class exists on a paragraph, it’s going to be set to display:block by default. If the html element never displays the class of .js, there’s nothing to override anyway.

Paul Irish has added this to the HTML5 Boilerplate as well. 

Happy coding!

Google—Your balls and periods are all wrong.

Now, before you jump down my throat and tell me, “it’s just a logo, lighten up,” let me give a brief explanation (that’s all I have time for and 140 isn’t doin’ it). 

Today, Google launched a really cute little experiment where multi-colored balls fly into the page, assemble themselves as the Google logo and re-scatter any time your cursor gets close. Really, very cute. And it’s just a logo. The issue for me is how they did it. Though their page has an HTML5 doctype, there was no HTML5 in the method they used to create the moving logo—it was old skool Javascript/divs (being rounded by CSS3 border-radius). Because you can create little dots out of divs doesn’t mean you should. And in Internet Explorer, it gets worse—they use periods—you know, like a comma. Seriously. Tons of periods flying all over the page. Not only is this a gross example of being non-semantic, but it’s horrendous for accessibility. Can you imagine coming to the search page with a screenreader and IE? You’d have to listen to period, period, period, period…ad infinitum. Bad.

The sad thing is, they could have done this with HTML5 technologies (well, canvas and SVG). And a couple smart devs immediately did. Rob Hawkes recreated the logo effect with canvas (it’s no more accessible but it’s less annoying) and Robin Berjon recreated the logo with SVG. Furthermore, they sniffed. Sniffing in this day and age is unnecessary and they proved it by excluding the newest Opera browser which would have rendered it quite well.

I suppose what bothers me even more is that it seemed to get thrown into the hype that is HTML5. Don’t get me wrong. I love HTML5. I’m building with an HTML5 doctype and elements. I’m teaching and speaking about HTML5. I’m bothered by the fact that the term HTML5 is being bandied about like Web 2.0 once was (where’s Web 2.0 now, huh?)—used by people that don’t actually even know what it means—just that it’s cool. And for that reason, a page with an HTML5 doctype uses non-semantic, non-accessible (maybe anti-accessible, annoying is better) little logo doodle and Time magazine writes an article about it—in wonder at the mystery of the meaning. No, they didn’t say it was HTML5—I’ll give them that. But with Google’s earlier pacman HTML5 example, that was the immediate assumption by us all—and likely Time as well. The overuse/misuse of the term HTML5 is the subject for another rant however.

It would have been nice to see this done with canvas or SVG — even Flash would have been less annoying to a screen reader since it could be hidden altogether. Old style DHTML… hmmmm.

How to use a list marker with a definition list

Today, a friend on Twitter posted a frustration he was experiencing. He wanted to set a list-style on a definition list, but it wasn’t cooperating. According to the spec, a list item -li- in an ordered or unordered list has a marker. A definition list, which has two parts—a dt and dd (or multiple dd)—is typically rendered by user agents on two lines, with the second slightly indented, but with no list marker. But with CSS, it doesn’t have to stay that way.

I’m sharing the fix here in case someone else needs the same visual rendering. One of the lesser used values of the display property is list-item. Placing this property/value on the dt does not change it to block rendering, it simply allows you to set a list marker using the list-style property. If it were the dd you wanted markers on, that would work as well. The support for it is good. I didn’t test but PPK’s compatibility chart reports that Internet Explorer 6 and 7 both support it as long as the the default value for the element is inline. A dt is inline by default, so I expect it will work (a dd is block, so you might have trouble in IE 6/7 if you want to place it there).

Depending on your overall page and list styling, you may need to give the dt a bit of left margin—you can also place the margin on the dl. I made a quick example of list markers on definition lists showing all three scenarios. 

Happy coding!

Box-shadow, Firefox 3.6 & Opera 10.6

I’m currently building a site for a dream client—one whose website user base is built of tech-oriented people, who has almost no Internet Explorer 6 in his stats, and who groks, and even encourages, progressive enhancement. I’m using lots of HTML5 and CSS3 goodness on the site and it’s great fun!

But in certain areas, dealing with new, and still developing technologies is proving interesting. One of them is related to border-radius. Thanks to Dave Gregory (@screwlewse) for his brilliant sleuthing and helping me track this little bugger down!

In a nutshell, on top of CSS3 and HTML5, the site (which I can’t show quite yet) makes use of a lot of generated content. It was rendering fine in Webkit-based browsers, but in Firefox (and later I found the same in Opera), there was a horizontal scrollbar of approximately 10px. I started the process of commenting CSS out, bit by bit, beginning with my more complex rules comprised of generated content. My early finger pointing was there was in that direction—but there was nothing there. After much hair pulling, curse words, and other unmentionables, we found the reason.

Though the spec says the border-radius property should not add any size to the element, Firefox adds the size of the border-radius spread on the right side of the element (that’s where it was in my case anyway—I haven’t had time to do exhaustive testing). Since this site is liquid (based on percentages) and the full browser width is used, the shadow place on the header was creating a space on the right side of the page. I haven’t had time to find a fix yet, so for now, that property is commented out in my client’s page (Yay for browser prefixes!). But perhaps one will appear.

You can see a simplified example of this Firefox bug for yourself. View in Firebug and comment out the -moz-box-shadow property to watch it disappear. And lest we pick only on Firefox, Opera shows the same problem.

Happy coding!

Modernizr & the latest browser support for CSS3/HTML5

Anyone that follows me on twitter knows I’m a big Modernizr fan. There are so many practical uses for it. Yesterday, I finally upgraded my browsers to the latest versions — Firefox, Chrome, Opera and Safari. As I was working on a project, I noticed in my Modernizer string that there were less “no-” properties shown in some of the new browser versions (as well as more properties Modernizr is testing for in the new version—nice!). So here’s another handy use for Modernizr—showing you what’s new in your upgraded browser. ;)

In Chrome 5.0.375.125, I have:

html class=” js canvas canvastext geolocation crosswindowmessaging websqldatabase no-indexeddb hashchange historymanagement draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms no-csstransforms3d csstransitions  video audio localstorage sessionstorage webworkers applicationcache svg smil svgclippaths  fontface”

In Firefox 3.6.8, it says:

html class=” js canvas canvastext geolocation crosswindowmessaging no-websqldatabase no-indexeddb hashchange no-historymanagement draganddrop no-websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow opacity no-cssanimations csscolumns cssgradients no-cssreflections csstransforms no-csstransforms3d no-csstransitions video audio localstorage sessionstorage webworkers applicationcache svg no-smil svgclippaths fontface”

In Safari 5.0, we now have:

html class=” js canvas canvastext geolocation crosswindowmessaging websqldatabase no-indexeddb hashchange historymanagement draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions  video audio localstorage sessionstorage webworkers applicationcache svg smil svgclippaths   fontface”

Finally, Opera 10.6 looks like this;

html class=” js canvas canvastext geolocation crosswindowmessaging websqldatabase no-indexeddb no-hashchange no-historymanagement no-draganddrop no-websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow opacity no-cssanimations no-csscolumns no-cssgradients no-cssreflections csstransforms no-csstransforms3d csstransitions video audio localstorage sessionstorage webworkers applicationcache svg smil svgclippaths fontface”

UPDATE: Decided to add IE 8:

html class=” js no-canvas no-canvastext no-geolocation crosswindowmessaging no-websqldatabase no-indexeddb no-hashchange no-historymanagement draganddrop no-websockets no-rgba no-hsla no-multiplebgs no-backgroundsize no-borderimage no-borderradius no-boxshadow no-opacity no-cssanimations no-csscolumns no-cssgradients no-cssreflections no-csstransforms no-csstransforms3d no-csstransitions fontface no-video no-audio localstorage sessionstorage no-webworkers no-applicationcache no-svg no-smil no-svgclippaths

Looks like everyone’s getting closer, doesn’t it? (Well, save IE where we’ll continue to wait for their holy grail version—soon I hope.) What it can’t report is things like—Safari 5.0 no longer requires the -webkit prefix for border radius (though you’ll still need it for older versions and mobile Safari), or changes in a property that was already supported. Still, it’s a handy comparison chart when you need it. 

Happy coding!

Speaker Scam

Yesterday I received a request to speak at an upcoming London Youth Conference. Outside the slightly broken English, it wasn’t unlike other speaking requests. It was written to me by a Reverend Mike Gabriel. He stated where he found my name (through another speaking gig). He promised a contract on request as well as travel and generous honorarium. But my spidey sense went up for some reason (maybe it was the generous honorarium ;)).

For one thing, the event is on August 1st, less than two weeks away. I was invited late due to the illness of one of the speakers. Another issue was related to the fact that the topic was “Future.” Future of what? There was no explanation. And the final fact that made me probe rather than reply was that the website address was listed as “being updated,” with no URL. Ummm, if you’re still updating your site 2 weeks before the event, I’m wondering how you’re going to have 3,500 people there as you state.

A quick Google search produced a link to Colleen’s website where she outlines a nearly identical letter from about a year ago—along with 63 comments from other speakers who have been contacted over the past year.

The scam comes in when they get you to give them a credit card number to procure a UK visa—or work permit—it seems to vary. And of course, you know what happens after that. As Strong Bad would say, “DeLEETed.”

Firefox, HTML5 and an anchor bug

I’m sure someone’s named this bug already. And perhaps it’s written up all over the web. But it just affected a site I was working on today and left me scratching my head for a few minutes. In case you run into it, I’d like to confirm to you, “No, you’re not crazy.” (Well, not for this reason anyway.)

Apparently, Firefox has an issue with the ability HTML5 has given us to wrap just about anything in an anchor (one of my favorite features). I find this useful in many situations. Wrapping an anchor around an image and a paragraph/caption (whether I’m using the figure element or not), wrapping the entire contents of a list item, wrapping all headings in an hgroup when used as a logo of sorts, etc. Much of the time, I’m using the declaration “text-decoration: none;” and then using another method to indicate the link. Today though, that changed. I needed this link underlined.

Firefox refuses to show an underline on a link around block level elements

I had a client report today, with an HTML5 site I’m building, that one of the pre-order links wasn’t underlined in Firefox. The anchor, in this case, was wrapped around a paragraph and image. I used Firebug to inspect it. The CSS for the link itself wouldn’t even show up in Firebug (the a:visited state did). I validated the page. All was well. I Inspected with Dreamweaver and the link was underlined as it should be. It was also underlined in webkit browsers and Internet Explorer. WTF?

It finally occurred to me that this link was around block level elements. I created a simple test case and, sure enough, with a heading and paragraph wrapped in an anchor, Firefox refused to show the underline. The answer was found in setting the anchor to display: block. But really Firefox? You’re usually nearly bug-free. Can we get this fixed?